Re: XHR header blacklist rationale

Julian Reschke wrote:
> 
> Jonas Sicking wrote:
>> These should absolutely not be under control of web content.
>>
>> The Referer header is used by some web servers for security checks so 
>> allowing this to be settable would work around that. Servers can't 
>> currently rely on the header being there due to some firewalls/proxies 
>> filtering it, however they can rely on it being true when it is there.
>>
>> The User-Agent is used a lot for logging and measuring various aspects 
>> (OS, UA, etc) of the user base for a site. Allowing this to be 
>> "spoofed" by a web page would severely reduce its usefulness. You cite 
>> in a different mail that you want to be able to set this to work 
>> around servers that send different content based to different UAs 
>> based on this header. However if we let this header be set by web 
>> content then servers would not be able to rely on the User-Agent 
>> header and would likely start using even worse mechanisms.
> 
> Microsoft's ActiveX version of XMLHTTPRequest definitively lets clients 
> set it. I know it, because it was needed to override the UA header, so 
> that servers would do proper authentication instead of form-based login.
> 
> Not sure about what the native implementations do today, but I think we 
> need to make sure that the XHR spec doesn't break use cases that work 
> today.

I assume that by "it" you mean the User-Agent header?

Looking at the code it does indeed look like we let you set that header, 
which greatly surprises me.

My gut feeling though is that we want sites to be able to rely on the UA 
header for logging. I'm fine with breaking "use cases that work today" 
if we do it to improve security. The User-Agent header isn't strictly 
security, but it's close to.

/ Jonas

Received on Wednesday, 28 May 2008 01:02:48 UTC