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

[Security] Fail gracefully if the security token cannot be unserialized from the session#25669

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

Conversation

@thewilkybarkid
Copy link
Contributor

QA
Branch?2.7
Bug fix?yes
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets
LicenseMIT
Doc PR

If the security token in the session can't be unserialized, anE_NOTICE is issued. This prevents it (and provides a better log message if it's not even a__PHP_Incomplete_Class).

This is similar to#24731, but I saw it triggered when changing OAuth library (elifesciences/journal#824), so the token class itself no longer exists. (I want to avoid having to manually invalidate all sessions, as not all sessions use that token class.)

@thewilkybarkid
Copy link
ContributorAuthor

Travis failure looks unrelated.

@nicolas-grekasnicolas-grekas added this to the2.7 milestoneJan 3, 2018
@nicolas-grekas
Copy link
Member

Thanks for the fix, looks legit. I think for a full fledged implementation, we should borrow fromResourceCheckerConfigCache::safelyUnserialize().
The currently proposed logic is not robust enough AFAIK.

try {
$unserialized =unserialize($serialized);
}catch (\ErrorException$e) {
// To be rethrown after restoring the error handler.
Copy link
ContributorAuthor

@thewilkybarkidthewilkybarkidJan 4, 2018
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Can usefinally in Symfony 3+.

sstok reacted with hooray emoji
$token =$this->unserialize($serializedToken);
}catch (\ErrorException$e) {
if (null !==$this->logger) {
$this->logger->warning('Failed to unserialize the security token from the session.',array('key' =>$this->sessionKey,'received' =>$serializedToken,'exception' =>$e));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Shouldn't this be an error instead? It means that something goes wrong somewhere.

Can you renamekey tosession_key? This should describe the function a bit more when viewing the logs. At first I thought this was the firewall (context) key, but that's included in the session key.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Can do, though I was keeping it in-line with

$this->logger->warning('Expected a security token from the session, got something else.',array('key' =>$this->sessionKey,'received' =>$token));

Copy link
Contributor

@linaorilinaoriJan 4, 2018
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Fair enough, best to keep it consistent then (regarding the key).

Copy link
Member

@nicolas-grekasnicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

feels like nobody noticed my previous comment, here it is :)

Thanks for the fix, looks legit. I think for a full fledged implementation, we should borrow from ResourceCheckerConfigCache::safelyUnserialize().
The currently proposed logic is not robust enough AFAIK.

@thewilkybarkid
Copy link
ContributorAuthor

@nicolas-grekas Implemented in23e6fee.

@nicolas-grekasnicolas-grekasforce-pushed theaccess-token-unserialization branch from23e6fee to219118aCompareJanuary 7, 2018 08:41
@nicolas-grekasnicolas-grekasforce-pushed theaccess-token-unserialization branch from219118a to053fa43CompareJanuary 7, 2018 09:03
Copy link
Member

@nicolas-grekasnicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@thewilkybarkid I pushed some changes directly on your fork, PR ready on my side.

@fabpot
Copy link
Member

Thank you@thewilkybarkid.

@fabpotfabpot merged commit053fa43 intosymfony:2.7Jan 8, 2018
fabpot added a commit that referenced this pull requestJan 8, 2018
…t be unserialized from the session (thewilkybarkid)This PR was merged into the 2.7 branch.Discussion----------[Security] Fail gracefully if the security token cannot be unserialized from the session| Q             | A| ------------- | ---| Branch?       | 2.7| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets || License       | MIT| Doc PR        |If the security token in the session can't be unserialized, an `E_NOTICE` is issued. This prevents it (and provides a better log message if it's not even a `__PHP_Incomplete_Class`).This is similar to#24731, but I saw it triggered when changing OAuth library (elifesciences/journal#824), so the token class itself no longer exists. (I want to avoid having to manually invalidate all sessions, as not all sessions use that token class.)Commits-------053fa43 [Security] Fail gracefully if the security token cannot be unserialized from the session
@thewilkybarkidthewilkybarkid deleted the access-token-unserialization branchJanuary 10, 2018 14:27
@nanasessnanasess mentioned this pull requestFeb 23, 2018
6 tasks
@fabpotfabpot mentioned this pull requestMay 7, 2018
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fabpotfabpotfabpot approved these changes

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

@chalasrchalasrchalasr approved these changes

+1 more reviewer

@linaorilinaorilinaori left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

2.7

Development

Successfully merging this pull request may close these issues.

6 participants

@thewilkybarkid@nicolas-grekas@fabpot@linaori@chalasr@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp