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

Giorgio Fedon giorgio.fedon at owasp.org
Wed Oct 23 19:18:51 UTC 2013


Hi,

from my point of view DOMXss and standard XSS are well described in this
thread.

I just would like to add my contribution with the focus on the fact that
a standard XSS is generated by tampering or injecting unsanitized data
in the web server response versus the DOMXss that is due to an abuse of
a vulnerability in the javascript code itself.

My definitions:

DomXss is the execution of arbitrary javascript code forced by an
attacker in the context of a website due to the abuse of a vulnerability
in the javascript code loaded originally by that website. Attacker is
thus able to change, modify or completely subvert the code execution
flow of the vulnerable Javascript code.

Standard XSS is the execution of arbitrary javascript code forced by an
attacker in the context of a website due to the abuse of the lack of
sanitization controls in the generation and delivery to the browser of
the web server response. The Attacker is thus able to inject malicious
XSS payload data in the Web server response, and that data in not
sanitized at any stage before reaching the browser layout engine. Note:
also builtin filters and browser security plugins are a Sanitization Stage.

Stored vs Non Stored or better Persistence vs non Persistent is a
property of both and depends on a number of factors that let the
automatic re-injection of the payload in the vulnerable response area,
or in the vulnerable function.


On 10/23/2013 07:41 PM, Erlend Oftedal wrote:
> I would call that "remote code execution".
>
> Erlend
> ------------------------------------------------------------------------
> Fra: Colin Watson <mailto:colin.watson at owasp.org>
> Sendt: 23.10.2013 18:44
> Til: Tobias Glemser <mailto:tobias.glemser at owasp.org>
> Kopi: Erlend Oftedal <mailto:erlend.oftedal at owasp.org>;
> owasp-leaders at lists.owasp.org <mailto:owasp-leaders at lists.owasp.org>
> Emne: Re: [Owasp-leaders] OWASP DOM based XSS definition, which looked
> a little off
>
> For completeness, are we happy that JavaScript injection into
> server-side application code (e.g. node.js) is best described as
> "command injection" and not any sort of XSS?
>
> Colin
>
>
> On 23 October 2013 16:38, Tobias Glemser <tobias.glemser at owasp.org
> <mailto:tobias.glemser at owasp.org>> wrote:
>
>     Erlend,
>
>     > The gist of it is, that reflected/persisted is about source, and
>     DOM-based
>     is
>     > more about sink.
>     +1
>
>     I'm telling since years we got:
>      - reflected XSS server side
>      - reflected XSS client side ("DOM-based")
>      - persistent XSS server side
>      - persistent XSS client side ("DOM-based")
>
>     So it's four and not three types (like claimed over the years even
>     by me ;)
>
>     Best
>
>     Tobias
>
>
>     > -----Ursprüngliche Nachricht-----
>     > Von: owasp-leaders-bounces at lists.owasp.org
>     <mailto:owasp-leaders-bounces at lists.owasp.org>
>     [mailto:owasp-leaders- <mailto:owasp-leaders->
>     > bounces at lists.owasp.org <mailto:bounces at lists.owasp.org>] Im
>     Auftrag von Erlend Oftedal
>     > Gesendet: Mittwoch, 23. Oktober 2013 12:08
>     > An: Neil Smithline
>     > Cc: owasp-leaders at lists.owasp.org
>     <mailto:owasp-leaders at lists.owasp.org>
>     > Betreff: Re: [Owasp-leaders] OWASP DOM based XSS definition, which
>     > looked a little off [ Z1 UNGESICHERT ]
>     >
>     > We had a small discussion on twitter yesterday with amongst others
>     > @wisecwisec (the author of the domxsswiki and Dominator Pro).
>     > I tried to summarize the discussion in this small table:
>     > http://erlend.oftedal.no/blog/research/xss/index.html
>     >
>     >
>     > The gist of it is, that reflected/persisted is about source, and
>     DOM-based
>     is
>     > more about sink. So you can combine them and end up with things like
>     > reflected DOM-based XSS or persistend server-generated XSS.
>     >
>     > Erlend
>     >
>     >
>     > On Wed, Oct 23, 2013 at 4:56 AM, Neil Smithline
>     <neil.smithline at owasp.org <mailto:neil.smithline at owasp.org>>
>     > wrote:
>     >
>     >
>     >       For kicks I googled DOM XSS. The first three links were to
>     OWASP (go
>     > OWASP!). I ignnored those as I consider them tainted references.
>     The next
>     > four links were:
>     >
>     >       *       http://j.mp/1626ZMW
>     >       *       http://j.mp/16ry5iN
>     >
>     >       *       http://j.mp/1ccJUMp
>     >
>     >       *       http://j.mp/He1yS8
>     >
>     >
>     >       At least to me, all of the references seem to say that DOM
>     XSS is
>     > based on where in the browser the unsanitized data is used in a
>     risky
>     manner
>     > and not how the data got there. The last reference above is from the
>     > MediaWiki's development guide. It succinctly states:
>     >
>     >               This class of XSS is distinct from Reflective XSS
>     (type-1
>     XSS)
>     > and Stored XSS (type-2 XSS), since the server is not returning
>     executable
>     > JavaScript to the browser. Instead, data that has been sanitized
>     by the
>     > server, or possibly never sent to the server, is converted to
>     executable
>     > JavaScript by the existing code running on the page.
>     >
>     >
>     >
>     >
>     >       Neil
>     >
>     >
>     >
>     >       On Tue, Oct 22, 2013 at 8:38 PM, johanna curiel curiel
>     > <johanna.curiel at owasp.org <mailto:johanna.curiel at owasp.org>> wrote:
>     >
>     >
>     >               Hi Serg
>     >
>     >
>     >               I'm going to read very careful your comments
>     before I  give
>     > my final humble opinion, but I think for sure that we should
>     take a look
>     on
>     > this since during the Mentor summit - Google summer of Code
>     which I had
>     > the opportunity to assist last weekend, a very respectful and
>     blackhat
>     > speaker this year mentioned to me that there is a lot of info in
>     the OWASP
>     > wiki that is not correct. You might have found this
>     issue,however I would
>     like
>     > to back up my info with good references and resources (that does
>     not take
>     > away what you have mentioned is correct)
>     >
>     >
>     >               regards
>     >
>     >
>     >
>     >               Johanna
>     >
>     >
>     >
>     >
>     >               On Tue, Oct 22, 2013 at 7:05 AM, Serg
>     <serg at owasp.org <mailto:serg at owasp.org>>
>     > wrote:
>     >
>     >
>     >                       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
>     > <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
>     > <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
>     > <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
>     <mailto:OWASP-Leaders at lists.owasp.org>
>     >                      
>     https://lists.owasp.org/mailman/listinfo/owasp-
>     > leaders
>     >
>     >
>     >
>     >
>     >
>     >               _______________________________________________
>     >               OWASP-Leaders mailing list
>     >               OWASP-Leaders at lists.owasp.org
>     <mailto:OWASP-Leaders at lists.owasp.org>
>     >               https://lists.owasp.org/mailman/listinfo/owasp-leaders
>     >
>     >
>     >
>     >
>     >
>     >       _______________________________________________
>     >       OWASP-Leaders mailing list
>     >       OWASP-Leaders at lists.owasp.org
>     <mailto:OWASP-Leaders at lists.owasp.org>
>     >       https://lists.owasp.org/mailman/listinfo/owasp-leaders
>     >
>     >
>     >
>
>
>     _______________________________________________
>     OWASP-Leaders mailing list
>     OWASP-Leaders at lists.owasp.org <mailto: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


-- 
| Giorgio Fedon, Owasp Italy
|
| In Input Validation 
|            and Output Sanitization, 
|                                   We Trust
--
| Web: https://www.owasp.org/index.php/Italy
|_____________________________________________.



More information about the OWASP-Leaders mailing list