<div dir="ltr">I do agree that mitigation happens at the sink, but the source is interesting. Why? Some developers do not have a clear distinction between trusted and untrusted data. For instance request headers, cookies etc. may or may not be treated as trusted data depending on the knowledge of the dev. Allthough I always suggest "encode by default", many devs apply "encode when needed", which is much more difficult to get right security wise.<div>
<br></div><div>Erlend</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 24, 2013 at 9:14 AM, Giorgio Fedon <span dir="ltr"><<a href="mailto:giorgio.fedon@owasp.org" target="_blank">giorgio.fedon@owasp.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with Eoin with an exception about DOMxss in a sense that is<br>
better to say that the sink or the dangerous function should be<br>
"sanitized". So sanitizing the sink I would say for the DOMxss case.<br>
<br>
Just making an example of a DOMxss case where output encoding is not<br>
possible. E.g. redirection to javascript:// that issue for location<br>
sinks is  remediated by whitelisting the allowed protocols and<br>
redirection domains.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 10/24/2013 08:58 AM, Eoin Keary wrote:<br>
> +1<br>
> Attack types help define risk, fair?<br>
> Mitigation is what is important; contextual output encoding.<br>
><br>
> Eoin Keary<br>
> Owasp Global Board<br>
> <a href="tel:%2B353%2087%20977%202988" value="+353879772988">+353 87 977 2988</a><br>
><br>
><br>
> On 24 Oct 2013, at 07:22, Erlend Oftedal <<a href="mailto:erlend.oftedal@owasp.org">erlend.oftedal@owasp.org</a>> wrote:<br>
><br>
>> I think the distinction between stored and. reflected is useful.<br>
>> Remember that stored xss can occur on completely different locations.<br>
>> Consider an attack where the attack string ends up in a web enabled log<br>
>> in the admin gui. So for stored, sink and source can be far from each<br>
>> other, while for reflected they are always found relatively close to<br>
>> each other in the code.<br>
>> Instead of talking about different types of XSS, from a defensive point<br>
>> of view, we need to be able to identify sources and sinks to mitigate<br>
>> with correct escaping. For reflected XSS, the source is the request.<br>
>> For a stored XSS, the source is the databases, files and other types of<br>
>> backend storage. Allthough it could also include web storage for<br>
>> DOM-based. And then there is pure DOM-based where the browser is the<br>
>> source.<br>
>> And next the sink is either server-generated HTML/JavaScript, while the<br>
>> sink is in JavaScript for all types of DOM-based.<br>
>><br>
>> Erlend<br>
>> Fra: Giorgio Fedon<br>
>> Sendt: 23.10.2013 23:25<br>
>> Til: Achim<br>
>> Kopi: <a href="mailto:owasp-leaders@lists.owasp.org">owasp-leaders@lists.owasp.org</a><br>
>> Emne: Re: [Owasp-leaders] OWASP DOM based XSS definition, which looked<br>
>> a little off<br>
>> On 10/23/2013 11:05 PM, Achim wrote:<br>
>>> opps, my point was not to stick on a single XSS definition, but on<br>
>>> reflected, persistent and DOM-based. As these are problems on different places.<br>
>>> All others are variants of these, as we know today.<br>
>> Ops I misunderstood. Sorry Achim.<br>
>><br>
>> However I think that the cathegories are:<br>
>><br>
>> - XSS or generic XSS<br>
>> - DomXSS<br>
>><br>
>> I would remove "stored" as a cathegory. Both can be non persistent or<br>
>> persistent but this is an addtitional aspect that makes the previous<br>
>> more critical (if persistent)<br>
>><br>
>> --<br>
>> | Giorgio Fedon, Owasp Italy<br>
>> |<br>
>> | In Input Validation<br>
>> |            and Output Sanitization,<br>
>> |                                   We Trust<br>
>> --<br>
>> | Web: <a href="https://www.owasp.org/index.php/Italy" target="_blank">https://www.owasp.org/index.php/Italy</a><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>
>> 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>
| Giorgio Fedon, Owasp Italy<br>
|<br>
| In Input Validation<br>
|            and Output Sanitization,<br>
|                                   We Trust<br>
--<br>
| Web: <a href="https://www.owasp.org/index.php/Italy" target="_blank">https://www.owasp.org/index.php/Italy</a><br>
|_____________________________________________.<br>
<br>
</div></div></blockquote></div><br></div>