[Owasp-leaders] OWASP DOM based XSS definition, which looked a little off
jim.manico at owasp.org
Thu Oct 24 11:10:40 UTC 2013
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.
> 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
>> 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
More information about the OWASP-Leaders