[
https://issues.apache.org/jira/browse/WICKET-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147073#comment-13147073
]
Olivier Jaquemet commented on WICKET-4196:
------------------------------------------
I needed to diagnose exactly the same problem with another application, totally
unrelated to WICKET, here is my first returns on this subjects.
I could reproduce the HTTP Splitting vulnerability with the latest version of
HTTPD, mod_jk, and Tomcat :
Apache/2.2.21 (Win32) mod_jk/1.2.32, Tomcat 6.0.33
The vulnerability does not appears when using only Tomcat 6.0.33.
To reproduce :
1. Drop this JSP in the default ROOT webapp of tomcat
{noformat}
<%
// Test me by invoking this JSP like this :
//
http://www.example.com/header.jsp?foo=bar%0D%0AContent-Length:%20100%0D%0A%0D%0Apoisoned
String foo = request.getParameter("foo");
if (foo != null) {
response.addHeader("Foo", foo);
}
%>
This is the expected content of the file, nothing should appear above this line.
{noformat}
2. Configure Apache Tomcat with both an HTTP/1.1 connector and AJP/1.3
connector
This is the default when downloading Tomcat 6.0.33, you should have nothing to
do.
3. Configure Apache HTTPD with mod_jk
- Download mod_jk 1.2.32 binaries and drop mod_jk.so in modules directory
- Add the following worker.properties in conf directory :
{noformat}
worker.list=tomcat1
worker.tomcat1.port=8009
worker.tomcat1.host=127.0.0.1
worker.tomcat1.type=ajp13
{noformat}
- Update httpd.conf with the following line at the end :
{noformat}
LoadModule jk_module modules/mod_jk.so
JkWorkersFile conf/workers.properties
JkLogFile logs/mod_jk.log
JkLogLevel info
JkShmFile logs/shm
JkMount /* tomcat1
{noformat}
3. Access header.jsp through the HTTP/1.1 connector of tomcat with this URL :
http://127.0.0.1:8080/header.jsp?foo=bar%0D%0AContent-Length:%2010%0D%0A%0D%0Apoisoned
The response content is as expected : "This is the expected content of the
file, nothing should appear above this line."
4. Access header.sjp through Apache, with this URL :
http://127.0.0.1:80/header.jsp?foo=bar%0D%0AContent-Length:%2010%0D%0A%0D%0Apoisoned
The response content has been modified and contains new header and the content
has been truncated.
I will now report this security issue to Apache/mod_jk
> 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
