[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] attribute based XSS
- From: "Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>
- Subject: Re: [WEB SECURITY] attribute based XSS
- Date: Sat, 28 Jul 2007 18:11:18 -0700
------=_Part_14639_20816041.1185671478562
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<comments inline>
On 7/27/07, Brian Eaton <eaton.lists@gmail.com> wrote:
>
> I've been trying to get involved in a discussion about "attribute
> based cross-site-scripting" on Jeremiah's blog, but for some reason
> convincing blogger to let me post a decent XSS example has been kind
> of tricky.
>
> Here's Jeremiah's original post:
>
>
> http://jeremiahgrossman.blogspot.com/2007/07/attribute-based-cross-site-scripting.html
>
> The point I tried (and completely failed) to make on the blog is that
> using HTML entities as an anti-XSS measure does not work if the
> attacker controlled data lands in an HTML attribute that the browser
> interprets as a URI.
That is not entirely true. In terms of escaping -- if you are trying to
break
out of the enquoted string and transparently execute code, you have
properly enforced a boundary between function and data.
The hyperlinked-attack vector, manipulating URI's that a user could
click on, is a social-engineering attack vector in my book. Certainly
valid and legitimate, but one I tend to pay less attention to compared
to transparent code execution.
Thank you for brining that overlook to my attention though.
For example, consider an application that puts attacker controlled
> data in an href tag:
>
> <a href="ATTACKERCONTROLLED">blah</a>
>
> The attacker could achieve XSS with this by creating code like this:
>
> <a href="javascript:alert('xss')">blah</a>
>
> The normal anti-XSS measure of entity encoding does not work to stop
> the XSS. For example, firefox 2.0.0.5 (and probably other browsers,
> I'm too lazy to check right now) will execute the javascript even if
> every single character is HTML entity encoded:
>
> <a
> href="javascript:alert('xss')">foo</a>
> I think a more appropriate mitigation here is URI encoding, but that
> has to be done carefully to avoid changing the semantics of any good
> URIs you're trying to embed.
Sure. Properly escaping the URI is the way to go here. Unfortunately
there are some webservers and pieces of software that do not properly
un-escape the URI so that in itself can lead to issues...
Per Stefan's comments in the thread --
Just because encoding is *supported* by the browser does not mean
that it is "a joke". That's a dangerously myopic way to view that.
Sure sure, understanding why encoding came about in the first place
is important. But understanding what target parsers interpret what
encoding types, and particulary layered encoding types, and the
rising issue with transcoding and UTF-8 normalizations for database
searching on international language sites...the list goes on.
It's more than simply defeating the "javascript:" blacklist. The
notion of a blacklist like that is the joke.
Anyway, it is also a legitimate attack vector if that's how one
bypasses someone's explicitly defined "security controls".
--
Arian Evans
software security stuff
------=_Part_14639_20816041.1185671478562
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<comments inline><br><br>
<div><span class="gmail_quote">On 7/27/07, <b class="gmail_sendername">Brian Eaton</b> <<a href="mailto:eaton.lists@gmail.com";>eaton.lists@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I've been trying to get involved in a discussion about "attribute<br>based cross-site-scripting" on Jeremiah's blog, but for some reason
<br>convincing blogger to let me post a decent XSS example has been kind<br>of tricky.<br><br>Here's Jeremiah's original post:<br><br><a href="http://jeremiahgrossman.blogspot.com/2007/07/attribute-based-cross-site-scripting.html";>
http://jeremiahgrossman.blogspot.com/2007/07/attribute-based-cross-site-scripting.html</a><br><br>The point I tried (and completely failed) to make on the blog is that<br>using HTML entities as an anti-XSS measure does not work if the
<br>attacker controlled data lands in an HTML attribute that the browser<br>interprets as a URI.</blockquote>
<div> </div>
<div> </div>
<div>That is not entirely true. In terms of escaping -- if you are trying to break</div>
<div>out of the enquoted string and transparently execute code, you have</div>
<div>properly enforced a boundary between function and data.</div>
<div> </div>
<div>The hyperlinked-attack vector, manipulating URI's that a user could</div>
<div>click on, is a social-engineering attack vector in my book. Certainly</div>
<div>valid and legitimate, but one I tend to pay less attention to compared</div>
<div>to transparent code execution.</div>
<div> </div>
<div>Thank you for brining that overlook to my attention though.</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">For example, consider an application that puts attacker controlled<br>data in an href tag:<br><br><a href="ATTACKERCONTROLLED">blah</a>
<br><br>The attacker could achieve XSS with this by creating code like this:<br><br><a href="javascript:alert('xss')">blah</a><br><br>The normal anti-XSS measure of entity encoding does not work to stop
<br>the XSS. For example, firefox <a href="http://2.0.0.5";>2.0.0.5</a> (and probably other browsers,<br>I'm too lazy to check right now) will execute the javascript even if<br>every single character is HTML entity encoded:
<br><br><a href="&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;&#39;&#120;&#115;&#115;&#39;&#41;">foo</a>
</blockquote>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I think a more appropriate mitigation here is URI encoding, but that<br>has to be done carefully to avoid changing the semantics of any good
<br>URIs you're trying to embed.</blockquote>
<div> </div>
<div>
<div>Sure. Properly escaping the URI is the way to go here. Unfortunately</div>
<div>there are some webservers and pieces of software that do not properly</div>
<div>un-escape the URI so that in itself can lead to issues...<br> </div>
<div>Per Stefan's comments in the thread --</div>
<div> </div>
<div>Just because encoding is *supported* by the browser does not mean</div>
<div>that it is "a joke". That's a dangerously myopic way to view that.</div>
<div> </div>
<div>Sure sure, understanding why encoding came about in the first place</div>
<div>is important. But understanding what target parsers interpret what</div>
<div>encoding types, and particulary layered encoding types, and the</div>
<div>rising issue with transcoding and UTF-8 normalizations for database</div>
<div>searching on international language sites...the list goes on.</div>
<div> </div>
<div>It's more than simply defeating the "javascript:" blacklist. The</div>
<div>notion of a blacklist like that is the joke.</div>
<div> </div>
<div>Anyway, it is also a legitimate attack vector if that's how one</div>
<div>bypasses someone's explicitly defined "security controls".</div>
<div> </div>
<div>-- <br>Arian Evans<br>software security stuff </div></div></div>
------=_Part_14639_20816041.1185671478562--
Brought to you by http://www.webappsec.org
Search this site
|