Xss Attacks

TehFallen · December 1, 2011

So today I was testing some XSS vulnerabilities out on a site. It seemed to be working, my script tags were generating but oddly enough the javscript in between them was mysteriously gone, so I took a look at the console and realized I was getting this error: "Refused to execute a JavaScript script. Source code of script found within request." A quick google search confirmed by suspicions, Google Chrome was protecting me >.< Admirable but I wasn't about to let it beat me, so I continued prying around. It even filtered out <meta> redirects. Then I found it. I haven't seen this on the web, but maybe someone else discovered this workaround, maybe not, needless to say I thought it was worth sharing. Let's say we have a search result page with a url of site.com/search.php?query=test&page=1 and the code looks like this:

&lt;html&gt;
&lt;head&gt;...&lt;/head&gt;
&lt;body&gt;
...
&lt;input type='text' id='query' name='query' value='test'&gt;
...
&lt;input type='hidden' id='page' name='page' value='1'&gt;
...
&lt;/body&gt;
&lt;/html&gt;

The key is that there are two inputs, and if they're both unsanitized and vulnerable to XSS then you're in luck. The way you do this is by assigning query a value of

'&gt;&lt;script&gt;/*

. The '> breaks out of the input tag, the <script> opens up a Javascript tag, and the key to it all, the /* begins a comment. Now you've halfway beaten the system, time to finish it up. Next it's time to set page equal to

'&gt;*/alert();&lt;/script&gt;&lt;input type='hidden

. The '> breaks out of the input tag as before, and now, the */ closes the comment, next the alert(); (or any other malicious code), then close the script with a </script>, and lastly I like to properly end it with a hidden input, personal preference. The key here is the comment, it lets us split our attack across the 2 inputs without the html in the middle messing it up.

Enjoy! :)

digip · December 1, 2011

No disrespect but welcome to the world of reinventing the already invented. Yeah, kind of old hat stuff right there. You can even get around it when places remove

&lt;script&gt;

all together by inserting some other object like another input tag or even an img tag, and adding an event handler, like

&lt;img onload="javascript:some code" src= /&gt; or &lt;input  onload="javascript:some code" /&gt;

.

rsnake has a site that lists a tone of ways to do xss attacks. Your method is something I've even used in the past. Thats pretty much how XSS works in the first place and a common attack vector, nothing really new, you are just learning it on your own, which is a good thing.

http://ha.ckers.org/xss.html

TehFallen · December 2, 2011

Thanks for the feedback, I've actually been to that site and a lot of those methods don't seem to work in modern day browsers, maybe I'm implementing them wrong but it seems, especially Chrome, has cracked down on this lately. I know that the error I was getting is less than a year old, I used to do the exact same XSS attacks in Chrome without it picking up that it was being used in the request, so new security features. I'd never before heard of anybody separating XSS attacks across two inputs before, but then again I hadn't heard of browsers securing against them in such methods, it's always been something that was up to the site admins to cleanse the input. Honestly I don't understand why you would split an XSS attack across two inputs except in this scenario. In addition RSnake's methods seem to address circumventing server side security and not client side security, which as I'm aware is something new. But again, the only reason I was posting this is to share a method I had not seen online (and I looked). But I couldn't find anything about getting around Chrome's client side security.

[edit]

http://blog.securitee.org/?p=37

It is a relatively new feature, and I managed to find some documentation that mirrored what I discovered, the aim is to get the word out about new security features in Chrome to watch out for and the proper techniques required to get around them.

[/edit]

Edited December 2, 2011 by TehFallen

digip · December 2, 2011

Some of the ones I've used in the past, are just in general looking at search boxes and input forms on sites. Logins, search queries, etc, are the most common and easiest to find. Persistent XSS, such as in a comment on a forum or someones blog, is generally a lot harder.

A quick test I use a lot on any site with a search form, is to enter the following and see what happens.

'"/&gt;&lt;some code here&gt;&lt;input type="text"

If its vulnerable to html injection it, you should get an extra input box without triggering anything looking for XSS. Its also possible the extra input box is all that is injectable, and not necessarily vulnerable to inserting javascript. When that happens, usually all you can do is insert images, or even CSS, which can let you deface a page with your own image and hide everything else on the page.

When html can be inserted and a script tag doesn't work, you have to figure out other ways to bypass filtering. Some sites filter by specific keywords and tags, and not by html entities themselves, which is where they get tripped up using filters for

&lt;script&gt; vs &lt;scri+pt&gt;

and escaping certain characters like

&lt; &gt; ' " ; etc

I've seen where sites remove both script and + signs, but when combined, they remove the + sign, leaving the script then intact for execution, since it didn't initially meet the filtering requirements.

The real trick is persistent XSS, vs only what you would see in trying to find the holes that may only be visible to you during your session. If the form in use allows get vs post, then you can cause visitors to trigger the XSS remotely as well, via inserting a full URL with the XSS attached to the url, then getting someone, like an admin, to click it, sending back the cookies for a login session, etc. I've managed to insert and overlay entire pages with clones of the site, but with my own forms, that can then phish the login to the legitimate site. In doing so, I always notify the site owners though, once I have a POC working. I even got offered a job from someone in showing them what was possible due to their poor filtering of XSS appended to the URL of their site, but I'm not a programmer or security consultant, and only dabble with this stuff. I know enough to know I don't know it all, and try keep myself out of trouble.

Edited December 2, 2011 by digip

TehFallen · December 2, 2011

I recognize all that, I've had my fair share of experience in it. There are several sites I routinely checkup on once a year or so for the admins as an unofficial security advisor of sorts, all because I pointed out holes in their site. I by no means claim to know a lot about it, I'm just a script kiddie, but your responses do not seem to address the original post. The original post is a method used to circumvent security measures google chrome has placed for non-persistent xss attacks. If you ignore such things, and yourself use, say firefox, or god forbid internet explorer, and you create an xss attack out of a search page and then hop on the sites chat or forum or wherever and send that link out you're screwed if they're using google chrome. Now yes, the site I found this on has already been notified of their vulnerabilities (as well as an SQL injection issue on the same page with the same inputs) and I also refuse to give the name of the site out. But I came here to post an interesting workaround for a NEW security implementation in modern day browsers. My post had nothing to do with persistent xss, it also had nothing to do with escaping Server side security. That's an entirely different story. My post addressed the issue that google chrome filters out javascript it sees in the page's request. Please read it kind sir. I appreciate the thought but I feel like you've gotten off topic.

[edit]

Quick testing shows that Chromes anti-xss measures even work against things like onload handlers of images as you had suggested, so the attack '><img onload="javascript:alert();" src= /><input type=' wouldn't work, the server might let it through but if the client you're trying to attack has google chrome it refuses to run the script.

[/edit]

Edited December 2, 2011 by TehFallen

digip · December 2, 2011

Ok. So do this, add the following, make sure the img tag does not error out, needs a real image url, or chrome ignores it like as if its a broken script. If the url for the image doesn't work, then chrome will never do the "onload" event, since onload has not fired due to no image loading.

'&gt;&lt;img src="http://s3.amazonaws.com/kym-assets/photos/images/original/000/096/044/trollface.jpg" onLoad="javascript:alert(1);" /&gt;&lt;input type="text"

Just tested it, and chrome DOES render it, so not sure what you are doing, unless the site is not showing the output.

;)

ps - Most browsers do ignore the onload event for input boxes these days, which is why I use the img tag.

Edited December 7, 2011 by digip

TehFallen · December 2, 2011

Maybe you need to update your chrome...doesn't work for me, the image loads but the console still gives the "Refused to execute a JavaScript script. Source code of script found within request." error, refusing to execute the javascript. I'm running an up to date (15.0.874.121 m) windows 7 version, I'll boot up debian here in minute and try that out as well. Now there is a header ("X-XSS-Protection: 0") the server can send telling chrome to disable this feature, maybe your testing site is telling chrome not to worry about xss? Chrome apparently be started with an "--disable-xss-auditor" option to do this as well.

Take a look at this http://www.opensource.apple.com/source/WebCore/WebCore-658.28/page/XSSAuditor.cpp

Edited December 2, 2011 by TehFallen

digip · December 2, 2011

Maybe you need to update your chrome...doesn't work for me, the image loads but the console still gives the "Refused to execute a JavaScript script. Source code of script found within request." error, refusing to execute the javascript. I'm running an up to date (15.0.874.121 m) windows 7 version, I'll boot up debian here in minute and try that out as well. Now there is a flag the server can send telling chrome to disable this feature, maybe your testing site is telling chrome not to worry about xss?

I'll download the latest and see whats what. You are probably right, and I should update my Chrome to latest version.

digip · December 2, 2011

Well, you are right about it blocking the javascript:code in the img tag. Its also blocking the code you put in your first post, unless I missed the syntax, it is blocking that as well. I'm now running version "15.0.874.121" but I don't see an "m" in my description of the build.

You can test it here on my server if you want but I can't get your or my code to execute now. I've tried with php $_post forms and $_get forms, same results in both.

http://digip.info/xss.php

Thats a good thing though, that Chrome is doing this. I see the "Refused to execute a JavaScript script. Source code of script found within request." in the console too, so it would seem there would have to be another way to combine a XSS attack that would be needed. Can you paste the entire code and syntax as needs to be pasted to make this work, so I can test it? Just not getting it to work from your example above.

TehFallen · December 2, 2011

I'm not at home right now where my code is at but I'll get it up later tonight for sure. It's worked every time for me but I've only been trying it on one site. I'm impressed that Chrome is doing this as well, though in the end it should be the site admins responsibilities, it's nice to know we're helping cover up their shortcomings.

[edit]

I get a 403 on your site so can't test it.

[/edit]

Edited December 2, 2011 by TehFallen

digip · December 2, 2011

I'm not at home right now where my code is at but I'll get it up later tonight for sure. It's worked every time for me but I've only been trying it on one site. I'm impressed that Chrome is doing this as well, though in the end it should be the site admins responsibilities, it's nice to know we're helping cover up their shortcomings.

[edit]

I get a 403 on your site so can't test it.

[/edit]

Sorry about that, probably your IP subnet being blocked. If its in TX, then I just added that one IP to my allow list should work now.

TehFallen · December 2, 2011

Sorry about that, probably your IP subnet being blocked. If its in TX, then I just added that one IP to my allow list should work now.

I'm actually at an University in Arkansas, must be similar subnet, it lets me in now.

Try out this test site I threw together: http://pi.webuda.com/hello.php

Here's the code:

&lt;html&gt;
&lt;head&gt;
&lt;title&gt;Hello&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;?php
$fn = $_POST['fn'];
$ln = $_POST['ln'];
if($fn==NULL || $ln==NULL)echo "&lt;form action='hello.php' method='post'&gt;First Name: &lt;input name='fn' type='text'/&gt;&lt;br/&gt;Last Name: &lt;input name='ln' type='text'/&gt;&lt;br/&gt;&lt;input type='submit' value='Go'/&gt;&lt;/form&gt;";
else echo "Hello " . $fn . " " . $ln . "!";
?&gt;
&lt;/body&gt;
&lt;/html&gt;

The way you exploit it would be set your first name as

&lt;script&gt;/*

and your last name as

*/alert();&lt;/script&gt;

if you do this you should see an alert box.

digip · December 3, 2011

The way your php file is setup, you don't even need the comments. Just do

&lt;script&gt;alert(1);

in the first name box and

&lt;/script&gt;

in the second box, and it works. Reason is your form is somewhere concatenating and echoing back the content as html, leaving the javascript intact, but Chrome sees it as two different things, and your site is making them one, so Chromes filter doesn't work with it beign invalid code probably.

I'd like to find a way to do this, with a single input box, or even with a simple form that uses GET vs POST, so it can be manipulated in the URL itself. From what I have seen so far, google has done a great job with their built in XSS fix. Not bullet proof, given the scenario you have on your site with two inputs being concatenated, but none the less, thumbs up to Chrome for parsing the attempts and removing them from the http request.

edit: looks like someone has seen and done this, using the two variable method.

http://blog.securitee.org/?p=37

I'm still wondering if its possible to to trick a page into doing this with a single input/variable via chrome though. Doesn't look like it will be possible without two variables being concatenated though, and knowing google, they could plug that quickly.

Edited December 3, 2011 by digip

TehFallen · December 3, 2011

Yeah, mine's a simple setup, but in most real world applications the comments are needed to block out interfering HTML. As for doing it in a single line, it's all open source, we just gotta reverse engineer it and figure something out, I haven't tried embedding source code yet such as <script src="malicious.js"/> that might work.

digip · December 3, 2011

Yeah, mine's a simple setup, but in most real world applications the comments are needed to block out interfering HTML. As for doing it in a single line, it's all open source, we just gotta reverse engineer it and figure something out, I haven't tried embedding source code yet such as <script src="malicious.js"/> that might work.

I tried that already yesterday. Chrome filteres it out, unless the script is of same origin, as in, already exists on the same domain. Once it sees a foreign host, it blocks it. You can test it with http://digip.info/xss.php using both http://digip.info/foo and http://www.ticktockcomputers.com/foo. The first one works because of same site origin, chrome lets it through, second doesn't as its recognized in the GET request retrieving from a foreign domain and potentially XSS.

If you found a way to upload files on the site, that defeated the need for reflected XSS and you could just use persistent XSS or upload a shell and do anything at that point, which doesn't need XSS if you have root.

Sign In

Xss Attacks

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members