Cross-Site Scripting

应用程序问题
WASC分类： Cross-Site Scripting
分为：non-persistent and persistent（如放在BBS、bulletin boards..）
参考：http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml
错误等级：
严重（High）
风险：
可以偷盗或者操作用户Session和Cookie，这样攻击者可以扮演一个合法的客户进行操作。
技术说明：
Cross-Site Scripting是一种秘密攻击行为，它能使得攻击者获得合法客户的身份和特定的服务器进行交互。攻击者利用这样一个事实：网站未对用户在页面中输入的JavaScript（通常是作为参数值）进行清洗（消毒）。这样，当在返回信息中包含这段JavaScript代码，这段代码就会在客户端的Browser中执行。这样可能形成一个指向带有恶意代码的网站链接。这串代码在这个站点环境中就会执行，收集可以获取的这个站点或者正在浏览这个网站的其他窗口的cookie，
攻击者会做进一步处理：攻击者会诱使用户点击这个由攻击者生成的链接。如果用户点了这个链接，将会向包含恶意代码作为参数的网站发起一个请求。如果这个网站将这串参数值（恶意代码）嵌入在返回中，恶意代码将在客户端的浏览器中执行：
恶意代码可能会做：
1.       将用户的cookie发送给攻击者
2.       将能够通过Dom(URLs, Form field 。。。)取到的信息发送给攻击者
结果是客户的安全性受到了威胁。
一些注释：
1.       虽然攻击者的Web Site也被卷入，但是并没有直接包含进来。攻击者通过采用“jump station”方式将返回客户，好像是合法的（It is used as a ‘jump station‘ for the malicious script sent by the attacker, to return to the victim‘s browser, as if it is legitimate.）。无论如何，由于用户是在使用这个特定的网站，而且是这个网站的直接返回，因此可以认为是这个网站的安全漏洞。
2.     这个怀有恶意的链接由攻击者生成，可以包含在攻击者自己维护的网站中。这个链接攻击者也可以通过发送email的方式发送给受害人。
3.     由于用户输入是作为form的字段值，可以知道这串恶意代码从什么地方来的，
4.       各种浏览器实现的不一样，有时候在这种浏览器上没有问题，但是换一种浏览器就会有问题。
攻击方法：
写一个链接：  参数值为：

这样，当服务器返回时，上面这串脚本将自动执行，将本地的Cookie发现指定的URL，用户资料泄露了。
解决方式：
1.       加强对参数的校验：
一定要做，大量的漏洞都是针对参数未作校验引出很多攻击手法(会有如何检查参数的单独说明)
Cross-Site Scripting
Application
WASC Threat Classification
Client-side Attacks: Cross-site Scripting
http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml
CVE Reference(s)
N/A
Security Risks
It is possible to steal or manipulate customer session and cookies, which may be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user
Possible Causes
Sanitation of hazardous characters was not performed correctly on user input
Technical Description
The Cross-Site Scripting attack is a privacy violation, that allows an attacker to acquire a legitimate user‘s credentials and to impersonate that user when interacting with a specific website. The attack hinges on the fact that the web site contains a script that returns a user‘s input (usually a parameter value) in an HTML page, without first sanitizing the input. This allows an input consisting of JavaScript code to be executed by the browser when the script returns this input in the response page. As a result, it is possible to form links to the site where one of the parameters consists of malicious JavaScript code. This code will be executed (by a user‘s browser) in the site context, granting it access to cookies that the user has for the site, and other windows in the site through the user‘s browser.
The attack proceeds as follows: The attacker lures the legitimate user to click on a link that was produced by the attacker. When the user clicks on the link, this generates a request to the web-site containing a parameter value with malicious JavaScript code. If the web-site embeds this parameter value into the response HTML page (this is the essence of the site issue), the malicious code will run in the user‘s browser.
Possible actions that can be performed by the script are:
[1] Send user‘s cookies (for the legitimate site) to the attacker.
[2] Send information that is accessible through the DOM (URLs, Form fields, etc.), to the attacker.
The result is that the security and privacy of the victim user is compromised on the vulnerable site.
Some notes:
[1] Although the attacked web site is involved, it is not compromised directly. It is used as a ‘jump station‘ for the malicious script sent by the attacker, to return to the victim‘s browser, as if it is legitimate. However, since the privacy of the victim is breached in the context of the specific site, and since the site is directly responsible, it is considered a security flaw in the site.
[2] The malicious link can be provided by the attacker, using a web site link, if the attacker maintains a site that is visited by the victim user. The malicious link can also be provided by email, if the attacker knows the user‘s email address, and the user‘s email client uses the browser to render the HTML message.
[3] While user input is most commonly found in form field values (i.e. URL parameters), there are known attacks where the malicious code is embedded in the path, query, or in the HTTP Referrer headers, and even in cookies.
[4] AppScan sends many types of Cross-Site Scripting attacks, including attacks that work only on specific browsers or versions of browsers. AppScan‘s "Show in Browser" feature uses Internet Explorer to show the vulnerability. In the case of variants to which Internet Explorer is not vulnerable, but other browsers are, the "Show in Browser" facility does not work and the popup is not shown. There are two possible scenarios for sending input to a web application that is vulnerable to cross-site scripting:
General Fix Recommendations
There are several issues whose remediation lies in sanitizing user input.
By verifying that user input does not contain hazardous characters, it is possible to prevent malicious users from causing your application to execute unintended operations, such as launch arbitrary SQL queries, embed Javascript code to be executed on the client side, run various operating system commands etc.