搜索
WEB开发框架的安全问题中国科学技术大学软件学院林观利2013.06.011背景Web是互联网的核心，是未来云计算和移动互联网的最佳载体，因此Web安全也是互联网公司安全业务中最重要的组成部分。然而在当今的互联网行业中，对安全的重视程度普遍不高。有统计显示，互联网公司对安全的投入不足收入的百分之一。在2011年岁末之际(当时本人还在家中备考)，中国互联网突然卷入了一场有史以来最大的安全危机。12月21日，国内最大的开发者社区CSDN被黑客在互联网上公布了600万注册用户的数据。更糟糕的是，CSDN在数据库中明文保存了用户的密码。接下来如同一场盛大的交响乐，黑客随后陆续公布了网易、人人、天涯、猫扑、多玩等多家大型网站的数据库，一时间风声鹤唳，草木皆兵。Web开发框架就相当于web应用程序的操作系统，它决定了一个应用程序的模型结构和编程风格。由于框架漏洞频发，struts任意代码执行、Djangocsrftoken防御绕过、Cakephp代码执行等等各大语言编程框架都相继暴出高危漏洞，这说明对于编程框架的安全问题已经逐渐走入安全工作者的视线。关键字：SQL注入，XSS，CSRF常见的WEB安全攻击种类1、SQL注入：所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。攻击者通过在应用程序预先定义好的SQL语句结尾加上额外的SQL语句元素，欺骗数据库服务器执行非授权的查询,篡改命令。它能够轻易的绕过防火墙直接访问数据库，甚至能够获得数据库所在的服务器的系统权限。在Web应用漏洞中，SQLInjection漏洞的风险要高过其他所2有的漏洞。2、跨站脚本攻击(也称为XSS)：XSS全称(CrossSiteScripting)跨站脚本攻击，是Web程序中最常见的漏洞。指攻击者在网页中嵌入客户端脚本(例如JavaScript),当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的.比如获取用户的Cookie，导航到恶意网站,携带木马等。3、CSRF攻击CSRF（Cross-siterequestforgery），中文名称：跨站请求伪造，也被称为：oneclickattack/sessionriding，缩写为：CSRF/XSRF。你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。Web开发框架现状现代编程框架的几个大特点：1、将程序代码分为不同层次，业务开发、前端开发、数据库开发人员各司其职，框架根据需要组装代码、调度执行2、统一化自动化逻辑处理3、常见功能的代码库封装并高度重用4、脚手架功能，常见代码组件自动组装生成。如默认用户系统、默认后台。然而就是以上几点广受好评的功能导致了安全薄弱点的产生。1、代码调度3先回顾一下WEB应用框架所最常见的MVC模型。用户发送一个HTTP请求过来，框架的入口点（一般是route，路由）分析用户请求的url。然后依照url中蕴含的信息分析出用户所要访问的controller、action，从而分发给相应的controller文件中的action函数，执行之；随后controller再将model中的数据结合用户输入数据依照view层中的代码逻辑填充模板，最后view、controller执行完毕，返回用户最后的HTML。整个生命周期是这样的：用户请求url-route分发-controller接管处理用户输入及业务逻辑-view层代码执行-controller返回展现结果从上面的流程发现了什么？MVC模型就是一个将程序员分散在M、C、V中的代码寻找并整合在一起执行的过程。那这必然就要牵涉到一个代码调度执行的问题。这里route就是一个非常明显的例子。一个框架这么多代码文件，route每一次调用controller，都需要根据用户输入的url进行匹配并执行用户指定的函数。这里就是一个薄弱点，一个必然绕不过去的问题。2010年7月9日，安全研究者公布了Struts2一个远程执行代码的漏洞（CVE-2010-1870），严格来说，这其实是XWork的漏洞，因为Struts2的核心使用的是WebWork，而WebWork又是使用XWork来处理action的。这个漏洞的细节描述公布在exploit-db2上。在这里简单摘述如下：XWork通过getters/setters方法从HTTP的参数中获取对应action的名称，这个过程是基于OGNL(ObjectGraphNavigationLanguage)的。OGNL是怎么处理的呢？如下：user.address.city=Bishkek&user['favoriteDrink']=kumys会被转化成：4action.getUser().getAddress().setCity(Bishkek)action.getUser().setFavoriteDrink(kumys)这个过程是由ParametersInterceptor调用ValueStack.setValue()完成的，它的参数是用户可控的，由HTTP参数传入。OGNL的功能较为强大，远程执行代码也正是利用了它的功能。由于参数完全是用户可控的，所以XWork出于安全的目的，增加了两个方法用以阻止代码执行。*OgnlContext'sproperty'xwork.MethodAccessor.denyMethodExecution'(缺省为true)*SecurityMemberAccessprivatefieldcalled'allowStaticMethodAccess'(缺省为false)但这两个方法可以被覆盖，从而导致代码执行。#_memberAccess['allowStaticMethodAccess']=true#foo=newjava.lang.Boolean(false)#context['xwork.MethodAccessor.denyMethodExecution']=#foo#rt=@java.lang.Runtime@getRuntime()#rt.exec('mkdir/tmp/PWNED')ParametersInterceptor是不允许参数名称中有#的，因为OGNL中的许多预定义变量也是以#表示的。可是攻击者在过去找到了这样的方法（bug编号XW-641）：使用\u0023来代替#，这是#的十六进制编码，从而构造出可以远程执行的攻击payload。最终导致代码执行成功。52、代码高度封装代码的高度封装，对外只暴露几个接口，一行说明书。这必然造成一种现象：普通程序员就像是在搭建一个模型，只要按照说明书组建积木就可以了，不需要知晓其原理，不需要知道为什么要这样做。于是这时候就安全问题就产生了。再举一个struts2的例子：对于常见的文件上传场景，struts提供了一个FileUploadInterceptor拦截器，直接可以在应用逻辑运行前对用户上传文件进行检查。然而在笔者的代码审计经验中，常常发现程序员只对maximumSize（文件大小）和allowedTypes（文件mime-type）进行限制，却放过了最关键的allowedExtensions（扩展名）限制。为什么？检查一下官方文档，发现在struts2.2之前的文档，都没有给出allowExtensions的说明。或许struts开发者想当然的认为allowedTypes就可以限制上传文件的类型，殊不知只要伪造HTTP包中的mime-type字段，就可以直接上传任意文件。于是开发者也就依照官方的例子，只限制了allowdTypes，从而导致安全问题的产生。高度代码封装的确解决了“重复造轮子”的问题，但是它解决不了程序员的安全意识和懒惰的习惯。或许它设计的很好，或许它实现的也很好，但是只要它组装的不好，就有可能造成问题。3、不做框架的傀儡框架的应用是软件开发的必然趋势，本文的目的也不在于抵制框架的使用。但对于框架应用后所带来的新安全问题，安全从业人员需要提高重视，紧跟技术发展，更新知识。对于此，我们能够做点什么？1、对于常见的应用场景，如文件操作、命令行操作、数据库操作、用户权限及认证等，我们需要了解框架的实现，给出相应的安全编码范例。框架文档中给出的例子并不一定就是最好的。安全工作者必须对程序员进行安全意识的培训，让他知道如何利用框架的API去安全的组合出常用功能。62、对于应用漏洞挖掘，我们需要扩充字典。框架的封装，可能引入更多的危险API或危险特性。在代码审计的过程中，需要将这些内容加入到危险词字典中。3、对于应用漏洞挖掘，由于框架结构所带入的新的安全薄弱点，需要专门对框架的设计及实现做检查，是否存在问题。总结Web框架本身也是应用程序的一个组成部分，只是这个组成部分较为特殊，处于基础和底层的位置。Web框架为安全方案的设计提供了很多便利，好好利用它的强大功能，能够设计出非常优美的安全方案。但我们也不能迷信于Web框架本身。很多Web框架提供的安全解决方案有时并不可靠，我们仍然需要自己实现一个更好的方案。同时Web框架自身的安全性也不可忽视，作为一个基础服务，一旦出现漏洞，影响是巨大的。致谢本文参考了《白帽子讲Web安全》，上学期郭燕老师的《Web安全实践》以及网上一些前辈们的研究，特此表示由衷的谢意。