fix: narrow the validation of cookies to match RFC6265 #167
+59
−9
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fixes jshttp#165. Previously, validation on serialization used the field-content regexp from RFC7230 to perform all checks. However, that is the regexp for the cookie header as a whole, but each individual part of a cookie has a tighter restriction. In the bug report jshttp#165 I demonstrated that whitespace in names and values was invalid but allowed by the field-content pattern. In this code I started by adding tests for those two cases, then added the expressions derived from the RFC; the relevant portions of the RFC have been inlined as comments. Removing the field-content regexp unearthed that as well as those two it was being used to validate domain names and paths. Paths are fairly unrestricted (being any ascii character except control characters and semicolon) but the code was wrong here too - it allowed all 8-bit characters not just 7-bit characters. Domain names have a well recognised pattern, there are only a couple of gotchas: RFC6265 explicitly says RFC1123 applies, so the leading character of a label is allowed to be a digit; and while I wondered for a moment if this should allow things like [::1] the domain matching section of https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.3 teaches that domain values are _not_ ip addresses.
bewinsnw
changed the title
wesleytodd
requested changes
Jul 17, 2024
|
Thanks, this VERY well structured from the comments to the new regular expressions, great work. CI is passing, but I want to wait a bit and see if anyone else on the project as opinions on this. My one review comment is not intended to block, so if you feel strongly about that form of regex please tell me. |
The regexp should be in the same order as the RFC grammar, for ease of checking.
wesleytodd
approved these changes
Jul 17, 2024
bewinsnw
commented
Jul 18, 2024
bewinsnw
commented
Jul 18, 2024
|
Hey, can we fix up the lint issues? After that I think we can land this and update in both |
🤦 that's what I get for doing those last two commits in the online editor. Fixed, thanks |
|
I think that coveralls just glitched out. I can see at https://coveralls.io/builds/68891763 that the coveralls run was successful, but it looks like it never reported back to github. Just needs a kick. |
hdtmccallie
added a commit
to hdtmccallie/jshttp-cookie
that referenced
this pull request
Oct 1, 2024
…C validations These tests are to help illustrate vulnerabilities in the cookie name, domain and path strings. The lack of filtering delimiters like semicolon and comma is the major concern but other characters can present security problems as well. [PR jshttp#167][1] fixes these vulnerabilities and tests should pass with those new validations added. [1]: jshttp#167
hdtmccallie
added a commit
to hdtmccallie/jshttp-cookie
that referenced
this pull request
Oct 2, 2024
…ations These tests better align with the proper RFC rules for the cookie attributes of `name`, `domain`, and `path`. These test are meant to be implemented along with [PR jshttp#167][1] that adds more fine-grained validations based on RFC rules. [1]: jshttp#167
2 tasks
6 tasks
djskinner
added a commit
to djskinner/cookie
that referenced
this pull request
Oct 9, 2024
To fix vulnerability jshttp/cookie#167
1 task
1 task
1 task
1 task
KnisterPeter
added a commit
to KnisterPeter/remix
that referenced
this pull request
Nov 7, 2024
The version 0.6.0 of the `cookie` package has a security flaw described here (jshttp/cookie#167). This PR does update the library to the closest fixed version. Closes remix-run#10077
KnisterPeter
added a commit
to KnisterPeter/remix
that referenced
this pull request
Nov 7, 2024
The version 0.6.0 of the `cookie` package has a security flaw described here (jshttp/cookie#167). This PR does update the library to the closest fixed version. Closes remix-run#10077
This was referenced Nov 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #165. Previously, validation on serialization used the field-content regexp from RFC7230 to perform all checks. However, that is the regexp for the cookie header as a whole, but each individual part of a cookie has a tighter restriction.
In the bug report #165 I demonstrated that whitespace in names and values was invalid but allowed by the field-content pattern. In this code I started by adding tests for those two cases, then added the expressions derived from the RFC; the relevant portions of the RFC have been inlined as comments.
Removing the field-content regexp unearthed that as well as those two it was being used to validate domain names and paths. Paths are fairly unrestricted (being any ascii character except control characters and semicolon) but the code was wrong here too - it allowed all 8-bit characters not just 7-bit characters.
Domain names have a well recognised pattern, there are only a couple of gotchas: RFC6265 explicitly says RFC1123 applies, so the leading character of a label is allowed to be a digit; and while I wondered for a moment if this should allow things like [::1] the domain matching section of https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.3 teaches that domain values are not ip addresses.