[
https://issues.apache.org/jira/browse/WICKET-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143921#comment-13143921
]
Gert-Jan Schouten commented on WICKET-4196:
-------------------------------------------
Well, even if Tomcat sanitizes the requests when called through HTTP and not
when it's called through AJP, this still does not make it a Tomcat problem.
Wicket should be able to handle unsanitized requests and not be dependent on
the container.
Our apache config is as follows:
We don't modify the main apache conf file.
Find below a sanitised copy of our configuration.
virtual.conf
------------
ServerTokens ProductOnly
ServerSignature Off
NameVirtualhost *:80
<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName our.server.name
ServerAlias server.name
# Modified logging format to include X-Forwarded-For IP addresses
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"
\"%{X-Forwarded-For}i\"" combxfwd
CustomLog "logs/access_log" combxfwd
ServerSignature Off
RewriteEngine On
RewriteRule ^$ /app-context/ [R]
RewriteRule ^/$ /app-context/ [R]
JkMount /app-context/* app-lb
JkMount /app-context app-lb
# Only enable these for debugging
#RewriteLog /tmp/rewrite
# Enable compression of text content
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
text/javascript application/json
</VirtualHost>
workers.properties
------------------
ps=/
worker.list=app01, app02, app-lb
worker.jkstatus.type=status
worker.app01.type=ajp13
worker.app01.host=app01
worker.app01.port=8009
worker.app01.socket_keepalive=1
worker.app02.type=ajp13
worker.app02.host=app02
worker.app02.port=8009
worker.app02.socket_keepalive=1
worker.ajp13.lbfactor=1
worker.app-lb.type=lb
worker.app-lb.balance_workers=app01,app02
worker.app-lb.sticky_session=1
mod_jk.conf
-----------
LoadModule jk_module modules/mod_jk.so
JkWorkersFile /etc/httpd/conf.d/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
JkShmFile /var/log/httpd/mod_jk.status
JkLogLevel error
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
> 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
