-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Correct minor security issue for cookie prefixes #1965
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
Conversation
Please use security@palletsprojects.com to responsibly report security issues. Your assessment of the severity shouldn't factor into that. For any project, if you're not sure, use another means of contact to determine the correct one. Additionally, definitely don't open a PR over an issue, as we can't delete PRs like we can issues. |
That doesn't seem correct. |
I'm not clear how this is an issue that should be addressed by Werkzeug. If browsers are using the encoded/quoted name rather than the real name for this check then the issue should be reported to and fixed by browsers. |
Thank you for that feedback and I apologize for not doing things right. I wasn't aware PRs couldn't be deleted and couldn't find any published address but will try better next time.
Per the spec linked above:
So a cookie name cannot contain "separators" which would include double quote characters. You can also see this in the MDN documentation at: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Attributes
I may not have explained it well so I will try again. This is my best understanding of the issue. Feel free to correct any misunderstandings I have:
Hopefully my understanding of the issue is correct enough that it helps you see the issue. Perhaps also an example attack might help.
There are other attack scenarios (such as MITM for |
35e618d
to
7af27ef
Compare
This was against RFC 6265 and potentially allowed setting __Secure prefixed cookies.
7af27ef
to
8f8507b
Compare
NOTE: I did not see any special contact address for security issues. Seeing as this is a quite low severity issue I am just opening a public ticket. Feel free to delete if this is not the right thing to do.
Browsers assign special meaning to cookies prefixed with either
__Secure-
or__Host-
. Due to the unquoting of cookie keys done by Werkzeurg this protection can be bypassed by creating a cookie with these prefixes inside quotes. The browses will not enforce the requirements needed by those prefixes while the server will not be able to differentiate between the unsecure quoted cookie and the more secure unquoted cookie.While the cookie spec encourages encoding the cookie value it does not specify anything with regard to cookie name and the character set for the cookie name is more restricted.
This issue was brought up for the Rails platform recently which is what prompted me to see what other platforms have the same or similar issues. See that investigation for more information:
https://hackerone.com/reports/895727
I have created what I hope to be a POC of this issue at:
https://github.com/eric1234/werkzeug-cookie-prefix-poc
This commit changes the code so that only the value is unquoted and the key is not. If someone provides a quoted key then the
quote will become part of the cookie name.
Checklist:
CHANGES.rst
summarizing the change and linking to the issue... versionchanged::
entries in any relevant code docs.pre-commit
hooks and fix any issues.pytest
andtox
, no tests failed.