[WEB SECURITY] The future of XSS attacks

MustLive mustlive at websecurity.com.ua
Sun Jan 24 12:43:03 EST 2010


Hello MaXe!

Thank you for your comments at my site. It's important for me to hear
thoughts of other security professionals on these topics.

> I've replied to your blog about "MouseOverJacking" (fancy) and The
> Future of XSS Attacks.

Yesterday I've already wrote a comment to your comment about The future of
XSS attacks (http://websecurity.com.ua/3878/) and I'd write comment to your
another comment soon. And there was a question to you: what do you think
about using of MouseOverJacking instead of expression() and -moz-binding for
conducting XSS attacks as cross-browser solution (which works in any
browser, including new versions of Firefox and IE)?

I agreed with you that Content Security Policy can do a good work against
XSS (and also CSRF) attacks. The idea itself is interesting and promising.
But as I mentioned, there is a hole in current Mozilla’s CSP implementation.

It's solution for future versions of Firefox browser and we’ll see how it’ll
be implemented in the next versions of Firefox (and also we'll see how other
browser vendors will act with CSP, because there are many browsers in the
world, especially developers of the most popular browsers). In Firefox 3.0
and 3.5 it's not implemented. I heard that it'll be implemented only in
Firefox 3.7. So what about new Firefox 3.6, did Mozilla add CSP to it (at
least partly) or we need to wait for 3.7? First I need to see CSP in action
to say if it really can help to solve issues with XSS and CSRF.

> In the following reply examples of code was filtered away:

It's WordPress's filters :-).

> <img src="x:x" onerror="alert(0)" /> is just one of my
> favorite working examples of getting an alert box still."

Yes, I also love onerror vector of attack. But as I mentioned in my article
about The future of XSS attacks, it not happens too often in real world, so
other vectors of attack (via style property) are used in the most cases. And
due to situation with Firefox 3 and IE8 I gave my own solution - I propose
to use MouseOverJacking technique for wide variety of XSS attacks.

> Instead of filtering / removing tages like you do on your website

It's not me, it's WordPress ;-). But I got used to these WP filters very
quickly after I became using it in summer 2006. You can also get used to
them, it's just needed to remember about WP behaviour when posting to sites
on WP.

In my own practice I'm using complete removing of the tags. It's my personal
best practice (as web developer I used this approach from begging of 2002),
so behavior of WP is similar to my own approach. But I must admit, that
besides removing tags, WP is also using htmlspecialchars and htmlentities
(in different parts of engine).

> Websites are built by humanoids and
> they are exploited by humanoids due to nothing can be created 100% and
> neither 100% secure, however it is possible to follow "best coding
> practice" which I endorse you to do as well.

Yes, I use best coding practices, especially my own (based on my own
experience). But the most important to make your web application (web site)
secure is to do security audit of it.

Security through obscurity will not help anyone, only finding and fixing 
holes can help. It's what I always do and security audit it's what I'm 
recommending to everyone. Every web developer makes holes, so they need to 
be found and fixed. No need to blame Chinese hackers in making Aurora 
operations against you, just always do security audit and sleep tight.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "MaXe" <owasp at intern0t.net>
To: "MustLive" <mustlive at websecurity.com.ua>
Cc: <websecurity at webappsec.org>
Sent: Saturday, January 23, 2010 3:19 PM
Subject: Re: [WEB SECURITY] The future of XSS attacks


> MustLive wrote:
>> Hello participants of Mailing List.
>>
>> Yesterday I wrote English version of my article The future of XSS attacks
>> (http://websecurity.com.ua/3878/), which you can read if you
>> interested in
>> this topic.
>>
>> In the article I talked about Cross-Site Scripting attacks where it’s
>> not possible to use any tags and angle brackets. I listed attack
>> vectors which can be used in this case (automated and non-automated).
>> And wrote about current situation with modern browsers: in 2008 in
>> Firefox 3 possibility of attack via -moz-binding was removed (partly)
>> and in IE 8, which released at beginning of 2009, support of
>> expression() was removed.
>>
>> So I proposed my cross-browser solution for conducting of automated XSS
>> attacks in such conditions (when it’s not possible to use any tags and
>> angle
>> brackets) - with using of MouseOverJacking technique, which I already
>> wrote
>> about (http://websecurity.com.ua/3814/).
>>
>> You can read the article The future of XSS attacks at my site:
>> http://websecurity.com.ua/3878/
>>
>> Best wishes & regards,
>> MustLive
>> Administrator of Websecurity web site
>> http://websecurity.com.ua
>>
>>
>> ----------------------------------------------------------------------------
>>
>> Join us on IRC: irc.freenode.net #webappsec
>>
>> Have a question? Search The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/archive/
>>
>> Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS
>> Feed]
>>
>> Join WASC on LinkedIn
>> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>>
>>
> Hi MustLive,
>
>
> I've replied to your blog about "MouseOverJacking" (fancy) and The
> Future of XSS Attacks.
>
> In the following reply examples of code was filtered away: (text inside
> hard brackets [] were filtered away)
> "In cases where [ <script> ] has only been “blocked” by f.ex.
> preg_replace (seen in many cases), [ <img src="x:x" onerror="alert(0)"
> /> ] is just one of my favorite working examples of getting an alert box
> still."
>
> Instead of filtering / removing tages like you do on your website, using
> htmlspecialchars($var) or htmlentities($var, ENT_QUOTES) is most likely
> a better implementation against Cross-Site Scripting (if it is used
> correct) since it will also be easier to write code examples like I
> tried to. At www.php.net you can read more what the above functions do,
> in short they convert html characters to their html entitiy, " becomes
> f.ex. " which can't be used for Cross Site Scripting in this case.
>
> The problem where the error / vulnerability lies are the users
> (humanoids) including developers. Websites are built by humanoids and
> they are exploited by humanoids due to nothing can be created 100% and
> neither 100% secure, however it is possible to follow "best coding
> practice" which I endorse you to do as well.
>
>
> Best regards,
> MaXe - Founder of InterN0T


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list