[WEB SECURITY] Exploiting User-Agent XSS
owasp at intern0t.net
owasp at intern0t.net
Wed Jun 8 05:09:01 EDT 2011
Instead of just talking about how it may be possible to conduct XSS attacks vis
User-Agents with current up to date technology and referring to your own website
whenever possible, why don't you just provide this mailing list with relevant
If you know a way, the amount of time it takes to write a reply as your previous
to this mailing list, is the same as it takes to provide a relevant example. I'm
sorry, but all I see is talk, and old irrelevant examples.
The only possible way I know, is to trick the user into a scheme that could look
1. User clicks a short URL link, which redirects the user to a spoofed website
that looks like the target site.
2. The target site, makes a request on behalf of the user with a modified user
agent, conducting the XSS attack, and of course it returns the output.
3. Cross-domain policy, will prevent most critical assets from being accessed,
such as cookies. (If you use Firebug in FireFox, you'll get the usual access
This kind of attack, looks similar to TRACE (XST) attacks, because most if not
all current attack vectors, has been patched a long time ago.
As soon as it's another website, and not the user performing the request,
cross-domain policy will intervene and as previously stated, make possible
exploitation even harder.
There is an impact of User Agent XSS, but I'd profile it as low, due to the
requirements for a successful attack to work.
If you should have a way, of conducting XSS attacks vis User Agents, without
making any website or program (which is manually installed), perform the HTTP
request, then I'd like to see it.
On June 7, 2011 at 4:50 PM MustLive <mustlive at websecurity.com.ua> wrote:
> Hi Michal and guys!
> Last week I've already wrote two articles: 1st one - Sending server headers
> in Flash (on which I'd be referencing in 2nd article) and 2nd one - XSS
> attacks via User-Agent header (http://websecurity.com.ua/5195/). The topic
> is large, so I was needed to split it into two articles. And in second
> article (which I'll translate for you) I'm be talking about as XSS attacks
> via User-Agent header, as (briefly) via other headers.
> So soon I'll translate this article for you (it's large enough, but I'm
> planning to finish translation in the nearest days). In the article I've
> described the next attack vectors with using UA header: via Flash, via
> via ActiveX, via spoofing User-Agent in browsers by viruses, via proxy which
> is spoofing User-Agent.
> > There are many RCE and UXSS vulnerabilities in outdated Flash plugins;
> > there is no way you can protect such users.
> It's true concerning other attacks (browser-based attacks) on such users.
> But the things is different when we talk about XSS attacks via Flash on
> these users. To protect them from such attacks (without asking them to
> update their browser/plugin/brain/etc) it's possible by fixing these XSS
> holes at vulnerable sites. If lame admins of these sites don't want to fix
> these (as any other) holes, then other actions can be made. To make long
> story short: XSS hole via User-Agent header it's a problem of the site, not
> of flash plugin.
> > If you know a way to inject U-A headers into
> > cross-domain requests, it would certainly be considered a browser bug
> Partly it is. But from other side, if some request is made by some browser
> of some user with changed U-A from default, then it's not a big deal for
> browser (and for plash plugin). Even if this header contain XSS payload :-),
> as I wrote above - XSS hole via User-Agent header it's a problem of the
> site, not of browser / flash plugin.
> But Adobe and browser developers are trying to fix such holes, and besides
> doing good, also doing bad. Such examples concerns not only this case with
> U-A, but many other cases. I'll not write further on this, because it's
> other topic then "Exploiting User-Agent XSS" started by topic-starter. Just
> note guys, that any moaning about "Adobe fixed this attack vector, so
> it's not possible any more and don't care about XSS via U-A completely" is
> incorrect and will lead to additional decrease of security of web sites. So
> main leitmotif of my article is that there are many methods of conducting
> XSS via User-Agent and developers need always to work to prevent such
> vulnerabilities (and about that I wrote in article's conclusion).
> > - and would likely be addressed swiftly.
> Michal, such things not always happen :-). Like when in March I informed
> Mozilla, Microsoft, Google and Opera about vulnerability which concerns many
> browsers (as these one, as almost all others), then Google and Opera just
> ignored. Microsoft asked for additional details and after that (when I gave
> it for them) ignored. Only Mozilla not ignored and promised to fix (but it
> can stretch on long time, even years like it was with css history hack).
> Best wishes & regards,
> Administrator of Websecurity web site
> ----- Original Message -----
> From: "Michal Zalewski" <lcamtuf at coredump.cx>
> To: "MustLive" <mustlive at websecurity.com.ua>
> Cc: <atul at secfence.com>; <websecurity at lists.webappsec.org>
> Sent: Tuesday, May 31, 2011 2:53 AM
> Subject: Re: [WEB SECURITY] Exploiting User-Agent XSS
> > It's not working in new versions of flash plugin, but it's working in
> > older
> > versions. So no need to fully forget about it.
> There are many RCE and UXSS vulnerabilities in outdated Flash plugins;
> there is no way you can protect such users.
> > 3. Other advanced methods. Among them there is also such one as using of
> > JS.
> > Even if other guys told you, that there is no possibility via JS, it's not
> > true - there is such way (which works in some browsers). I know about such
> > method from 2004 and at that time I wrote about it at one my site
> > (concerning not security purposes) and I tested this method in modern
> > versions of those browsers.
> Please do share. If you know a way to inject U-A headers into
> cross-domain requests, it would certainly be considered a browser bug
> - and would likely be addressed swiftly.
> The Web Security Mailing List
> WebSecurity RSS Feed
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> websecurity at lists.webappsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity