应用安全工作的那些事儿

好久没写文章了，之前写的文章都是实际解决方案的文章往往看起来比较晦涩，本文就说说与我工作有关的故事吧。

先声明一下个人观点：

1. 应用安全工作决不可能都是由应用安全工作者完成的，不是全员参与的应用安全工作决不可能做出安全性很好的产品。

2. 公司期望所有与应用安全有关的工作均有应用安全工作者来完成，那一定是战略上的轻视、战术上的错误，最终必将以重大安全事故的出现而结束这场战争。

3. 企业应用安全工作者理应是：安全风险的识别者、解决方案策划者与设计者及企业工程师安全意识的培训者，必需得到最高层的直接重视方可得以很好的实施。安全的具体实施理应由普通的工程师完成，规范化渗透测试工作理应由普通的测试工程师来完成。导弹是高科技产品，它的零部件依然是普通的工人来完成的，不要认为应用安全很高深，普通工程师做不了，那是应用安全实现“工艺设计”人员的工作没做好!

【故事一】：XSS的困惑

在公司的早期，当我演示XSS的问题给我们的开发者与测试人员的时候(e.g. http://www.testfire.net/search.aspx?txtSearch=%3Cscript%3Ealert%281%29%3C%2Fscript%3E)，他们最最困惑的一个问题是：

|谁没事把自己的页面注入一串javascript的然后在自己的浏览器当中执行?这是漏洞吗?

这个问题看起来似乎很傻，其实不然，这里蕴涵着一个非常重要的问题：谁是攻击者、谁是受害者以及谁是责任者的问题，你想过这些问题吗?若想让你的公司的员工明白XSS问题的严重性必需让他们从根本上理解问题，方可以得以从心底里接受。于是我就做了一个虚拟的场景：

假如我是黑客，我发现某公司网站上可以注入JS脚本，于是我就巧妙的构造攻击URL，通过社会工程学的方式诱使对方点击我的URL，当对方处于登录状态时，我可以获取对方的会话信息、本地cookie信息等等，我可以做的事你可以想象了…，在这里我是攻击者，我们的产品用户是受害者，我们公司是责任者，你说我们要不要处理这个问题?

【故事二】：关于CSRF的那些事

先问问读者：CSRF是漏洞吗?

在我要求开发人员解决CSRF(CSRF概念可查询CSRF)问题的时候，我曾经被一个资深开发人员问的目瞪口呆，开发人员的问题是：

一个需要做身份验证的URL，我们在实现的时候已经做了严格的身份验证，现在你的要求等于是让我我们再做一次身份验证，这不是折腾吗?换句话问用户访问了一个只有登录成功才可以访问的URL，当用户登录后可以正常访问，为什么你还说它需要做身份验证?

开发人员的问题是有效的，且我认为是有价值的，如果你不能给开发人员解决这个问题，他们是不能从心底里形成类似问题的防御意识，相反他们会形成一种内心的抵抗，最终的效果将是可想而知的。于是我又做了一个场景的虚拟：

假如我是黑客，你是用户，我是黑客，当然我同时也是一个用户，没有迹象表明我是一个黑客，对于别的用户来说，我就是一个普通的用户而已。OK,你登录了我们的产品，我也登录了我们的产品，现在我找到了changePasswd.do的API，我发现它并没有做CSRF防范，但是这个URL是做了严格的身份认证检查的，现在我用changePasswd.do?newPWD=XXXX来构造一个URL，发给你，为了有隐秘性，我可以使用短链接的方式发给你，你一眼也看不出来它里面包含了什么，当你点击之后，它会怎么样? 开发说：可以正常运行! 我问：为什么不需要登录、为什么没要求身份验证? 开发说：我已经登录了!我说：这就是CSRF了，你觉得它严重吗?

此例子当中攻击者是我，受害者是那个开发人员，责任者依然是我们产品—服务的提供者。

【故事三】：身份认证与授权难解之惑

我们要求开发描述清楚你写的URL或者API的身份认证的要求，比如：myInfo.do，

开发人员：只有登录的用户才可以访问myInfo.do，否则会转到登录页面要求用户登录。

我说：这样写是不对的，你这样写表明只要登录的用户都可以访问myInfo.do了.

开发人员：没错啊，登录的用户就可以访问myInfo.do，这有什么问题?

我说：如果我登录了，但是我访问的是你的myInfo.do会怎么样?

开发人员：(…沉思了一会…)，这种情况是可能存在的，但是这是比较偏的情况

我说：我们做安全需要考虑的就是可能存在的安全风险，正确的描述访问是：只有登录的用户才可以访问他自己的myInfo.do!读者可能会问：咬文嚼字吗? 我想说的是：这样的咬文嚼字必需有，否则后果很严重。