[Owasp-leaders] OWASP DOM based XSS definition, which looked a little off
Eoin Keary
eoin.keary at owasp.org
Wed Oct 23 20:02:01 UTC 2013
Stored DOM.....
In a cookie for the entire session.
Eoin Keary
Owasp Global Board
+353 87 977 2988
On 23 Oct 2013, at 19:00, "Tobias Glemser" <tobias.glemser at owasp.org> wrote:
> Hi,
>
>> If you take a look at my link, we actually identified five :) And then
> there is
>> universal XSS (in browser plugins/extensions). So maybe six.
> I did. But I did not point out why "Source/Sink: Browser" is not necessary
> IMHO in my last mail, sorry about that. For me it's just getting to
> "complex" without having a clear benefit to me.
>
> For me "Stored" or persistent means the Payload is stored somewhere and is
> loaded each time the user hits the application. This could be
> - the application database
> - Browser DB
> - Cookie
> - ...
>
> Of course it's important to know where it is stored. But a developer advice
> would be "sanitise your data each time you store it, client or serverside"
> and "if you load stored data you want to sanitise again..".
>
> So if you would change the definition for Stored from "Untrusted data is
> stored server side" to "Untrusted data is stored" it would be just four :)
>
>> I would call that "remote code execution".
> Obviously we all agree, it's not XSS :) If we take the Top10 wording as a
> reference I would call it "code injection".
>
> Best
>
> Tobias
>
>> -----Ursprüngliche Nachricht-----
>> Von: Erlend Oftedal [mailto:erlend.oftedal at owasp.org]
>> Gesendet: Mittwoch, 23. Oktober 2013 19:43
>> An: Tobias Glemser
>> Cc: owasp-leaders at lists.owasp.org
>> Betreff: SV: [Owasp-leaders] OWASP DOM based XSS definition, which
>> looked a little off [ Z1 UNGESICHERT ]
>>
>> If you take a look at my link, we actually identified five :) And then
> there is
>> universal XSS (in browser plugins/extensions). So maybe six.
>>
>> Erlend
>> Fra: Tobias Glemser
>> Sendt: 23.10.2013 17:38
>> Til: Erlend Oftedal
>> Kopi: owasp-leaders at lists.owasp.org
>> Emne: AW: [Owasp-leaders] OWASP DOM based XSS definition, which
>> looked a little off 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] Im Auftrag von Erlend Oftedal
>>> Gesendet: Mittwoch, 23. Oktober 2013 12:08
>>> An: Neil Smithline
>>> Cc: 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>
>>> 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> 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>
>>> 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
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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