-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jetty 11.0.14 is less tolerant of non-compliant cookies than 11.0.13 #9468
Comments
Since you are using raw header setting, you should be encoding properly. Per RFC6265 the space is invalid for a cookie value. Try this instead ... .setHeader("cookie", "PS_DEVICEFEATURES=width:1920%20height:1080") RFC6265 will see |
I agree it should be encoded correctly, but the browser (Edge 110.0.1587.50) is sending it with spaces in; the reproducer is just trying to be as close to the browser as possible. |
That Edge is this broken is quite incredible 🤦🏼♂️ Do you know how this cookie is set? |
Sorry, I don't know how it was set - Google seems to think it's something to do with PeopleSoft. FWIW from the perspective of my application, that cookie is just chaff: I need the value of a different cookie, but to get that, Jetty has to parse the full set of cookies sent from the browser. |
btw, the current versions of Tomcat also puke and reject the entire request on that bad Cookie. |
According to various PeopleSoft docs i've been reading (along with various complaints about this cookie) ... The An example of a "complete" version of this header would be ...
The only way I can see us handling this entirely messed up Cookie is to just fail it and ignore the entire header field on failure. |
Note that if you wish to use the old Cookie parser, then you need to set one of the LEGACY cookie compliance modes (or include BAD_QUOTES violation in a custom mode). This will use the old parser, but by the nature of the forgiveness you may be vulnerable to cookie smuggling if an intermediary does not forgive the cookies in the same way that Jetty does. |
@joakime's Postel's law suggestion would work for me: It seems reasonable that invalid cookies might not be available to Jetty (or at least not trivially available), but given the server can't control what cookies get sent, it should be tolerant as far as possible, subject to security concerns as mentioned by @gregw. |
@markslater we are as forgiving as we can be. The problem with bad cookies that have variations of bad quotes (including spaces without quotes), is that there is no specification for being forgiving. If an intermediary does it differently to us, then security concerns can result. Hence the change to a parser that is as forgiving as it can be, without forgiving cookie boundaries. The new parser can thus skip to the next valid cookie if it sees a bad one. So the LEGACY mode is there to use if you really need spaces forgiven. Let's leave this issue open and we can consider if we can also handle spaces in the new parser in a way that allows bad cookies to be skipped. |
Added a violation to allow unquoted spaces in cookie values Signed-off-by: gregw <[email protected]>
I think supporting spaces in values is easy and safe. I have created PR #9471 that does it. |
Added a violation to allow unquoted spaces in cookie values Signed-off-by: gregw <[email protected]>
Added a violation to allow unquoted spaces in cookie values Signed-off-by: gregw <[email protected]>
Jetty version(s)
11.0.14
Java version/vendor
(use: java -version)
openjdk version "11.0.18" 2023-01-17
OpenJDK Runtime Environment (build 11.0.18+10-post-Ubuntu-0ubuntu120.04.1)
OpenJDK 64-Bit Server VM (build 11.0.18+10-post-Ubuntu-0ubuntu120.04.1, mixed mode, sharing)
OS type/version
Linux 5.4.0-120-generic
Description
Jetty 11.0.14 is less tolerant of non-compliant cookies than 11.0.13.
Specifically, when Jetty 11.0.14 is presented with a cookie containing a space in the value,
org.eclipse.jetty.server.Request.getCookies()
throws aBadMessageException
, whereas Jetty 11.0.13 parses the cookie successfully.This is a particular problem because the cookies an application receives might be outside its control: The browser will send
myapp.example.com
invalid cookies set bybadapp.example.com
on the.example.com
domain.Reviewing the code, I think the intention was that 11.0.14 would behave in the same way as 11.0.13, but a failure case has slipped through.
How to reproduce?
Use this class:
Outputs:
The text was updated successfully, but these errors were encountered: