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

Eoin Keary eoin.keary at owasp.org
Thu Oct 24 12:26:22 UTC 2013


+1

Eoin Keary
Owasp Global Board
+353 87 977 2988


On 24 Oct 2013, at 12:10, Jim Manico <jim.manico at owasp.org> wrote:

> There are edge cases where contextual output encoding is not the right
> control. For example, when you use TinyMCE and similar UI widgets.
> These submit untrusted HTML within a form parameter.
> 
> In this case we need HTML sanitizers, such as htmLawed for PHP or the
> OWASP HTML Sanitizer for Java.
> 
> I prefer to sanitize both on input to ensure I save "safe" HTML in the
> database (and also as potential attack detection). I also suggest the
> same sanitization in the UI on output to ensure my UI templates are
> fully injection resistant regardless of the kind of data that reaches
> dynamic variables in the UI.
> 
> I'm sure most of you know this already, but I just wanted to put it
> out there for completeness.
> 
> Regards,
> --
> Jim Manico
> @Manicode
> 
>> On Oct 24, 2013, at 2:08 AM, Giorgio Fedon <giorgio.fedon at owasp.org> wrote:
>> 
>> 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
>> |_____________________________________________.
>> 
>> _______________________________________________
>> 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