RE: accept attributes: possible security holes

We will add a prohibition against characters outside the allowed range
32-126 as errors.  For interoperability, we'll require that all XInclude
processors fail if disallowed characters are encountered.

We believe this is resolution completes our resolution of outstanding
issues on XInclude, and we plan to release a new CR draft soon.

> -----Original Message-----
> From: www-xml-xinclude-comments-request@w3.org
[mailto:www-xml-xinclude-
> comments-request@w3.org] On Behalf Of Elliotte Harold
> Sent: Monday, November 10, 2003 8:50 PM
> To: www-xml-xinclude-comments@w3.org
> Subject: 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 Tuesday, 2 March 2004 03:49:32 UTC