> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbar...@mit.edu]
> Sent: Sunday, October 14, 2012 12:49 AM
>
> On 10/13/12 5:08 AM, Hallvord R. M. Steen wrote:
> > I came across an article [1] that describes some of the reasoning for
> > Flash's change in security policy when it banned setting User-Agent.
> > Apparently, some sites echo the User-Agent value back in markup in
> > certain contexts (maybe a "browser requirements" page for example).
>
> And naturally do not send "Vary: User-Agent"?
I'm not sure what Hallvord assumed here, but if certain backend intends to
provide its content under some browser requirements, isn't "Vary: User-Agent"
sort of a required header to have related caching proxy, if any, work
correctly? Otherwise, subsequent requests on the same resource with different
User-Agent string would be regarded as a cache HIT in caching proxy anyway.
Anyway, the point here is that if changing of User-Agent is allowed in script,
it will be possible for malicious third party to set arbitrary User-Agent
strings in generating XSS attacks.
To which Hallvord wrote:
> > So it seems reasonable to keep the limitation on setting User-Agent.
+1.
> > (I'm still wondering if we could lift it only for the cross-domain case
> > where the target site must opt in to receiving a changed UA string though..)
-1. I don't know if there can be any smart way, but as of now I don't think it
is a good way to determine the availability of setRequestHeader('User-Agent',
...) depending on the choice of certain backend.
Jungkee
>
> > However, another threat might be using an XHR request to put a
> > generated page with injected content in the browser's cache, then
> > opening the page directly in a new window. The page would likely be
> > taken from cache
>
> This seems simple enough to deal with on the browser side: Assume "Vary:
> User-Agent" on all requests. Probably a good idea anyway.
>
> -Boris
