-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[HttpFoundation] Send cookies using header() to fix "SameSite" ones #25348
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
nicolas-grekas
commented
Dec 6, 2017
•
edited
Loading
edited
Q | A |
---|---|
Branch? | 3.4 |
Bug fix? | yes |
New feature? | no |
BC breaks? | no |
Deprecations? | no |
Tests pass? | yes |
Fixed tickets | #25344 |
License | MIT |
Doc PR | - |
@@ -337,7 +337,7 @@ public function sendHeaders() | |||
} | |||
|
|||
// headers | |||
foreach ($this->headers->allPreserveCaseWithoutCookies() as $name => $values) { | |||
foreach ($this->headers->allPreserveCase() as $name => $values) { |
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.
The current cookie code distinguishes between urlencoding the cookie value and not doing that (raw), the setcookie()
function also performs some filtering and escaping as I understand it. As far as I can see in the code, the allPreserveCase()
function doesn't do that but just casts the Cookie
object to string
and as such isn't a 1-to-1 substitute for setcookie()
and setrawcookie()
, right?
Edit: Ah, I see in Cookie.php that it does distinguish between raw/non-raw and performs some checks. However a double-check to see what PHP does in setcookie()
might still be useful so there's no regressions, right?
Nop, the Cookie now understands how to stringify itself differently based
the raw or not raw. Therefore, we don't need PHP's `set*cookie`
…On Wed, 6 Dec 2017 at 18:13, Thom Hurks ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/Symfony/Component/HttpFoundation/Response.php
<#25348 (comment)>:
> @@ -337,7 +337,7 @@ public function sendHeaders()
}
// headers
- foreach ($this->headers->allPreserveCaseWithoutCookies() as $name => $values) {
+ foreach ($this->headers->allPreserveCase() as $name => $values) {
The current cookie code distinguishes between urlencoding the cookie value
and not doing that (raw), the setcookie() function also performs some
filtering and escaping as I understand it. As far as I can see in the code,
the allPreserveCase() function doesn't do that but just casts the Cookie
object to string and as such isn't a 1-to-1 substitute for setcookie()
and setrawcookie(), right?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#25348 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAxHETp-qltXfQNc_xmHHXVlwKnmRftaks5s9tkdgaJpZM4Q3nK_>
.
|
@sroze Yes, I realized that after examining the code more closely and so I edited my comment. Still, cross-referencing the code with PHP's implementation may be a good thing to do to prevent regression in behaviour. I'm not sure how new the Cookie code is, and the code that is currently there is not actually used to generate the final cookie at the moment, so it may be incomplete/untested? |
@ThomHurks here is the native implem: everything looks fine to me. |
@nicolas-grekas Not the case, there are some differences that I can spot:
|
I understand your concerns, and agree a bit. We will add integration
testing to this PR very soon. Highlighting the important scenarios that you
believe needs to be tested would be a very nice input from you! Could you
do so?
…On Thu, 7 Dec 2017 at 09:02, Thom Hurks ***@***.***> wrote:
@nicolas-grekas <https://github.com/nicolas-grekas> Not the case, there
are some differences that I can spot:
- Symfony does not check the value of value against the characters =,;
\t\r\n\013\014 whereas PHP does. Symfony only checks it against name
and PHP checks it agains name and value.
- When a cookie needs to be deleted, Symfony sets the max-age to
31536001 and the expiry to now - max-age but PHP just passes in expiry
= 1 and max-age = 0.
- PHP checks if the expiry date has a year greater than 9999.
- Symfony also urlencode's name, I don't see PHP do that.
- Symfony uses urlencode for the name vs rawurlencode for the value,
not sure why that difference is there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#25348 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAxHEcCjAYcpYVxNkRxVfnFdeovGgsknks5s96nCgaJpZM4Q3nK_>
.
|
I'd like to propose a plan:
|
I like this plan 👍
…On Thu, 7 Dec 2017 at 19:51, Nicolas Grekas ***@***.***> wrote:
I'd like to propose a plan:
- @sroze <https://github.com/sroze> would you like to submit a testing
infra for this? Could be heavily inspired by AbstractSessionHandlerTest
on 3.4
- @ThomHurks <https://github.com/thomhurks> would you like to submit a
separate PR on 3.3 to align the behavior with native PHP?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#25348 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAxHEbIHdt80LKCThXK49tqP3kTEwUoKks5s-EHXgaJpZM4Q3nK_>
.
|
@nicolas-grekas I will likely have time tomorrow to create a PR. |
@sroze @ThomHurks any progress? |
Regarding spectre attack and suggested mitigations should this be considered as a critical security fix? |
I don't think it has anything to do with the attacks you've mentioned. I did not get time to get ahead with this so if anybody would like until I get back to it, you're welcome 😉 |
@sroze I quote the part from https://www.chromium.org/Home/chromium-security/ssca that seems to imply this is actually relevant:
|
moving to the 3.4 milestone as the last bugfix release for 3.3 was published today |
e04c84a
to
b2785b0
Compare
30cac90
to
6386d39
Compare
6386d39
to
12aa1cd
Compare
ef09ba8
to
65a6ec1
Compare
65a6ec1
to
73fec23
Compare
Back on here, this PR now contains a second commit provided by @cvilleger, thank to him for working on it. The Response + Cookie classes are now functionnally tested, and their behavior is a bit more aligned to PHP native one:
It does for the name, but doesn't care for the value. HTTP allows anything so no reason to restrict like PHP.
Aligned
I don't see any reason, kept as is (and tested).
PHP should encode. Symfony does, that's OK.
Unrelated to the PHP vs Symfony delta, kept as is. Status: needs review |
@@ -162,13 +162,13 @@ public function testCookieIsCleared() | |||
public function testToString() | |||
{ | |||
$cookie = new Cookie('foo', 'bar', $expire = strtotime('Fri, 20-May-2011 15:25:52 GMT'), '/', '.myfoodomain.com', true); | |||
$this->assertEquals('foo=bar; expires=Fri, 20-May-2011 15:25:52 GMT; max-age='.($expire - time()).'; path=/; domain=.myfoodomain.com; secure; httponly', (string) $cookie, '->__toString() returns string representation of the cookie'); | |||
$this->assertEquals('foo=bar; expires=Fri, 20-May-2011 15:25:52 GMT; Max-Age=0; path=/; domain=.myfoodomain.com; secure; httponly', (string) $cookie, '->__toString() returns string representation of the cookie'); |
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 please update assertEquals()
calls to assertSame()
? (as done at ClientTest
).
Thank you @nicolas-grekas. |
…ite" ones (nicolas-grekas, cvilleger) This PR was merged into the 3.4 branch. Discussion ---------- [HttpFoundation] Send cookies using header() to fix "SameSite" ones | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #25344 | License | MIT | Doc PR | - Commits ------- 73fec23 [HttpFoundation] Add functional tests for Response::sendHeaders() e350ea0 [HttpFoundation] Send cookies using header() to fix "SameSite" ones
Added the RFC document:rfc6265 |
@nicolas-grekas you said:
This might be correct from a spec point of view, but FYI upgrading our app broke cookies with names "foo:bar:baz" as the : gets encoded and CloudFront's cookie whitelist does not recognize the encoded |
Also a related issue, clearCookie does not allow clearing cookies without urlencoding, so a cookie set without urlencoding can not be cleared. |
@Seldaek I think we can fix these. WOuld you mind opening an issue? |
…grekas) This PR was merged into the 3.4 branch. Discussion ---------- [HttpFoundation] don't encode cookie name for BC | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - As reported by @Seldaek in #25348 (comment) Commits ------- d28949b [HttpFoundation] don't encode cookie name for BC