Skip to content
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

Token can be guessing, am i right? (Security question) #1

Open
brutto opened this issue Jun 16, 2017 · 0 comments
Open

Token can be guessing, am i right? (Security question) #1

brutto opened this issue Jun 16, 2017 · 0 comments

Comments

@brutto
Copy link

brutto commented Jun 16, 2017

Hello @schnittstabil, thanks for middleware, its great job!

In out project we use AngularJS(2) via API on cross domain. Also we have CORS for trusted domains only. API authorized by OAuth2 protocol + custom login/password implementation. Basic API method use standart access_token and it's ok, but on authorizations endpoints we use session and want to protect CSRF there.

I'll choose to use buildHeaderToHeaderMiddleware but still have a security question.

As i realized your middleware use encrypted token pattern. So well token signed and have ttl, thats really very usefull. But for submit this token to server back we must get it anyway (header in our case), right? For this puprose we use some of our API-endpoints to return xsrf-token in header.

So what if attacker get this token for himself from good.com and then use it with submit on his evil.com session request with this "correct" token? Even if we return csrf-token only for session users, attacker can be registered and take token as normal and then use it, because middlewre check only sign and ttl. Even with CORS-enable potentially attacker can create session and get tokens for use anytime on his evil.com (ttl check pass).

For this workaround it will be nice to have additional payload with getTokenService()->generate() for validatin current user. We can use already existed $rejectMiddleware with csrf-payload into $request->getAttribute(Guard::CSRF_PAYLOAD) for additional checking.

Am i right with security warning or probably misunderstating something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant