You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Gert-Jan Schouten <ge...@roboreus.com> on 2011/11/03 13:04:14 UTC
HTTP Response Splitting issue when reaching Wicket through AJP
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.
Is there anything we can do about this? We use mod_jk 1.2.31 on our
httpd server.
Cheers!
Gert-Jan
--
*Gert-Jan Schouten
Java Developer*
Re: HTTP Response Splitting issue when reaching Wicket through AJP
Posted by Martin Grigorov <mg...@apache.org>.
See the comments in the ticket
On Fri, Nov 4, 2011 at 11:57 AM, Gert-Jan Schouten
<ge...@roboreus.com> wrote:
> Done!
>
> https://issues.apache.org/jira/browse/WICKET-4196
>
> *Gert-Jan Schouten
> Java Developer*
>
>
> On 03/11/11 15:16, Igor Vaynberg wrote:
>>
>> please create a jira issue.
>>
>> -igor
>>
>> On Thu, Nov 3, 2011 at 7:02 AM, Gert-Jan Schouten
>> <ge...@roboreus.com> wrote:
>>>
>>> Hello!
>>>
>>> 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
>>>
>>> Cheers,
>>>
>>> Gert-Jan
>>>
>>>
>>>
>>> *Gert-Jan Schouten
>>> Java Developer*
>>>
>>>
>>>
>>> On 03/11/11 12:49, Martin Grigorov wrote:
>>>>
>>>> Hi,
>>>>
>>>> Can you describe what exactly is the problem with these custom headers ?
>>>>
>>>> On Thu, Nov 3, 2011 at 2:04 PM, Gert-Jan Schouten
>>>> <ge...@roboreus.com> wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>> Is there anything we can do about this? We use mod_jk 1.2.31 on our
>>>>> httpd
>>>>> server.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> Gert-Jan
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Gert-Jan Schouten
>>>>> Java Developer*
>>>>>
>>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HTTP Response Splitting issue when reaching Wicket through AJP
Posted by Gert-Jan Schouten <ge...@roboreus.com>.
Done!
https://issues.apache.org/jira/browse/WICKET-4196
*Gert-Jan Schouten
Java Developer*
On 03/11/11 15:16, Igor Vaynberg wrote:
> please create a jira issue.
>
> -igor
>
> On Thu, Nov 3, 2011 at 7:02 AM, Gert-Jan Schouten
> <ge...@roboreus.com> wrote:
>> Hello!
>>
>> 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
>>
>> Cheers,
>>
>> Gert-Jan
>>
>>
>>
>> *Gert-Jan Schouten
>> Java Developer*
>>
>>
>>
>> On 03/11/11 12:49, Martin Grigorov wrote:
>>> Hi,
>>>
>>> Can you describe what exactly is the problem with these custom headers ?
>>>
>>> On Thu, Nov 3, 2011 at 2:04 PM, Gert-Jan Schouten
>>> <ge...@roboreus.com> wrote:
>>>> 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.
>>>>
>>>> Is there anything we can do about this? We use mod_jk 1.2.31 on our httpd
>>>> server.
>>>>
>>>> Cheers!
>>>>
>>>> Gert-Jan
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Gert-Jan Schouten
>>>> Java Developer*
>>>>
>>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: HTTP Response Splitting issue when reaching Wicket through AJP
Posted by Igor Vaynberg <ig...@gmail.com>.
please create a jira issue.
-igor
On Thu, Nov 3, 2011 at 7:02 AM, Gert-Jan Schouten
<ge...@roboreus.com> wrote:
> Hello!
>
> 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
>
> Cheers,
>
> Gert-Jan
>
>
>
> *Gert-Jan Schouten
> Java Developer*
>
> Roboreus
> 175 High Holborn
> London WC1V 7AA
> T: +44 (0) 7832916802
> E: gert-jan.schouten@roboreus.com
> Skype: gert.jan.schouten
>
>
> On 03/11/11 12:49, Martin Grigorov wrote:
>>
>> Hi,
>>
>> Can you describe what exactly is the problem with these custom headers ?
>>
>> On Thu, Nov 3, 2011 at 2:04 PM, Gert-Jan Schouten
>> <ge...@roboreus.com> wrote:
>>>
>>> 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.
>>>
>>> Is there anything we can do about this? We use mod_jk 1.2.31 on our httpd
>>> server.
>>>
>>> Cheers!
>>>
>>> Gert-Jan
>>>
>>>
>>>
>>> --
>>>
>>> *Gert-Jan Schouten
>>> Java Developer*
>>>
>>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HTTP Response Splitting issue when reaching Wicket through AJP
Posted by Gert-Jan Schouten <ge...@roboreus.com>.
Hello!
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
Cheers,
Gert-Jan
*Gert-Jan Schouten
Java Developer*
Roboreus
175 High Holborn
London WC1V 7AA
T: +44 (0) 7832916802
E: gert-jan.schouten@roboreus.com
Skype: gert.jan.schouten
On 03/11/11 12:49, Martin Grigorov wrote:
> Hi,
>
> Can you describe what exactly is the problem with these custom headers ?
>
> On Thu, Nov 3, 2011 at 2:04 PM, Gert-Jan Schouten
> <ge...@roboreus.com> wrote:
>> 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.
>>
>> Is there anything we can do about this? We use mod_jk 1.2.31 on our httpd
>> server.
>>
>> Cheers!
>>
>> Gert-Jan
>>
>>
>>
>> --
>>
>> *Gert-Jan Schouten
>> Java Developer*
>>
>>
>
>
Re: HTTP Response Splitting issue when reaching Wicket through AJP
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Can you describe what exactly is the problem with these custom headers ?
On Thu, Nov 3, 2011 at 2:04 PM, Gert-Jan Schouten
<ge...@roboreus.com> wrote:
> 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.
>
> Is there anything we can do about this? We use mod_jk 1.2.31 on our httpd
> server.
>
> Cheers!
>
> Gert-Jan
>
>
>
> --
>
> *Gert-Jan Schouten
> Java Developer*
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org