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

Achim achim at owasp.org
Thu Oct 24 20:23:24 UTC 2013

Jim, in case you disagree with my sanatize suggestion, I'd like to recess my
   Sanitation should not be used in application (or data) with a high security
   demand. For less secure demands (that's what I meant with "other context")
   sanitation can be an additional valid mitigation.

Hope this explains better ;-)

Am 24.10.2013 15:45, schrieb Jim Manico:
> In the case of untrusted HTML from TinyMCE and other WYSIWYG editors,
> the context of display does not matter. A chunk of HTML is a chunk of
> HTML. So although it pains me to say you are wrong, Achim, since you
> embody German discipline so well, I think you are in this one case.
> ;-)
> --
> Jim Manico
> @Manicode
> (808) 652-3805
>> On Oct 24, 2013, at 8:41 AM, Achim <achim at owasp.org> wrote:
>> Hmm, it's hard to give a proper definition of XSS from a independent point
>> of view. The definition often (always?) depends on the context.
>> For example: if there is a rich content editor, the data needs to be stored
>> as is. And in this case it is *not* "stored XSS".
>> An this example is exactly, why I slightly diagree with Jims suggestion to
>> store anything sanatized, as it can break intended functionality, obviously.
>> My suggestion for developers is: check data at each boundary, and encode proper
>> when data leaves your control (aka output encoding). This encoding must be
>> according the sink. Where the sink can be any of HTML, CSS, JavaScript, href,
>> etc. (all in UI) or SQL (in backend). You see that each sink needs its own
>> encoding. Again, see what we suggested in
>>    https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
>> A similar concept should be used for other types of XSS.
>> This approach does not mean that only output encoding is necessary, you need
>> input checks for that data used under your control (your program).
>> Sanitation is a bad approach, IMHO. If input checks fail, ignore all data
>> (may be different in some less secure cases).
>> These rules work for all kind of injections, not only XSS.
>> Did I miss something?
>> Achim
>> Am 24.10.2013 14:15, schrieb Giorgio Fedon:
>> ...
>>> It seems that dividing the issue by remediation is more complicated than
>>> what it may seem. In addition I think that in the search of a proper
>>> definition of DOMXss we need to define a correct definition of XSS, in a
>>> sense that we should say what XSS is and what XSS is not. As well as
>>> what DOMXss is.
>> ...
>>> On 10/24/2013 01:10 PM, Jim Manico wrote:
>> ...
>>>> I prefer to sanitize both on input to ensure I save "safe" HTML in the
>>>> database (and also as potential attack detection).
>> ...

More information about the OWASP-Leaders mailing list