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.
Test Technical Description There are three parties involved in this attack:  - Is an attacker who may know the identity of "B", and the structure of site "C".  - Is the victim user (of web-site "C").  - 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.
Possible actions that can be performed by the script are:  Sending the attacker the user cookies for the legitimate site  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:  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).  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).  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=>"'><script>alert(XSS%20Vulnerable%20To%20Cross%20Site%20Scripting')</script> 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 >"'><script>alert('XSS Vulnerable To Cross Site Scripting')</script> </HTML>
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=">"'><script>alert('XSS Vulnerable To Cross Site Scripting')</script>"> <br> <INPUT TYPE=text NAME="other data" value="Enter other data here"> <br> <INPUT TYPE=submit value="Submit"> </FORM> </HTML>
Listed below are the different variants performed:
Variant , : 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 '<\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 <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.
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"