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

Erlend Oftedal erlend.oftedal at owasp.org
Thu Oct 24 10:41:54 UTC 2013


I do agree that mitigation happens at the sink, but the source is
interesting. Why? Some developers do not have a clear distinction between
trusted and untrusted data. For instance request headers, cookies etc. may
or may not be treated as trusted data depending on the knowledge of the
dev. Allthough I always suggest "encode by default", many devs apply
"encode when needed", which is much more difficult to get right security
wise.

Erlend


On Thu, Oct 24, 2013 at 9:14 AM, Giorgio Fedon <giorgio.fedon at owasp.org>wrote:

> 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
> |_____________________________________________.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20131024/754344cb/attachment-0001.html>


More information about the OWASP-Leaders mailing list