SSL历险记

Nov 27

IUSR技术文章, 补充两句 , No Comments

我得承认我是个SSL重度依赖者，上网总会下意识地把URL里的http后随手加个s——我打URL时从来都是从不厌其烦手动写上协议名称的，发送表单——尤其是用户名密码什么的——看到目的URL不是https的总觉得像被人剥光了一样，家里机器时不时地打开着就为了用putty做个tunnel，方便在公司访问一些没SSL支持又敏感的站点、服务etc.。
可惜啊，今天被彻底地打击了，竟然有人会想到这么明目张胆地强奸下SSL。
我得感谢firefox这些不鸟Internet设置里那些CA证书的应用程序，类似的程序还包括thunderbird以及伟大的，那个，SUN
JRE。早晨来到公司，就发现没有关掉的ff里跳出N多错误提示框说mail.google.com、www.google.com、api.delicious.com这些站点的证书有问题。刚开始还觉得是firefox受不了这一夜的孤独又出问题了。可是因为装了那个Perspectives扩展，这种情况下看证书也比较方便，就顺手看了看，结果被……不知道”雷”这个动词适合不适合这个情景……证书的颁发机构是一个很陌生又很熟悉的名字：说陌生是因为长这么大没见过这个CA，说熟悉是因为每个工作日都能看到这个名字。”咦？难道经济危机时做CA有助于增加收入么？”于是，先ping下这几个域名，确认一下DNS没被f*ck掉，check；然后请出openssl
s_client，确认一下ff没有脑残能把证书都搞错，check。那接下来就是标准国骂了：谁（TMD）动了我的SSL会话？！
为了鄙视下Windows + IE组合，我当然得拿出来最新最NB的IE8试试。结果，果然没问题，所以理论上我刚看到的那个山寨CA肯定已经存在于这鸟Windows
XP里了，理论上我还得查一下internet属性来确认一下，当然最后也很明了：我是在域控的关怀和照料下茁壮成长的，所以这鸟XP里出现几个我不认识的山寨CA，还真没法让我吃惊。
好在大部分应用程序还都是靠谱的，看到这种山寨CA还都是会报错说未知CA的。不过这么一折腾，所有本地跑来测试的java程序都没法跟外网服务器建立SSL连接了。还好我比较有前瞻性，早就着手验证这事儿，赶紧发的信给大家说了下怎么让JRE容忍这几个山寨CA。
我在想一个情景：一个恶意站点，因为一直脑残，用的是伪造的、自认证之类的SSL证书，所以无人问津；某个同事不幸地点了别人发的一个URL，正是这个脑残恶意站点，本来这种情况下是会提示证书错误的，结果现在因为根CA被篡改成某山寨CA，而且这山寨CA还是受信的，那这下子连证书错误都不会提示了，IE很高兴……当然也许这SSL篡改程序还没脑残到这程度吧，哪天试验下。
好吧，既然这样，上班时间咱就不看Gmail和Google
Reader了。既然（有可能）人家觉得员工看这些是浪费时间，我就发挥前辈徒手造解放大卡的精神闷头干活吧。

JS蠕虫

Jun 13

IUSR咿咿呀呀 , , No Comments

昨晚看到The Register上的一篇文章：JavaScript worm targets Yahoo!，一个以js编写的蠕虫，借助Yahoo! Webmail的漏洞快速蔓延起来。这次的蠕虫比较特殊，以往的跟浏览器、web扯上关系的病毒，大多利用的是浏览器自身的问题，而这次是完全利用的web应用的问题。

安全的确是无处不在，比如这个蠕虫，它并没有对用户的系统造成侵害，但会从用户的Webmail联系人中找到同样使用Yahoo! Webmail的人并将自身转发给他，这又符合对蠕虫的一般定义。虽然用户一旦关闭浏览器，蠕虫在其机器中的实体就会灰飞烟灭，看似不堪一击，但实际对这个web应用已经造成影响。将自身转发给其他人只是它蔓延的方式，如果这个蠕虫不停的转发或者向这个网站发出请求，网站很可能被一下子DoS掉。

我一向以拟人的角度来看病毒，所以觉得它们就像生物中的病毒一样，狠毒中透着伟大，为了自身的生存和复制，在很严苛的环境里不断蚕食着周围生命的某个部分。算了，反正我已经从一个梦想成为安全专家的人变成一个稍微爱好安全的普通小程序员。

当个合格的webapp developer真是越来越不易了

Jan 22

IUSR补充两句 , No Comments

俗话说，隔行如隔山，到了计算机这行就更夸张了，外人也许不明白，都是搞计算机的，怎么差别就那 么大呢？搞computer.software的不懂computer.hardware的还好理解，不过搞 computer.software.develop.*的不懂computer.software.security.*的在外人看来实在有些丢人，实 际上呢，谁有那个工夫
买了本好久不买了的《黑客防线》，翻了翻，发现现在的主流入侵方法（或者说，破坏方法）俨然已经是SQL注入了，各种文章也越来越流于介绍 NBSI、HDSI等等工具的使用方法，看了几篇文章，貌似除了穿插的截图不太一样，其他的都大致相同，跟一本使用手册一样。还有的人认为JSP+ Oracle就不会或者很难被注入，实际上大家都明白，纯粹的字符串拼接逻辑才是SQL注入的温床。
随着各种webapp爆发式地推出，webapp自身的安全越来越不容忽视了。以前我也鼓捣过SQL注入，那时的目的还是想以这种入侵方法作为 辅助，以拿到root或者Administrators组权限为最终目的，而现在，能打掉一个论坛、一个CMS就已经是高手了，而且确实，这些 webapp的价值对于网站所有者而言有时超过服务器系统的价值：服务器OS可以重装，但数据或者代码的损失可是不可估量的。更有甚者，已经出现了靠 webapp或者数据向受害一方勒索钱财的案例。一代不如一代。
看来觉得web层逻辑随便找个新手来搞的观念要改一改了，不只要精通html+javascript做客户端验证，服务器端的验证一样很重要， 还要明白图形验证码这样的需要两端验证的方法，而且不只是过滤字符串那么简单，还要涉及sql、hql、jdoql等等查询语言的语法验证etc.，大概 熟悉antlr势在必行了。
我以往的观点是除非系统的管理员权限失守，否则其他的入侵不算本事，赫赫，很单纯的从技术方面的考量。现在不行了，负责一些的话就要考虑自己参与的webapp上线后要真正为客户创造价值，而不是创造麻烦。
有时间要检查一下我们用的一个web层组件的代码了，如果丫也是搞字符串拼接的话（而且很可能就是这么搞的），那除了几个hard code在配置文件里的的用于显示固定栏目内容的查询，其他的……
各位webapp developer同行也要注意了，不能抱着防君子不防小人的想法来对待安全问题了，因为在互联网上你不知道对方是个小人。