[security] Jetty leaks cookies between HttpRequests when using HTTP/1.1 Proxy and specially crafted HTTP Requests

Test setup:

Several HTTP clients connect to Jetty via an Apache Reverse proxy using HTTP/1.1 for talking to the backend (Jetty). So in practice, this means requests from different origins get streamed over the same HTTP connection(s) to Jetty by Apache.

client \
client ----> Apache --(http/1.1) ---> Jetty
client /

When setting an empty 'Cookie: ' header in the HTTP Request, Jetty uses the Cookie value from the previous request seen in this HTTP connection. So at servlet time, it seems the unauthorized client uses a valid cookie that does not belong to the session. When a HTTP/1.1 reverse proxy is used in front of Jetty, this bug could be exploited to hijack sessions (if they're cookie-based).

When omitting the Cookie-header instead of providing it with an empty value, as well as when using HTTP/1.0 proxy connections to Jetty this bug does not occur. I also tried to reproduce the same behaviour using other (custom) HTTP Header lines, but it seems only the Cookie headers are affected.

It seems in the Cookie parsing code, when encoutering a Cookie: header name without value, the value is not cleared, but reused.

I've been debugging using the Jetty 6.1.18 source with a colleague here yesterday, but we could not yet find the exact spot where the bug occurs.

I have attached a full example project to reproduce this bug, consisting of 1) A Java project that starts Jetty with a simple Servlet. 2) A small python HTTP client program (only extra dependency is python-httplib2) that fires some requests at the server. The file 'output' displays the output of the python script when run.

Let me know if I can do anything else.