<div dir="ltr"><div>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?<br></div><div><br></div>
<div>Colin</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 23 October 2013 16:38, Tobias Glemser <span dir="ltr"><<a href="mailto:tobias.glemser@owasp.org" target="_blank">tobias.glemser@owasp.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Erlend,<br>
<br>
> The gist of it is, that reflected/persisted is about source, and DOM-based<br>
is<br>
> more about sink.<br>
+1<br>
<br>
I'm telling since years we got:<br>
 - reflected XSS server side<br>
 - reflected XSS client side ("DOM-based")<br>
 - persistent XSS server side<br>
 - persistent XSS client side ("DOM-based")<br>
<br>
So it's four and not three types (like claimed over the years even by me ;)<br>
<br>
Best<br>
<br>
Tobias<br>
<br>
<br>
> -----Ursprüngliche Nachricht-----<br>
> Von: <a href="mailto:owasp-leaders-bounces@lists.owasp.org">owasp-leaders-bounces@lists.owasp.org</a> [mailto:<a href="mailto:owasp-leaders-">owasp-leaders-</a><br>
> <a href="mailto:bounces@lists.owasp.org">bounces@lists.owasp.org</a>] Im Auftrag von Erlend Oftedal<br>
> Gesendet: Mittwoch, 23. Oktober 2013 12:08<br>
> An: Neil Smithline<br>
> Cc: <a href="mailto:owasp-leaders@lists.owasp.org">owasp-leaders@lists.owasp.org</a><br>
> Betreff: Re: [Owasp-leaders] OWASP DOM based XSS definition, which<br>
> looked a little off [ Z1 UNGESICHERT ]<br>
><br>
> We had a small discussion on twitter yesterday with amongst others<br>
> @wisecwisec (the author of the domxsswiki and Dominator Pro).<br>
> I tried to summarize the discussion in this small table:<br>
> <a href="http://erlend.oftedal.no/blog/research/xss/index.html" target="_blank">http://erlend.oftedal.no/blog/research/xss/index.html</a><br>
><br>
><br>
> The gist of it is, that reflected/persisted is about source, and DOM-based<br>
is<br>
> more about sink. So you can combine them and end up with things like<br>
> reflected DOM-based XSS or persistend server-generated XSS.<br>
><br>
> Erlend<br>
><br>
><br>
> On Wed, Oct 23, 2013 at 4:56 AM, Neil Smithline <<a href="mailto:neil.smithline@owasp.org">neil.smithline@owasp.org</a>><br>
> wrote:<br>
><br>
><br>
>       For kicks I googled DOM XSS. The first three links were to OWASP (go<br>
> OWASP!). I ignnored those as I consider them tainted references. The next<br>
> four links were:<br>
><br>
>       *       <a href="http://j.mp/1626ZMW" target="_blank">http://j.mp/1626ZMW</a><br>
>       *       <a href="http://j.mp/16ry5iN" target="_blank">http://j.mp/16ry5iN</a><br>
><br>
>       *       <a href="http://j.mp/1ccJUMp" target="_blank">http://j.mp/1ccJUMp</a><br>
><br>
>       *       <a href="http://j.mp/He1yS8" target="_blank">http://j.mp/He1yS8</a><br>
><br>
><br>
>       At least to me, all of the references seem to say that DOM XSS is<br>
> based on where in the browser the unsanitized data is used in a risky<br>
manner<br>
> and not how the data got there. The last reference above is from the<br>
> MediaWiki's development guide. It succinctly states:<br>
><br>
>               This class of XSS is distinct from Reflective XSS (type-1<br>
XSS)<br>
> and Stored XSS (type-2 XSS), since the server is not returning executable<br>
> JavaScript to the browser. Instead, data that has been sanitized by the<br>
> server, or possibly never sent to the server, is converted to executable<br>
> JavaScript by the existing code running on the page.<br>
><br>
><br>
><br>
><br>
>       Neil<br>
><br>
><br>
><br>
>       On Tue, Oct 22, 2013 at 8:38 PM, johanna curiel curiel<br>
> <<a href="mailto:johanna.curiel@owasp.org">johanna.curiel@owasp.org</a>> wrote:<br>
><br>
><br>
>               Hi Serg<br>
><br>
><br>
>               I'm going to read very careful your comments before I  give<br>
> my final humble opinion, but I think for sure that we should take a look<br>
on<br>
> this since during the Mentor summit - Google summer of Code which I had<br>
> the opportunity to assist last weekend, a very respectful and blackhat<br>
> speaker this year mentioned to me that there is a lot of info in the OWASP<br>
> wiki that is not correct. You might have found this issue,however I would<br>
like<br>
> to back up my info with good references and resources (that does not take<br>
> away what you have mentioned is correct)<br>
><br>
><br>
>               regards<br>
><br>
><br>
><br>
>               Johanna<br>
><br>
><br>
><br>
><br>
>               On Tue, Oct 22, 2013 at 7:05 AM, Serg <<a href="mailto:serg@owasp.org">serg@owasp.org</a>><br>
> wrote:<br>
><br>
><br>
>                       Hi All<br>
><br>
>                       I've recently had a look at the OWASP DOM based XSS<br>
> definition, which looked a little off.<br>
><br>
>                       The TL;DR version: the DOM based XSS definition<br>
> according to OWASP (<a href="https://www.owasp.org/index.php/DOM_Based_XSS" target="_blank">https://www.owasp.org/index.php/DOM_Based_XSS</a><br>
> <<a href="https://www.owasp.org/index.php/DOM_Based_XSS" target="_blank">https://www.owasp.org/index.php/DOM_Based_XSS</a>> ) is only 50% correct<br>
> (or the pessimistic view - 50% wrong) and misleading.<br>
><br>
>                       I am basing this on the 'Definition' examples<br>
> (<a href="https://www.owasp.org/index.php/DOM_Based_XSS" target="_blank">https://www.owasp.org/index.php/DOM_Based_XSS</a><br>
> <<a href="https://www.owasp.org/index.php/DOM_Based_XSS" target="_blank">https://www.owasp.org/index.php/DOM_Based_XSS</a>> ), not the<br>
> 'Advanced Techniques and Derivatives' section.<br>
><br>
><br>
>                       The first part of this document is incorrect.<br>
><br>
><br>
>                       In layman's terms, the Reflected XSS, request/JS is<br>
> first sent to the server, it is then reflected, as is, in the response,<br>
hence the<br>
> name.<br>
><br>
><br>
>                       Example:<br>
><br>
><br>
><br>
>       <a href="http://www.some.site/page.html?default=xss_attack_here" target="_blank">http://www.some.site/page.html?default=xss_attack_here</a><br>
><br>
>                       Since the query string gets sent to the server and<br>
> reflected back, this is a Reflected XSS, not DOM-based.<br>
><br>
><br>
>                       The 'xss_attack_here' part is irrelevant here. As<br>
long<br>
> as it is sent to the server and reflected back, it's a Reflected XSS<br>
vulnerability.<br>
> Whether it runs in DOM or not is irrelevant, technically everything runs<br>
in<br>
> DOM...<br>
><br>
><br>
>                       My understanding of DOM based XSS, is: it is<br>
> processed entirely in the web browser, the request with XSS payload is not<br>
> sent to the server.<br>
><br>
><br>
>                       As far as I know, the only way to achieve that is to<br>
use<br>
> fragment identifiers, the part of the URL after the '#' (including '#') is<br>
not sent<br>
> to the server as part of the request.<br>
><br>
><br>
>                       Based on that, I am fairly certain that the current<br>
> OWASP definition (<a href="https://www.owasp.org/index.php/DOM_Based_XSS" target="_blank">https://www.owasp.org/index.php/DOM_Based_XSS</a><br>
> <<a href="https://www.owasp.org/index.php/DOM_Based_XSS" target="_blank">https://www.owasp.org/index.php/DOM_Based_XSS</a>> ) is wrong and<br>
> misleading.<br>
><br>
><br>
><br>
><br>
><br>
>                       Thoughts?<br>
><br>
><br>
><br>
><br>
>                       --<br>
>                       Serg<br>
><br>
><br>
>       _______________________________________________<br>
>                       OWASP-Leaders mailing list<br>
>                       <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
>                       <a href="https://lists.owasp.org/mailman/listinfo/owasp-" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-</a><br>
> leaders<br>
><br>
><br>
><br>
><br>
><br>
>               _______________________________________________<br>
>               OWASP-Leaders mailing list<br>
>               <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
>               <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
><br>
><br>
><br>
><br>
><br>
>       _______________________________________________<br>
>       OWASP-Leaders mailing list<br>
>       <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
>       <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
><br>
><br>
><br>
<br>
<br>
_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
</blockquote></div><br></div></div>