MatrixPedia: XSS

Cross-site scripting (XSS):跨站脚本是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻击者利用XSS漏洞旁路掉访问控制——例如同源策略（same origin policy）。近来，这种类型的漏洞被用来编写危害性更大的phishing攻击和利用浏览器漏洞。产生背景«‹›»
当Netscape首先引入JavaScript语言时，他们便认识到这些允许web服务器发送可执行代码给浏览器所带来的安全风险。其中的一个关键问题是往往用户一次打开一个以上的浏览器窗口。在一些场合中，来自一个页面的脚本应被允许访问来自另一个页面或者对象的数据，但这在其它的一些场合中是被严格禁止——因为一些恶意站点可以使用此方式盗取敏感信息。出于这一原因，同源策略被制定了。此策略允许对象和页面之间进行任何交互，但这些对象要来自于页面所在同一域名和同一协议。这样，恶意站点就不能通过另一个浏览器窗口中的JavaScript访问敏感数据。
至此，其它一些类似的、用于防止用户被恶意站点侵害的访问控制策略已经被其它浏览器和客户端脚本语言所采取。
通常，XSS漏洞被视为允许攻击者越过这些机制的漏洞。通过寻找新的脚本侵入途径——将恶意脚本注入位于其它域名的页面，攻击者获得了敏感页面内容、会话cookie、其它对象变量的访问权限。
名词«‹›»
XSS并不是对于此类漏洞的精确描述。按照XSS先驱Marc Slemko的说法：“这个问题不是关于脚本的，实现跨站没有所必需的任何东西。那么为什么这样称呼呢？因为它最早被杜撰出来时大家对于XSS这个问题并没有很透彻的认识。”
早期的CSS被用来指跨站脚本漏洞，但这个名字很快就和级联样式表（Cascading StyleSheets）、内容编码系统（Content-scramblingsystem）的缩写产生冲突。因此在2002年，XSS这个缩写的缔造者Steve在Bugtraq邮件列表上首次建议使用XSS作为跨站脚本的缩写。随后各大安全社区很快便使用了XSS，而CSS很少被用来指跨站脚本了。
XSS的类型«‹›»
XSS漏洞目前具有三种不同的类型。出于讨论的目的，这里标记为类型0、类型1、类型2。
类型0«‹›»
此形式的XSS漏洞涉及到基于DOM或者为本地跨站脚本的漏洞。此类型漏洞存在于页面中客户端脚本自身。例如：如果JavaScript代码访问URL请求参数并使用这个信息在自身所在的页面中输出一些HTML，而这个信息没有使用HTML实体编码，因为这个被输出的HTML数据（可能包含附加的客户端脚本）可以重新被浏览器进行解释执行，所以出现了此类型的XSS漏洞。
在实际环境中，利用这样一个漏洞和利用类型1的漏洞非常相似，除了一个非常重要的条件。由于InternetExplorer对待位于本地域（比如在客户端本地硬盘中）的对象中的客户端脚本的方式，此类性XSS漏洞在本地页面中能呈现出远程执行漏洞的效果。例如，如果一个攻击者建立了恶意web主机，其主机中包括了一些链接到客户端本地系统的具有漏洞的页面，脚本便能被注入用户浏览器、并以用户浏览器权限运行。这便越过了这个客户端沙箱，而不是跨域限制。
类型1«‹›»
这种XSS漏洞涉及一些非持久化的或者反射的漏洞。这些漏洞出现在web客户端使用server端脚本生成页面为用户提供数据时。如果未经验证的用户数据被包含在页面中而未经HTML实体编码，这便使客户端代码能够注入到动态页面中。一个经典的例子是站点搜索引擎：当进行一次对于某个包含一些特殊HTML字符的关键词的搜索，通常搜索关键词将显示在搜索结果页面中用来标记哪些信息被搜索，或者至少要在编辑文本框中显示搜索关键词。如果这个搜索关键词没有被HTML实体所编码，那么将出现类型1的XSS漏洞。
首先，这不会出现严重的问题，因为用户只能在他们自己的页面中注入代码。但是在少量的案例中，攻击者能够欺骗用户随着一个注入代码的恶意URL而进入搜索结果页面，这使攻击者拥有访问页面内容的所有权限。对于这种情况，一些开发者并不认为它是多么的可怕。这个错误的概念有时被应用到对待XSS漏洞上，这也是安全社区所不同意的，后者认为跨站脚本漏洞非常值得重视。
类型2«‹›»
类型2的XSS漏洞涉及到被存储的、持久化的或者二次的漏洞。它允许多种危害巨大的攻击。此类型XSS漏洞出现于当web应用提供数据的情况下，此时这些数据首先被用户持久化保存到服务器上，然后被显示在页面中但没有经过HTML实体编码。一个经典的实例是在线留言版，用户被允许发布提供给其他用户读取的HTML格式的信息。
这些漏洞常比前两种漏洞影响深远，因为攻击者能够一次性注入脚本。这便潜在地给web应用带来了被注入跨站脚本病毒的危险。
注入的方法多种多样，攻击者可以无需使用web应用本身便可以利用此漏洞。被web应用接收的任何数据（通过电子邮件、系统日志等）可以被攻击者控制，所以在显示在动态页面中这些数据之前要进行编码。
利用XSS漏洞的场合«‹›»
攻击者尝试利用XSS漏洞的方式按照漏洞的类型有所不同。
类型0攻击«‹›»
Mallory发送一个恶意构造了web页面的URL给Alice（通过电子邮件或者其它机制）。
Alice点击链接
恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在Alice电脑上。
具有漏洞的HTML页面包含了在Alice电脑本地域执行的JavaScript。
Mallory的恶意脚本可以在Alice的电脑上执行Alice所持有的权限下的命令。
类型1攻击«‹›»
Alice经常浏览某个网站，此网站为Bob所拥有。Bob的站点运行Alice使用用户名/密码进行登录，并存储敏感信息（比如银行帐户信息）。
Mallory发现Bob的站点包含反射性的XSS漏洞。
Mallory编写一个利用漏洞的URL，并将其冒充为来自Bob的邮件发送给Alice。
Alice在登录到Bobde1站点后，浏览Mallory提供的URL。
嵌入到URL中的恶意脚步在Alice的浏览器中执行，就像它直接来自Bob的服务器一样。此脚本盗窃敏感信息（授权、信用卡、帐号信息等）然后在Alice完全不知情的情况下将这些信息发送到Mallory的web站点。
类型2攻击«‹›»
Bob拥有一个web站点，这站点允许用户发布信息/浏览已发布的信息。
Mallory注意到Bob的站点具有类型2的XXS漏洞。
Mallory发布一个热点信息，以使其它用户纷纷阅读。
在大量对此信息的浏览中，站点用户的会话cookies或者其它证书将被Mallory盗走。
而后，Mallory作为其它用户登录站点伪装为他们继续发布恶意信息。
外部链接«‹›»
HTML Code Injection and Cross-site Scripting
CGISecurity — The Cross Site Scripting (XSS) FAQ
Second-order Code Injection
DOM-Based Cross-Site Scripting
Foiling Cross-Site Attacks
A List Apart — Community Creators, Secure Your Code!
A List Apart — Community Creators, Secure Your Code! PartII