[Owasp-leaders] OWASP DOM based XSS definition, which looked a little off

Tim tim.morgan at owasp.org
Tue Oct 22 13:39:18 UTC 2013


Hi guys,

I think the focus here needs to be on where the vulnerability lies.
That is, does the coding mistake exist in server-side code, or
client-side code?  If the injection occurs because server-side code
generated HTML without properly encoding potentially malicious
strings, then it is clearly a server-side issue and is either a
reflected or stored XSS problem.

DOM-based XSS exists when JavaScript[1] is at fault.  JavaScript pulls
in potentially untrusted data from *somewhere*, and then either
generates new HTML using document.write, .innerHTML, etc, OR it uses
eval() unsafely.  It doesn't matter so much where the malicious data
came from (URL parameter, hash fragment, ...) or how it got there
(read directly from URL or passed through the server first and
embedded in the page safely only to be misused by the JavaScript).

So, to summarize: don't make the common mistake of focusing on how
malicious data came in to the application when it comes to classifying
injection flaws.  Injection flaws exist because how data is embedded
in a particular syntax.  The problem is with lack of encoding, not
lack of input validation, so focus on what piece of code performed the
embedding.

HTH,
tim


1. Doesn't necessarily need to be JavaScript... any client-side script
with equivalent capabilities.




On Tue, Oct 22, 2013 at 09:07:34AM -0400, Jeremy Long wrote:
> Serg,
> 
> I completely agree with you (and yes, I helped write some of that page and
> when I raised my earlier concerns about this people ignored me). The term
> DOM-based XSS got muddied over the years to really be discussing XSS caused
> by DOM manipulation (i.e. where the original insertion didn't necessarily
> cause the XSS, but rather its later use by JavaScript to manipulate the
> DOM) and even in some cases people use it to describe any nested/complex
> injection points that are injecting into JavaScript contexts.
> 
> I agree with you that what the page is describing isn't 100% true DOM Based
> XSS; but it does have a lot of good advice and helps people understand some
> of the more complicated nuances of XSS.
> 
> --Jeremy
> 
> 
> On Tue, Oct 22, 2013 at 8:40 AM, Serg <serg at owasp.org> wrote:
> 
> > Achim
> >
> > Actually I believe you've just described Reflected XSS.
> >
> > This is my take on it, I haven't seen any 'sane' explanation of this
> > anywhere yet... Here goes.
> >
> > Whether it's run inside the <script> tag or as an attribute/event handler
> > or anywhere else is largely irrelevant I think. The attack is not sent in
> > the request and it is not reflected in the response. This is the main
> > point. Using the other description, all XSS attacks are both: DOM and
> > Reflected. Which is fine, it's only names, but why do we have two
> > definition then?
> >
> > DOM based XSS, my understanding, is an attack that is not* *sent to the
> > server. Hence the fragments... using '#js_here' string will send the first
> > part of the request to the server, but not the fragment...
> >
> >
> > my 2c
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Oct 22, 2013 at 11:16 PM, Achim <achim at owasp.org> wrote:
> >
> >> Hi Serg,
> >>
> >> your 50% correct ;-)
> >>
> >> your example
> >>     http://www.some.site/page.html?default=xss_attack_here
> >>
> >> can serve for both, reflected XSS and/or DOM-based XSS.
> >> It's reflected as you described if the server sends it back and then will
> >> be
> >> rendered, but it can also be DOM-based if the send back page makes use of
> >> 'xss_attack_here' in it's scripts.
> >>
> >> In both cases it's entirely processed in the browser.
> >>
> >> Does this make sense?
> >> Achim
> >>
> >>
> >>
> >> Am 22.10.2013 13:05, schrieb Serg:
> >> > Hi All
> >> >
> >> > I've recently had a look at the OWASP DOM based XSS definition, which
> >> > looked a little off.
> >> >
> >> > The TL;DR version: the DOM based XSS definition according to OWASP (
> >> > https://www.owasp.org/index.php/DOM_Based_XSS) is only 50% correct (or
> >> the
> >> > pessimistic view - 50% wrong) and misleading.
> >> >
> >> > I am basing this on the 'Definition' examples (
> >> > https://www.owasp.org/index.php/DOM_Based_XSS), not the 'Advanced
> >> > Techniques and Derivatives' section.
> >> >
> >> > The first part of this document is incorrect.
> >> >
> >> > In layman's terms, the Reflected XSS, request/JS is first sent to the
> >> > server, it is then reflected, as is, in the response, hence the name.
> >> >
> >> > Example:
> >> >
> >> > http://www.some.site/page.html?default=xss_attack_here
> >> >
> >> > Since the query string gets sent to the server and reflected back, this
> >> is
> >> > a Reflected XSS, not DOM-based.
> >> >
> >> > The 'xss_attack_here' part is irrelevant here. As long as it is sent to
> >> the
> >> > server and reflected back, it's a Reflected XSS vulnerability. Whether
> >> it
> >> > runs in DOM or not is irrelevant, technically everything runs in DOM...
> >> >
> >> > My understanding of DOM based XSS, is: it is processed entirely in the
> >> web
> >> > browser, the request with XSS payload is not sent to the server.
> >> >
> >> > As far as I know, the only way to achieve that is to use fragment
> >> > identifiers, the part of the URL after the '#' (including '#') is not
> >> sent
> >> > to the server as part of the request.
> >> >
> >> > Based on that, I am fairly certain that the current OWASP definition (
> >> > https://www.owasp.org/index.php/DOM_Based_XSS) is wrong and misleading.
> >> >
> >> >
> >> > Thoughts?
> >>
> >>
> >
> >
> > --
> > Serg
> >
> > _______________________________________________
> > OWASP-Leaders mailing list
> > OWASP-Leaders at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >
> >

> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders



More information about the OWASP-Leaders mailing list