Control character in cookie value or attribute

[guinotphil]

Hi,

I came across this exception due to a Tomcat/JBoss Web control in the class CookieSupport:

Control character in cookie value or attribute

It seems that an exception is thrown when accessing to the cookie if it contains non-ASCII characters. The cookie can be accessed from various frameworks such as Seam, RestEasy…

It looks being a well-known Tomcat issue, and the only given advice is to properly encode the cookie before.

Unfortunately, we can’t always control the cookie, especially with features such as Google Analytics that are setting themselves non-encoded cookies containing non-ASCII characters or even ( ) characters (which must constraint us to use V0 cookie as they parenthesis are separators in V1 cookies).

So I try asking here instead of the Tomcat list since they don't consider this being an issue.

Looking at the code, I was wondering, shouldn’t the controls:

• org.apache.tomcat.util.http.CookieSupport.isV0Separator(char)
• org.apache.tomcat.util.http.CookieSupport.isHttpSeparator(char)

thrown an exception only if STRICT_SERVLET_COMPLIANCE is true ?

I understand of course the possibility to have a strict compliant server, and it’s good to do such controls; but when using 3^rd party software like Google Analytics it becomes impossible to use in a production environment.

I think that to replace

throw new IllegalArgumentException(

                        "Control character in cookie value or attribute.");

with

if (STRICT_SERVLET_COMPLIANCE) {

    throw new IllegalArgumentException("Control character in cookie value or attribute.");

} else {

    log.warn("Control character in cookie value or attribute.")

}

would allow the server to accept request with non-encoded cookie. But I have no idea if it could have some side effects.

What do you think?

[jaikiran]

I've moved this to JBossWeb forum where you have more chances of this being answered.

[jfclere]

the problem is that those cookies are not parsed correctly when receiving them that is related to CVE-2007-5333

[guinotphil]

In order to be able to get requests with third party cookies (for Google Analytics for example), I had to patch JBoss Web.

I replaced the lines with the content
throw new IllegalArgumentException(
  "Control character in cookie value or attribute.");
by
if (STRICT_SERVLET_COMPLIANCE) {
  throw new IllegalArgumentException(
    "Control character in cookie value or attribute.");
} else {
  return false;
}

in both methods: isHttpSeparator(char) and isV0Separator(char)

of the org.apache.tomcat.util.http.CookieSupport class.

With the following properties in the configuration, we are able to avoid the above mentioned exception when a request contains some V0 third party cookies.
<property name="org.apache.catalina.STRICT_SERVLET_COMPLIANCE" value="false"/>
<property name="org.apache.tomcat.util.http.ServerCookie.ALLOW_EQUALS_IN_VALUE" value="true"/>
<property name="org.apache.tomcat.util.http.ServerCookie.ALLOW_HTTP_SEPARATORS_IN_V0" value="true"/>
<property name="org.apache.tomcat.util.http.ServerCookie.ALWAYS_ADD_EXPIRES" value="false"/>
<property name="org.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR" value="false"/>

About the same topic, Glassfish introduced a new system property ("org.glassfish.web.rfc2109_cookie_names_enforced") which allows to bypass strict RFC 2109 compliance for cookie content in their grizzly Cookie implementation.

[jfclere]

Again I think the problem is also when parsing the cookie sent by the browser. Did you test that?

[guinotphil]

I am not sure to understand what you mean by "cookie sent by the browser". The problem occurs when parsing the cookies of the HTTP requests, so obviously sent by the browser. The cookies that we set to the response could be easily encoded but the third party cookies that we get in requests can not be managed from server-side.

We tested well this behavior. We got the exception described above each time a request contains a cooky having a character of the extended ASCII table (with values from 0x7F to 0xFF like the character 'é'). The parsing is made by the above mentioned CookieSupport class. We can not bypass the methods of this class because we use frameworks (e.g. RESTeasy, Seam) that rely on it. Our patch solve the issue ; i.e. makes us able to accept again requests with such cookies and allows us to parse them.

[jfclere]

Ok right that could work with a new flag like org.apache.tomcat.util.http.ServerCookie.ALLOW_CONTROLS_IN_VALUE but are you really sure that all browsers do that the right way?

[guinotphil]

Yeah, the issue happens with all the main browsers: Chrome, Firefox, Opera, Internet Explorer..

I’ve included a small Seam 2.2.2 project with a jsf page which call a JS that emulates the creation of a Google Analytics cookie (which is – I know – not properly encoded).

It set the following cookie:

__utmz         28835944.1347261359.59.13.utmcsr=company|utmccn=newsletter|utmctr=La%20rentrée|utmcmd=email|utmcct=n°2

With the default configuration, parsing it as a V1 cookie, the value get truncated:

__utmz         28835944.1347261359.59.13.utmcsr

So, I add the following properties in standalone.xml :

<system-properties>

      <property name="org.apache.tomcat.util.http.ServerCookie.ALLOW_EQUALS_IN_VALUE" value="true"/>

      <property name="org.apache.tomcat.util.http.ServerCookie.ALLOW_HTTP_SEPARATORS_IN_V0" value="true"/>

      <property name="org.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR" value="false"/>

</system-properties>

And then I get the error:

java.lang.IllegalArgumentException: Control character in cookie value or attribute.

       at org.apache.tomcat.util.http.CookieSupport.isHttpSeparator(CookieSupport.java:177) [jbossweb-7.0.17.Final.jar:]

       at org.apache.tomcat.util.http.Cookies.getTokenEndPosition(Cookies.java:454) [jbossweb-7.0.17.Final.jar:]

       at org.apache.tomcat.util.http.Cookies.processCookieHeader(Cookies.java:332) [jbossweb-7.0.17.Final.jar:]

       at org.apache.tomcat.util.http.Cookies.processCookies(Cookies.java:157) [jbossweb-7.0.17.Final.jar:]

       at org.apache.tomcat.util.http.Cookies.getCookieCount(Cookies.java:98) [jbossweb-7.0.17.Final.jar:]

       at org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId(CoyoteAdapter.java:673) [jbossweb-7.0.17.Final.jar:]

       at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:615) [jbossweb-7.0.17.Final.jar:]

       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:369) [jbossweb-7.0.17.Final.jar:]

       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.17.Final.jar:]

       at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.17.Final.jar:]

       at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.17.Final.jar:]

       at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]

To run it, just unzip the content in the standalone/deployments folder and run the server.

Go to: http://localhost:8080/Cookie_Test/index.jsf

The page shows the cookies as parsed by Tomcat and have a couple of links.

The second link show the actual cookies sent by the browser.

And the first link set the Google-Analytics-like cookie. Click on the link and refresh the page to reproduce the problem.

Thank you,

Philippe

[jfclere]

"Yeah, the issue happens with all the main browsers: Chrome, Firefox, Opera, Internet Explorer.."

and with your fix it works correctly?

[guinotphil]

Yeah, it seems to work well ! With any browser.

[jfclere]

Ok could you create a JIRA (change request) with some explainations and assigned it to me.

[man_of_mood]

Hi,

we use jboss 7.1.1.Final. and we faced with the same issue on production.

what is the status of this issue: Should we fix it by our selfs or it will be included in some release in future?

[vijender.gilhotra]

Hi,

We are facing same issue in jbossweb-7.2.2 but it is working fine on 6.2.

Can anyone please confirm is it issue with 7.2.2 only.

Thanks