[
https://issues.apache.org/jira/browse/WICKET-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146960#comment-13146960
]
Olivier Jaquemet commented on WICKET-4196:
------------------------------------------
As far as i known, HTTP response splitting attack are usually fixed at response
time. By filtering each header for \n & \r
You might be interested in having a look at the following vulnerability of
Tomcat :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1232
It is stated that it's a XSS vulnerability, but I would also qualify this
vulnerability as an HTTP response splitting vulnerability.
Indeed the fix clearly adds the removal of \n and \r when sending headers :
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalOutputBuffer.java?r1=505604&r2=673834&pathrev=673834
It has been fix in Tomcat 6.0.18. And because the bug reporter of this current
issue only specified Tomcat 6. Might be worth a look
PS : I do not use wicket, nor know the context of your bug report, but your
issue came as a google result when searching for http splitting attack, and I
add found the tomcat bug prior to reading your issue. So if it can help in any
way...
> Accessing Wicket through AJP makes Wicket vulnerable to HTTP Response
> Splitting Attack
> --------------------------------------------------------------------------------------
>
> Key: WICKET-4196
> URL: https://issues.apache.org/jira/browse/WICKET-4196
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.19
> Environment: CentOS 5.6, Apache HTTPD 2.2.3 with mod_jk 1.2.31 and
> Apache Tomcat 6
> Reporter: Gert-Jan Schouten
> Assignee: Martin Grigorov
> Labels: http, security
> Fix For: 1.4.20
>
>
> Hello all,
> When having a Wicket application installed on Tomcat and you call that
> application through HTTP, Wicket is protected against HTTP Response
> Splitting. However, when you call Tomcat through AJP (for example through an
> apache httpd proxy), HTTP Response Splitting becomes possible.
> To demonstrate, I created a simple application and called it through an AJP
> proxy with the curl command:
> curl --max-redirs 0 -Dfoo
> 'http:///myapp/home?wicket:bookmarkablePage=:org.apache.wicket.markup.html.pages.BrowserInfoPage&cto=Foobar%3f%0d%0aEvilHeader:%20SPLIT%2f-%0d%0aAnotherEvilHeader:%20HEADER'
> Note the '%0d%0a', a CRLF in the request. When calling Wicket through Tomcat,
> these are replaced by spaces, but when calling Wicket through AJP, these are
> left intact, getting us the following response:
> HTTP/1.1 302 Moved Temporarily
> Date: Wed, 02 Nov 2011 14:34:32 GMT
> Server: Apache
> Set-Cookie: JSESSIONID=4F403B53D091B40F6C3FBC2321A2E348.pub-app04;
> Path=/myapp; HttpOnly Location:
> http://<ip-address>/myapp/Foobar;jsessionid=4F403B53D091B40F6C3FBC2321A2E348.pub-app04?
> EvilHeader: SPLIT/-
> AnotherEvilHeader: HEADER
> Content-Length: 0
> Connection: close
> Content-Type: text/plain; charset=UTF-8
> Here we have 2 Evil Headers, that could be inserted by hackers by adding
> %0d%0a to the get-request.
> The problem is that a hacker can now post URL's that look like they're going
> to your site on some forum or in an email. But when the user actually clicks
> on the link, a custom header could redirect the user to a malicious site. In
> the example, I used "EvilHeader", but it could be any header, like an HTTP
> 301 redirect. Basically, the hacker can include any header he wants in the
> response that the user is going to get when he clicks on the link.
> Note we are not vulnerable if you connect directly to tomcat with HTTP - it
> appears that the Coyote HTTP Connector is sanitising the HTTP headers and
> replacing the CRLF with two spaces. You have to connect via Apache and AJP to
> reproduce.
> For a more detailed description of HTTP Response Splitting (which is on the
> OWASP list of security vulnerabilities), you can check:
> https://www.owasp.org/index.php/HTTP_Response_Splitting
> http://www.acunetix.com/vulnerabilities/CRLF-injectionHTTP-respon.htm
> http://packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
> http://www.infosecwriters.com/text_resources/pdf/HTTP_Response.pdf
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
