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

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


I agree with Eoin with an exception about DOMxss in a sense that is
better to say that the sink or the dangerous function should be
"sanitized". So sanitizing the sink I would say for the DOMxss case.

Just making an example of a DOMxss case where output encoding is not
possible. E.g. redirection to javascript:// that issue for location
sinks is  remediated by whitelisting the allowed protocols and
redirection domains.


On 10/24/2013 08:58 AM, Eoin Keary wrote:
> +1
> Attack types help define risk, fair?
> Mitigation is what is important; contextual output encoding.
>
> Eoin Keary
> Owasp Global Board
> +353 87 977 2988
>
>
> On 24 Oct 2013, at 07:22, Erlend Oftedal <erlend.oftedal at owasp.org> 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


-- 
| 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