You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: