[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJB2Jzu51_1sQq0UNAFHJLqJgyK5oibAZLJJvAN7ShF-prV6Fw@mail.gmail.com>
Date: Sat, 17 Dec 2011 11:02:54 +0100
From: Mario Vilas <mvilas@...il.com>
To: Bouke van Laethem <vanlaethem@...il.com>
Cc: Jann Horn <jannhorn@...glemail.com>, bugtraq@...urityfocus.com
Subject: Re: <BASE> tag used for hijacking external resources (XSS)
You make good points in the rest of the email. This one, however,
doesn't convince me...
On Sat, Dec 17, 2011 at 1:10 AM, Bouke van Laethem <vanlaethem@...il.com> wrote:
> Wouldn't you agree that by this definition no XSS is ever a
> vulnerability: you are just using the ability to inject HTML in order
> to inject some unaccounted for HTML, right?
Well, not quite. The idea of an XSS is that you can gain the privilege
to inject HTML code when you didn't have any.
HTML is not the same as textual content, for example - a blog that
lets you add comments to a blog post is not giving you the ability to
inject HTML tags, so if you manage to do that you've gained a
privilege you're not supposed to have.
Same goes for any other XSS - you always being by assuming you can't
inject HTML tags, and it's a vulnerability when you can. If you being
by assuming you can already insert HTML tags then there could be
millions of things to do from there, since your injected code can do
the same things the legitimate code can do, and there's no way to tell
them apart. Every single browser feature would be considered a
vulnerability.
That's why I'd categorize this as an exploitation aid rather than a
vulnerability. Then again you can always think I'm being too picky ;)
--
“There's a reason we separate military and the police: one fights the
enemy of the state, the other serves and protects the people. When the
military becomes both, then the enemies of the state tend to become
the people.”
Powered by blists - more mailing lists