[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6905b1570609220722m5ec8836fu77e6cb523d3a252d@mail.gmail.com>
Date: Fri, 22 Sep 2006 15:22:40 +0100
From: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
To: Tim <tim-security@...tinelchicken.org>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
webappsec@...urityfocus.com, websecurity@...appsec.org
Subject: Re: [Full-disclosure] Self-contained XSS Attacks (the new generation of XSS)
hi there,
personally I don't care if it is a new or old vector :) to be
completely honest with you but thanks for the clarifications. I will
leave it to you guys to decide.
cheers Tim
On 9/22/06, Tim <tim-security@...tinelchicken.org> wrote:
>
> Hello pdp,
>
> > http://www.gnucitizen.org/blog/self-contained-xss-attacks
> >
> > XSS attacks can be persistent and non-persistent. Persistent XSS is
> > more dangerous since it allow attackers to control exploited clients
> > for longer. On the other hand non-persistent XSS is considered less
> > dangerous although it has been widely used in many phishing attempts.
> >
> > In this article I will expose some of my findings around a new attack
> > vector which is of type non-persistent XSS but a lot more dangerous
> > than the persistent one.
> >
> > Some of you might be familiar with this attack vector; this subject
> > has been covered very vaguely in the past and none of its full
> > potentials has been explored. The impact of this attack is much bigger
> > today and could affect many web applications.
>
> This is a very interesting vector. However, I would argue that it is
> not a new class of XSS. Generally, the classes have been defined based
> on where the injected data flows from, not how it is injected in the
> page.
>
> For instance, stored or persistent XSS comes from an attacker via one
> communication, gets saved on the server, and is later reproduced to
> another user. Reflected is generally embedded in a link, sent to a
> victim, which a victim then sends to the webserver and is reflected back
> to achieve injection. DOM-based is similar, but does not need to flow
> to the webserver before coming back to get injected. I personally label
> these three classes Type 2, Type 1 and Type 0 respectively, in order to
> reduce confusion about terminology [1].
>
> All three of these scenarios could be used with your injection vector.
> A server side script could store the URL supplied by an attacker, and
> later present it to a victim, thus making it persistent. Similarly, a
> document.write() call could be exploited to inject a data: link, even if
> the typical dangerous characters (', ", <, >, etc) were handled.
>
> Don't get me wrong... I really like the vector, and what you've brought
> to the list. I just don't think it should be considered another class.
>
> cheers,
> tim
>
>
> 1. http://en.wikipedia.org/wiki/XSS
>
--
pdp (architect)
http://www.gnucitizen.org
Powered by blists - more mailing lists