-
Notifications
You must be signed in to change notification settings - Fork 125
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
Fix RUSTSEC-2020-0031 #190
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Thanks!
Could you please also add a test to the unit-tests in the same file, with the RUSTSEC-reference to highlight why never breaking this test is important?
Unit test added with a comment; please let me know if you want more detail. I waffled for a long time about making |
I read up on the spec. From "https://tools.ietf.org/html/rfc7230#section-3.2.3":
It also declares that a "header-name" = "token", which is a sequence of symbols, where whitespace is not accepted. In short; I think the proper mitigation is to error out if header-name has any whitespace. Sorry for not catching this in previous review. |
No, that's fine, I'm happy to error out - I mentioned the weirdness because I was concerned, but I wasn't sure how firm the RFC was being. In one part of the RFC, |
Now returns
Please let me know if you want any other changes made. |
Super! Could we perhaps also add the following to input-test.rs to verify the recommended RFC-behavior? (I don't think I can add to your PR?)
|
I thought you deserved the credit for that test, since all I did was add a comment and change a typo in another comment. :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This now looks good to me, but I'll wait a few days before merging, to allow some other (real) maintainer chime in.
As identified in RUSTSEC-2020-0031, normalizing the value of a header field (through the use of `str::trim`) can make applications based on this library vulnerable to HTTP request smuggling if the immediate upstream load balancer interprets the malformed header in a different way. This backported patch based on a PR opened against master. [1] [1]: tiny-http#190
As identified in RUSTSEC-2020-0031, normalizing the value of a header field (through the use of `str::trim`) can make applications based on this library vulnerable to HTTP request smuggling if the immediate upstream load balancer interprets the malformed header in a different way. This backported patch based on a PR opened against master. [1] [1]: tiny-http#190 Co-authored-by: Ben Stern <bstern@fortian.com>
Is there anything else that should be done here? |
Thanks! @rawler In the future, feel free to merge! No need to wait on me or tomaka. |
Without this fix:
With this fix:
Fixes #173.