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

Giorgio Fedon giorgio.fedon at owasp.org
Thu Oct 24 07:07:56 UTC 2013

I think that remediation should NOT take into consideration the source
for XSS but JUST the sink.

If we are also considering heuristical mitigations and IDS/IPS
approaches for realtime attack response that is very far from a solid
remediation. Those solutions consider usually also the input because
they should make a decision in realtime.

>From my point of view sanitization should be happen for the sink in
first place, sanitizing the source e.g. input is not a proper
remediation. This does not make any difference between stored or
reflected, persistent or non persistent. Correct remediation occour
sanitizing the output or better for DOMxss sanitizing the sink function.

That's why distinction between stored / non stored which is a difference
in the source of the attack could be not considered for remediation but
is a risk leverage property of the vulnerability. This it because
probability of exploitation of a stored XSS is higher because the xss is
triggered without user interaction. BTW remediation strategy is not changed.

On 10/24/2013 08:22 AM, Erlend Oftedal wrote:
> I think the distinction between stored and. reflected is useful.
> Remember that stored xss can occur on completely different locations.
> Consider an attack where the attack string ends up in a web enabled log
> in the admin gui. So for stored, sink and source can be far from each
> other, while for reflected they are always found relatively close to
> each other in the code.
> Instead of talking about different types of XSS, from a defensive point
> of view, we need to be able to identify sources and sinks to mitigate
> with correct escaping. For reflected XSS, the source is the request.
> For a stored XSS, the source is the databases, files and other types of
> backend storage. Allthough it could also include web storage for
> DOM-based. And then there is pure DOM-based where the browser is the
> source.
> And next the sink is either server-generated HTML/JavaScript, while the
> sink is in JavaScript for all types of DOM-based.
> Erlend
> Fra: Giorgio Fedon
> Sendt: 23.10.2013 23:25
> Til: Achim
> Kopi: owasp-leaders at lists.owasp.org
> Emne: Re: [Owasp-leaders] OWASP DOM based XSS definition, which looked
> a little off
> On 10/23/2013 11:05 PM, Achim wrote:
>> opps, my point was not to stick on a single XSS definition, but on
>> reflected, persistent and DOM-based. As these are problems on different places.
>> All others are variants of these, as we know today.
> Ops I misunderstood. Sorry Achim.
> However I think that the cathegories are:
> - XSS or generic XSS
> - DomXSS
> I would remove "stored" as a cathegory. Both can be non persistent or
> persistent but this is an addtitional aspect that makes the previous
> more critical (if persistent)

| 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