https://issues.apache.org/bugzilla/show_bug.cgi?id=50958
Volker Leidl <vkhle...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
--- Comment #2 from Volker Leidl <vkhle...@gmail.com> 2011-03-25 08:34:24 EDT
---
Let me try and make my point again.
> No it isn't. An HTTP response splitting attack is something triggered by
> client
> input, not by an application.
Fair enough. A response splitting attack is triggered by the client. However,
the root of the problem has nothing to do with client input. It's the
application that doesn't honour the HTTP protocol. RFC 2616 seems to go through
considerable lengths to disallow two or more consecutive CRLF pairs in various
locations, including header values (see the TEXT, token, separators, and
quoted-string productions in the BNF). I could easily imagine problems (not
necessarily exploits) being caused by header values coming from other sources
than client input.
The question is: where is the best place to enforce that conformance?
In the specific case of IIS + ISAPI + Tomcat + web app, I think it should be
the ISAPI filter that enforces the protocol restrictions. I'm aware that this
might just be my opinion, but here's why I believe that:
The web application just talks to an abstract interface, which is the Servlet
API. Nowhere does the API disallow the provision of header values with two
consecutive CRLF pairs. Also, why do I have to litter my web apps with code
that strips them out? After all, that's what the API is for, it should abstract
from the low-level protocol details. This is quite different to SQL or JS
injection attacks, where the low-level details are not abstracted away from the
application. Finally, not enforcing this limit in one common place will make
that vulnerability crop up again and again. After all, developers are human, so
they make mistakes.
>
> That the HTTP connectors and the newer AJP connectors stop developers shooting
> themselves in the foot (at least in this way) whereas the older BIO AJP does
> not (the filtering is in the Tomcat connector not the ISAPI native code) is a
> benefit of the newer connectors but does not represent a vulnerability in the
> older BIO AJP connector.
I'm not sure why the AJP connector should strip CRLFs at all. AJP is a binary
protocol and variable length strings are prefixed with a byte length. They're
not delimited by CRLFs, like in HTTP. I've tried Tomcat 5.5, 6, and 7, and only
the AJP connector that comes with 7 seems to do the stripping. So if I'm stuck
with 5.5 or 6 I can't take advantage of that feature. I don't know why the
decision was made to change the newer AJP connector, but I wouldn't blame it
for not doing it.
I think the best place to enforce the protocol is where the structured message
is serialised into HTTP. I can see the code in front of me where that happens.
It's in line 1050 of jk_isapi_plugin.c (rev 1085325). Simply copying the header
value into the response is like constructing a URL without encoding URL
parameters.
And if you're still not convinced, Apache httpd in combination with
mod_proxy_ajp also strips out CRLFs.
Regards,
Volker
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
