-
Notifications
You must be signed in to change notification settings - Fork 86
Fix invalid exception from urlencoded cookie value #23
Fix invalid exception from urlencoded cookie value #23
Conversation
@@ -302,7 +302,7 @@ public function getName() | |||
*/ | |||
public function setValue($value) | |||
{ | |||
HeaderValue::assertValid($value); | |||
HeaderValue::assertValid(urlencode($value)); |
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.
When this won't be valid? if there no case exists then remove whole line.
96290bd
to
83bcfc1
Compare
I see, yeah that's a much better solution. I've replaced my initial commit with one that follows your suggestions. |
$header = new SetCookie("leo_auth_token", "example\r\n\r\nevilContent"); | ||
$this->assertTrue(HeaderValue::isValid($header->getFieldValue())); |
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.
I preffer if you assertEquals against the __toString() output. Will be more clear to understand because the encoded characters will be visible while reading this code.
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.
Could you add an additional test method for unit check of setValue
?
Okay. (I assume the extra test method is what you were looking for, if not let me know) |
@weierophinney Please add this one to 2.4.8 LTS |
Fix invalid exception from urlencoded cookie value
Tagged in release-2.5.2 and 2.4.8. |
This is my alternative solution to #15, as a replacement for the existing PR #16.
This PR fixes the problem by simply re-urlencoding the cookie value before validating it. This is allowable because the actual cookie as output also urlencodes the value (see SetCookie::getFieldValue.
As a concrete example, this PR removes the test
testPreventsCRLFAttackViaConstructor
. The change makes that test fail, but the test was already failing for an input that wouldn't have actually enabled a CRLF attack. The "evil" example is:However, under both the existing code and after the commit in this PR, that SetCookie header creates no CRLF injection problems, because SetCookie already automatically urlencodes values on output. So, the output of
$header->toString()
on the above "evil" cookie is already safe:I think this change is the best way to fix the regression without compromising the security the validation was introduced to provide and without surprising users by changing the header's behavior.
Fix #15
Supersede & close #16