You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Gert-Jan Schouten (Updated) (JIRA)" <ji...@apache.org> on 2011/11/04 10:21:00 UTC
[jira] [Updated] (WICKET-4196) Accessing Wicket through AJP makes
Wicket vulnerable to HTTP Response Splitting Attack
[ https://issues.apache.org/jira/browse/WICKET-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gert-Jan Schouten updated WICKET-4196:
--------------------------------------
Description:
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
was:
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.
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
> 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
> Priority: Critical
> Labels: http, security
>
> 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