accept attributes: possible security holes

The new working draft does not say what happens if the accept attribute 
values are not legal for their respective HTTP headers. There are many 
ways they could be illegal ranging from not using an appropriate 
language code for accept-language to using non-ASCII characters in a 
header field that expected only ASCII to including carriage returns and 
linebreaks (escaped if necessary) that completely botch up the HTTP 
header; for instance by prematurely ending it with a blank line or 
adding extra header lines. For example,

accept-language="en
Name: Value

"

I can even imagine this might be a security violation if it enabled me 
to write a document that injected arbitrary HTTP headers into a request 
made by a different client. I'm not sure how serious this is, but it 
might become a problem at some point in the future with the wrong 
client. For instance, if this was followed by HTTP headers intended to 
provide a user name and password for a proxy server which the proxy 
would normally strip off, they might instead be transmitted in the clear 
past the firewall as part of the message body. I'm not sure if this is a 
real attack. However, this feels flaky enough that I think there might 
be a real attack in here somewhere on some systems. It's just very weird 
for a server to be able to tell a client which HTTP headers to provide 
for a different server.

If the accept attributes are retained at all, then the spec really needs 
to put some strict limits on them, and require XInclude processors to 
either skip them or throw a resource error or fatal error (I'm not sure 
which) if the values of these attributes are syntactically incorrect for 
the relevant HTTP headers. It might be the case that implementations 
don't need to check everything, but probably line breaks need to be 
eliminated at a minimum. And someone who's more familiar with HTTP 
headers than me and who's quite devious should give this a serious 
thinking about to see if there might be any other nasty holes here 
waiting to trip up the unwary.

--
Elliotte Rusty Harold

Received on Monday, 10 November 2003 23:49:43 UTC