RE: [XHR] Open issue: allow setting User-Agent?

> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky@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

Received on Monday, 15 October 2012 11:19:30 UTC