Cross site scripting (XSS or CSS) is a type of attack in which malicious script is inserted to webpages by attacker in form of hyperlinks.Clicking on these hyperlinks can help attacker to steal or manipulate customer session and cookies, which might be used to impersonate a user, allowing the hacker to view,alter or modify the records of user, and to perform transactions as that user.
How Cross site scripting attacks works?
The CSS attack starts as follows: The attacker lures the legitimate user to click on a malicious link that was produced by the attacker. When the user clicks on the link, it 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, the malicious code will run in the user's browser. The malicious script can be provided by the attacker, using a web site link, by e-mail, if the attacker knows the user's e-mail address.
Possible actions that can be performed by the script are:
1.Send user's cookies to attacker.
2.Send information that is accessible through the URLs, Form fields, etc., to the attacker.
Check Out Video..
There are two possible scenarios for sending input to a web application that is vulnerable to cross-site
scripting:
A. The parameter value sent to the CGI(Common Gateway Interface) script is returned in the response page, embedded in the
HTML.
For example:
[request]
GET /cgi-bin/script.pl?name=John HTTP/1.0
[response]
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2007 00:31:19 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 27
<HTML>
Hello John
</HTML>
B. The parameter value sent to the CGI script is returned in an HTML parameter value context.
For example:
[request]
GET /cgi-bin/script.pl?name=John HTTP/1.0
[response]
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2007 00:31:19 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 254
<HTML>
Please fill in your zip code:
<FORM METHOD=GET ACTION="/cgi-bin/script.pl">
<INPUT TYPE=text NAME="name" value="John"> <br>
<INPUT TYPE=text NAME="zip" value="Enter zip code here"> <br>
<INPUT TYPE=submit value="Submit">
</FORM>
</HTML>
Example 1 - Scenario A
The following request is sent by the user:
[attack request]
GET /cgi-bin/script.pl?name=>"'><script>alert('Watchfire%20XSS%20Test%20Successful')</script>
HTTP/1.0
[attack response scenario A]
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2002 00:31:19 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 83
<HTML>
Hello >"'><script>alert('Watchfire XSS Test Successful')</script>
</HTML>
In this case, the JavaScript code will be executed by the browser (The >"'> part is irrelevant here).
Example 2 - Scenario B
Using the same script and input as in Example 1 to invoke the attack:
[attack response scenario B]
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2002 00:31:19 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 310
<HTML>
Please fill in your zip code:
<FORM METHOD=GET ACTION="/cgi-bin/script.pl">
<INPUT TYPE=text NAME="name" value=">"'><script>alert('Watchfire XSS Test Successful')
</script>"> <br>
<INPUT TYPE=text NAME="zip" value="Enter zip code here"> <br>
<INPUT TYPE=submit value="Submit">
</FORM>
</HTML>
The >"'> prefix is used to break out of the parameter value context. Closing the parameter value field( "'> ) and then closing the <INPUT> tag ( > ) will cause the JavaScript to be executed by the browser and not to be treated as a parameter value that would have been parsed or executed as JavaScript code.
Listed below are the different test variants:
[1] >'><script>alert('Watchfire XSS Test Successful')</script>
[2] >"><script>alert("Watchfire XSS Test Successful")</script>
[3] </TextArea><script>alert('Watchfire XSS Test Successful')</script>
[4] >"'><img src="javascript:alert('Watchfire XSS Test Successful')">
[5] >"'><img src=javascript:alert
("Watchfire XSS Test Successful")>
[6] " style="background:url(javascript:alert('Watchfire XSS Test Successful'))" OA="
[7] --><script>alert('Watchfire XSS Test Successful')</script>
[8] '+alert('Watchfire XSS Test Successful')+'
[9] "+alert('Watchfire XSS Test Successful')+"
[10] >'><script>alert('Watchfire XSS Test Successful')</script> (.NET 1.1 specific variant)
[11] >"><script>alert("Watchfire XSS Test Successful")</script> (.NET 1.1 specific variant)
[12] >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SCRIPT+AD4-
[13] %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E5%F2%F4%A8%A7Watchfire%
20XSS%20Test%20Successful%A7%A9%Bc%Af%F3%E3%F2%E9%F0%F4%Be
Variant details:
Test variants 1 & 2: These are the most basic cross-site scripting variants. The difference between the two variants is the use of quotes or of an apostrophe in the JavaScript code. Some web application programmers only sanitize user input for apostrophe or for quotes, but not both. This vulnerability is detected by running both variants.
Test variant 3: This test variant is specifically designed for user input that is returned embedded in <TEXTAREA> parameters. During the test, an attempt is made to break out of the parameter value(text area),to force the JavaScript to be executed by the browser.
Test variant 4: Some web application programmers sanitize <SCRIPT> tags from user input, but forget to sanitize the "javascript:" specifier, which can be used in HTML links. During this test, an attempt is made to embed the malicious JavaScript code by using an <img> tag with a JavaScript link as its source.
Test variant 5: This variant is very similar to variant #4. It uses HTML entities to bypass security measures which sanitize user input of the <, >, quotes and the "javascript:" specifier.
Test variant 6: This variant uses the least number of non-standard characters. Unlike former variants, it does not use &, >, < , # or ; characters. Assuming that the user input is embedded in an HTML form parameter value (inside an <INPUT> tag), the malicious string first escapes from parameter value context and then proceeds to add a STYLE attribute to the <INPUT> tag, in which it
embeds the malicious JavaScript code. Note: this variant will only succeed in scenario B, or if user input is embedded in attributes of other HTML elements.
Test variant 7: Some web applications embed user input inside HTML comments. To test the application for this vulnerability, the HTML comment ( --> ) is first closed, and then the malicious JavaScript code is embedded.
Test variants 8 & 9: Some web applications embed user input in JavaScript string literals, for example:
<HTML>
<SCRIPT LANGUAGE="JavaScript">
var str = 'Hello $user_input';
...
</SCRIPT>
</HTML>
If we send the following parameter value: '+alert('Watchfire XSS Test Successful')+',the resulting response page will look like this:<HTML>
<SCRIPT LANGUAGE="JavaScript">
var str = 'Hello ' + alert('Watchfire XSS Test Successful') + '';
...
</SCRIPT>
</HTML>
The application is tricked into concatenating the malicious JavaScript code in the middle of the original string literal, causing the browser to execute our JavaScript code. The difference between variants #8 and #9 is the use of quotes or of an apostrophe, which customizes the attack for both stringterminating characters.
Test variants 10 & 11: In Microsoft .NET 1.1, the HttpRequest.ValidateInput method validates data submitted by a client browser and raises an exception if potentially dangerous data is present.
From MSDN: "If the validation feature is enabled by page directive or configuration, this method is called during the Page's ProcessRequest processing phase. ValidateInput can be called by your code if the validation feature is not enabled. Request validation works by checking all input data against a hard-coded list of potentially dangerous data."
Input data is checked during request validation in the following members:
- HttpRequest.Form,
- HttpRequest.QueryString,
- HttpRequest.Cookies
** Note: The HttpRequest.ValidateInput is enabled by default in ASP.NET 1.1
ASP.NET 1.1 blocks input containing '<' followed by an alphanumeric character or an exclamation mark (e.g. <script> , <img, <!--, etc...) If the '<' character is followed first by a NULL byte and only then by an alphanumeric character, the pattern does not match and the input is allowed to reach the web application. For example:
[*] The string '<script>' is blocked by ASP.NET 1.1
[*] The string '<script>' is allowed by ASP.NET 1.1
In addition, the HTML parser of most web browsers (including all versions of Microsoft Internet Explorer), ignores the NULL byte, and parses <script> as <script>. When combining this with the security problem presented above, any HTML tag can be injected through ASP.NET 1.1 HttpRequest.ValidateInput security mechanism, leaving it vulnerable to cross site scripting, and injection of other malicious HTML tags.
Test variant 12: While many input validation functions properly filter out or escape common characters used for XSS (such as <> (triangular parenthesis)), only a few manage to handle hazardous UTF-7 encoded strings.Therefore, in many cases, when sending an XSS attack payload encoded in UTF-7, the payload will
return in the response without being altered.
For the attack to succeed, the victim's browser should treat the XSS payload as UTF-7, otherwise the script will not be executed.
If 'Encoding' is set to 'Auto-Detect', and Internet Explorer finds a UTF-7 string in the first 4096 characters of the response body, it will set the charset encoding to UTF-7 automatically, unless another charset encoding is already enforced. This automatic encoding feature may help a malicious user to mount the UTF-7 XSS attack.
A successful attack for this variant requires the following:
[*] The victim uses an Internet Explorer client with 'Encoding' set to 'Auto-Detect'.
[*] There is no charset encoding enforcement (unless utf-7 is enforced) in:
[*] The response headers ("Content-Type: text/html; charset=[encoding]").
[*] A <meta http-equiv="Content-Type" (...) charset=[encoding]/> tag at the response html.
[*] The injected text appears in the first 4096 characters of the html text.
Test variant 13: The purpose of this variant is to exploit the way Internet-Explorer treats responses with 'us-ascii' Content-Type (it discards the Most Significant Bit of each character). By changing the most significant bit of each character of an XSS payload, AppScan can evade standard input sanitization functions.
For example: %3C, which is the URL-encoded representation of "<", is transformed into %BC in this attack. It is not recognized by the server-side sanitization function as a hazardous character, and therefore not altered in any way, but it will be read by Internet Explorer as "<", making a Cross-Site Scripting attack possible.
FIX RECOMMENDATIONS FOR XSS ATTACK:
It is advised to filter out all the following characters:
1. | (pipe sign)
2. & (ampersand sign)
3. ; (semicolon sign)
4. $ (dollar sign)
5. % (percent sign)
6. @ (at sign)
7. ' (single apostrophe)
8. " (quotation mark)
9. \' (backslash-escaped apostrophe)
10. \" (backslash-escaped quotation mark)
11. <> (triangular parenthesis)
12. () (parenthesis)
13. + (plus sign)
14. CR (Carriage return, ASCII 0x0d)
15. LF (Line feed, ASCII 0x0a)
16. , (comma sign)
17. \ (backslash)
Ref: IBM APP SCAN
