You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Keszthelyi Laszlo <la...@diepresse.com> on 2013/04/13 13:49:49 UTC

Tomcat 7.0.39: Blank pages - cookies containing umplaut causing the request processing beeing stopped

Hi,

we are facing problems with cookies containing umplaut (or other special characters), causing the request processing beeing stopped and returning a blank page.
I know that umlaut characters are forbidden within cookies, except when they are urlencoded, but the problem arises from third-parties createing cookies with the correct domain but containing invalid characters. Due to the request processing abort, we are unable to mark such cookies as invalid and beeing dropped next time by the client. 

Apr 13, 2013 9:19:41 AM org.apache.coyote.http11.AbstractHttp11Processor process
SEVERE: Error processing request
java.lang.IllegalArgumentException: Control character in cookie value or attribute.
       at org.apache.tomcat.util.http.CookieSupport.isHttpSeparator(CookieSupport.java:193)
       at org.apache.tomcat.util.http.Cookies.getTokenEndPosition(Cookies.java:502)
       at org.apache.tomcat.util.http.Cookies.processCookieHeader(Cookies.java:349)
       at org.apache.tomcat.util.http.Cookies.processCookies(Cookies.java:168)
       at org.apache.tomcat.util.http.Cookies.getCookieCount(Cookies.java:106)
       at org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId(CoyoteAdapter.java:931)
       at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:688)
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:402)
       at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
       at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
       at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
       at java.lang.Thread.run(Thread.java:722)

Is there a possibility to ignore such cookies? Setting CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0=true does not help because in org.apache.tomcat.util.http.Cookies.processCookieHeader first org.apache.tomcat.util.http.CookieSupport.isHttpSeparator is called and only than ALLOW_HTTP_SEPARATORS_IN_V0 examined:
// Skip whitespace and non-token characters (separators)
            while (pos < end &&
                   (CookieSupport.isHttpSeparator((char) bytes[pos]) &&
                           !CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0 ||
                    CookieSupport.isV0Separator((char) bytes[pos]) ||
                    isWhiteSpace(bytes[pos])))
                {pos++; }

Maybe changing the evaluation order within the while condition could solve the problem.

Why is it better throwing an exception, causing the request processing beeing aborted and returning a blank page, than ignoring the invalid cookie? In my opinion this is a serious possibility to prevent site accessing by the client through third-parties.


Pls help us/me out.

Thanks.

Laszlo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


AW: Tomcat 7.0.39: Blank pages - cookies containing umplaut causing the request processing beeing stopped

Posted by Keszthelyi Laszlo <la...@diepresse.com>.
thank you for your answers and short clarification. see my answers and further questions inline.

>In short:
>1. Cookies are usually sent by a single multi-valued "Cookie" header.
>If the header has incorrect value, then the client is sending an
>incorrect request which has to be rejected as invalid (400).

Why isn't the request simply rejected as invalid (400) by tomcat, instead of throwing the exception and quitting the request resulting in a blank page at the client (browser) side? Returning the "HTTP Error 400 Bad request" response would be more helpful for understanding teh failure at the client side than the blank page.

>In the past broken headers were used as a tool to break security of
>some web applications. E.g. to steal sessionid value.
>
>See CVE-2007-3385, CVE-2007-5333
>http://tomcat.apache.org/security-6.html

In this case it results in preventing the client's browser to access the page, without any reason (no 400 response returned).

>So I would like to be strict here.
>
>What is sending that value? Some web browser?

The value is sent by some web browser when requesting a page. The cookie is maybe set by a third-party in order to prevent a user to access pages. We are not setting any cookies with illegal control characters intentional. We got a hint that we could have a security hole in our application. Reproducing the problem resulted in detecting that it occurs already before our application can process the request somewhere in the tomcat engine (see stacktrace).

>2. If you are going to skip one cookie... that is not possible. At
>best you have to skip all of them (the header as a whole), and your
>web application will likely to misbehave anyway.

I would prefer skipping all cookies but how can I configure tomcat to do so and not trying to read/process them? 

>When Tomcat deciphers the Cookie header, the header contents in memory
>is being changed. So if Tomcat were changed to skip broken header,
>then you will not be able to process it in your application anyway.
>
>In Tomcat 8 it is possible to preserve the header, but it is turned
>off by default (PRESERVE_COOKIE_HEADER system property).

I do not want to process the broken header at any price, but I did not found any hint how to prevent tomcat in processing such headers resulting in the mentioned behaviour.

>3. What bother me is why this error is logged at severe level.

The Tomcat log-level has not been changed, I'm using the default settings. The problem maybe is that the exception is not catched and the request rejected as invalid (returning 400)?

Best regards,
Laszlo Keszthelyi


Re: Tomcat 7.0.39: Blank pages - cookies containing umplaut causing the request processing beeing stopped

Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/4/13 Keszthelyi Laszlo <la...@diepresse.com>:
> Hi,
>
> we are facing problems with cookies containing umplaut (or other special characters), causing the request processing beeing stopped and returning a blank page.
> I know that umlaut characters are forbidden within cookies, except when they are urlencoded, but the problem arises from third-parties createing cookies with the correct domain but containing invalid characters. Due to the request processing abort, we are unable to mark such cookies as invalid and beeing dropped next time by the client.
>
> Apr 13, 2013 9:19:41 AM org.apache.coyote.http11.AbstractHttp11Processor process
> SEVERE: Error processing request
> java.lang.IllegalArgumentException: Control character in cookie value or attribute.
>        at org.apache.tomcat.util.http.CookieSupport.isHttpSeparator(CookieSupport.java:193)
>        at org.apache.tomcat.util.http.Cookies.getTokenEndPosition(Cookies.java:502)
>        at org.apache.tomcat.util.http.Cookies.processCookieHeader(Cookies.java:349)
>        at org.apache.tomcat.util.http.Cookies.processCookies(Cookies.java:168)
>        at org.apache.tomcat.util.http.Cookies.getCookieCount(Cookies.java:106)
>        at org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId(CoyoteAdapter.java:931)
>        at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:688)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:402)
>        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
>        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
>        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
>        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>        at java.lang.Thread.run(Thread.java:722)
>
> Is there a possibility to ignore such cookies? Setting CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0=true does not help because in org.apache.tomcat.util.http.Cookies.processCookieHeader first org.apache.tomcat.util.http.CookieSupport.isHttpSeparator is called and only than ALLOW_HTTP_SEPARATORS_IN_V0 examined:
> // Skip whitespace and non-token characters (separators)
>             while (pos < end &&
>                    (CookieSupport.isHttpSeparator((char) bytes[pos]) &&
>                            !CookieSupport.ALLOW_HTTP_SEPARATORS_IN_V0 ||
>                     CookieSupport.isV0Separator((char) bytes[pos]) ||
>                     isWhiteSpace(bytes[pos])))
>                 {pos++; }
>
> Maybe changing the evaluation order within the while condition could solve the problem.
>
> Why is it better throwing an exception, causing the request processing beeing aborted and returning a blank page, than ignoring the invalid cookie? In my opinion this is a serious possibility to prevent site accessing by the client through third-parties.
>
>

In short:
1. Cookies are usually sent by a single multi-valued "Cookie" header.
If the header has incorrect value, then the client is sending an
incorrect request which has to be rejected as invalid (400).

In the past broken headers were used as a tool to break security of
some web applications. E.g. to steal sessionid value.

See CVE-2007-3385, CVE-2007-5333
http://tomcat.apache.org/security-6.html

So I would like to be strict here.

What is sending that value? Some web browser?

2. If you are going to skip one cookie... that is not possible. At
best you have to skip all of them (the header as a whole), and your
web application will likely to misbehave anyway.

When Tomcat deciphers the Cookie header, the header contents in memory
is being changed. So if Tomcat were changed to skip broken header,
then you will not be able to process it in your application anyway.

In Tomcat 8 it is possible to preserve the header, but it is turned
off by default (PRESERVE_COOKIE_HEADER system property).

3. What bother me is why this error is logged at severe level.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org