Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix double authentication via RememberMe resulting in wrong RememberMe cookie being set in client#46760

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
fabpot merged 1 commit intosymfony:5.4fromheiglandreas:allowOldTokensToBeUsed
Jun 26, 2022

Conversation

@heiglandreas
Copy link
Contributor

@heiglandreasheiglandreas commentedJun 24, 2022
edited
Loading

QA
Branch?6.0
Bug fix?yes
New feature?no
Deprecations?no
TicketsThere has not yet an issue opened for this.
LicenseMIT
Doc PRn.a.

In the RememberMe feature we have noticed that with a custom tokenVerifier it is possible to verify an old token. That works as expected but leads to the problematic issue that it will still result in the old token being integrated into the cookie that is sent back to the client.

So the flow is as follows:

  • Customer sends a request "A" withrem-cookie with token "tokenA"
  • The user is authenticated via the token "tokenA", the token is refreshed with "tokenB".
  • Customer sends a request "B" withrem-cookie with token "tokenA"
  • Set-Cookie is sent back to the customer in response to request "A" with Remember-Me token "tokenB"
  • The user is authenticated via the token "tokenA" via a custom verifier. The last token was created less than 60 seconds ago, so let's not refresh the token but resend the current token.
  • Set-Cookie is sent back to the customer in response to request "B" with Remember-Me token "tokenA"
  • Remember-Me token "tokenA" overwrites the previously received token "tokenB" in the client.
  • Customer sends a request "C" withrem-cookie with "tokenA"
  • The user is not authenticated any more as the custom.verifier no longer accepts old token "tokenA" and "tokenA" doesn't match the persisted token "tokenB". Therem-cookie is overwritten withdeleted.

This PR will pass the persisted token (in the example "tokenB") in request "B" instead of the provided token (in the example "tokenA") and therefore not causing an overwrite of the Remember-Me cookie with a wrong value and a continuing functionality also when authentication-requests are sent within one minute of one another.

How that can happen? By using double clicks for example in certain setups where then two authenticating requests are sent right after one another...

@carsonbot
Copy link

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has acontribution guide which I suggest you to read.

In short:

  • Always add tests
  • Keep backward compatibility (seehttps://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (seehttps://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.2 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@heiglandreasheiglandreas changed the titleAdd test to handle external validationsFix double authentication via RememberMe resulting in wrong RememberMe cookie being set in clientJun 24, 2022
@heiglandreasheiglandreas changed the base branch from6.2 to6.0June 24, 2022 08:08
@carsonbot
Copy link

Hey!

I think@Seldaek has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

Seldaek reacted with laugh emoji

@Seldaek
Copy link
Member

Probably should target 5.4 but otherwise lgtm!

@fabpot
Copy link
Member

Thank you@heiglandreas.

@fabpotfabpotforce-pushed theallowOldTokensToBeUsed branch from2044ee3 to4dff49fCompareJune 26, 2022 10:08
@fabpotfabpot merged commita390266 intosymfony:5.4Jun 26, 2022
@zerkms
Copy link
Contributor

Does this not break the series-based security? Now ifrequest-A is sent from the valid user, andrequest-B is sent from a malicious user that stole a token, then you return them the new valid token again.

See the solution from my#42343 which is free of this problem.

@zerkms
Copy link
Contributor

@Seldaek it looks like I was too quick to close my report right?

@wouterj
Copy link
Member

@zerkms can you please open a pull request that adds a failing test showing your use-case, and adds your solution - to show that it fixes both use-cases?

@zerkms
Copy link
Contributor

@wouterj it's a security vulnerability report, do we really need a PR to explain how the series-based remember me works?

@zerkms
Copy link
Contributor

Btw, PR is coming in next 10-15 minutes.

@wouterj
Copy link
Member

If you verified it is broken, please follow the procedure inhttp://symfony.com/security to report security vulnerabilities.

@zerkms
Copy link
Contributor

PR is coming, it does not need a dedicated report, all details have already been exposed here.

@zerkms
Copy link
Contributor

#47488 PR is published.

zerkms pushed a commit to zerkms/symfony that referenced this pull requestSep 5, 2022
nicolas-grekas added a commit that referenced this pull requestSep 8, 2022
…ond consequent request (Ivan Kurnosov)This PR was merged into the 5.4 branch.Discussion----------[Security] Fix valid remember-me token exposure to the second consequent requestClose#42343Fix#46760| Q             | A| ------------- | ---| Branch?       | 5.4| Bug fix?      | yes| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->| Tickets       |Fix#42343,Fix#46760 <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->| License       | MIT| Doc PR        | symfony/symfony-docs#... <!-- required for new features --><!--Replace this notice by a short README for your feature/bugfix.This will help reviewers and should be a good start for the documentation.Additionally (seehttps://symfony.com/releases): - Always add tests and ensure they pass. - Bug fixes must be submitted against the lowest maintained branch where they apply   (lowest branches are regularly merged to upper ones so they get the fixes too). - Features and deprecations must be submitted against the latest branch. - For new features, provide some code snippets to help understand usage. - Changelog entry should followhttps://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry - Never break backward compatibility (seehttps://symfony.com/bc).-->#46760 PR together with a fix produces a security vulnerability when a malicious actor may get a **new and valid** remember me token if makes a request right after the legit user.Commits-------62ceded Bug#42343 [Security] Fix valid remember-me token exposure to the second consequent request
symfony-splitter pushed a commit to symfony/security-http that referenced this pull requestSep 8, 2022
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fabpotfabpotfabpot approved these changes

@wouterjwouterjAwaiting requested review from wouterj

@chalasrchalasrAwaiting requested review from chalasrchalasr is a code owner

@lyrixxlyrixxAwaiting requested review from lyrixx

@ycerutoycerutoAwaiting requested review from yceruto

@dunglasdunglasAwaiting requested review from dunglas

@OskarStarkOskarStarkAwaiting requested review from OskarStark

@jderussejderusseAwaiting requested review from jderusse

@xabbuhxabbuhAwaiting requested review from xabbuh

+1 more reviewer

@SeldaekSeldaekSeldaek approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

5.4

Development

Successfully merging this pull request may close these issues.

7 participants

@heiglandreas@carsonbot@Seldaek@fabpot@zerkms@wouterj@xabbuh

[8]ページ先頭

©2009-2025 Movatter.jp