42

I use OAuth2.0 of identityserver3 for SSO in company, I cannot understand how does the state parameter prevent the CSRF.

I have copied the attack flow as below:

1.Mallory visits some client's website and starts the process of authorizing that client to access some service provider using OAuth

2.The client asks the service provider for permission to request access on Mallory's behalf, which is granted

3.Mallory is redirected to the service provider's website, where she would normally enter her username/password in order to authorize access

4.Instead, Mallory traps/prevents this request and saves its URL(Callback Url)

5.Now, Mallory somehow gets Alice to visit that URL. If Alice is logged-in to the service provider with her own account, then her credentials will be used to issue an authorization code

6.The authorization code is exchanged for an access token

7.Now Mallory's account on the client is authorized to access Alice's account on the service provider

I can understand step 1 to step 4. But from step 5 I got some confusion. Accordding to my understanding, in step 5 Alice visit the Callback Url when she is logged-in, and then the server just use the authorization code to access the OAuth service provider to get an openid and access token in backend, and then Alice's browser just executing login with Mallory's account and access token.What is the relationship with Mallory's browser? Could you explain it in detail please? Thank you for taking time to read my word!

Farwell_Liu
  • 645
  • 1
  • 7
  • 17

2 Answers2

85

I think steps 3 and 4 are not quite right. I've edited your example to show how I think the attack works.

1.Mallory visits some client's website (e.g. https://brilliantphotos.com) and starts the process of authorizing that client to access some service provider using OAuth (e.g. Acebook - as brilliantphotos.com allows its users to post pictures to their Acebook page)

2.brilliantphotos.com redirects Mallory's browser to Acebook's Authorisation Server requesting a redirect back to itself once auth is done.

3.Mallory is redirected to the Authorisation Server, where she enters her Acebook username/password in order to authorize access.

4.After successful login, Mallory traps/prevents the subsequent redirect request and saves its URL(Callback Url with an auth code related to Mallory) e.g.

https://brilliantphotos.com/exchangecodefortoken?code=malloryscode

5.Now, Mallory somehow gets Alice to visit that URL (maybe as a link on a forum post...) note that Alice may already be logged-in to brilliantphotos.com with her own account.

6.Alice clicks the link to brilliantphotos.com and the authorization code is exchanged for an access token (access to naughty Mallory's account). If Alice is logged in then brilliantphotos.com could conceivably associate Alice's account with the newly minted access token.

7.Now if Alice continues to use the brilliantphotos.com website, the client may inadvertently be posting pictures to Mallory's account on the service provider (Acebook).

If a state parameter was maintained by brilliantphotos.com then Mallory's state code would be bound to her browser but not Alice's. Therefore brilliantphotos.com would not be able to correlate the state code with Alice's browser session when Alice clicks on the malicious URL.

iandayman
  • 4,357
  • 31
  • 38
  • I appreciate you iandayman very much. I have understood it. But I have another question. After attacked success, the victim is the OAuth service provider, not https://brilliantphotos.com. Am I right? – Farwell_Liu Mar 15 '16 at 02:56
  • 2
    Alice is the victim: the resource owner. – iandayman Mar 15 '16 at 08:08
  • yes,yes, Alice is the victim. I'm sorry that I didn't express my meaning clearly. I mean that After attacked, which site's data may be modified mistakenly or illegal? Accordding to my understanding, this CSRF can't affect data rightness in database of brilliantphotos.com, but affect the data rightness of the OAuth service provider. Am I right? – Farwell_Liu Mar 15 '16 at 08:59
  • 1
    @Farwell_Liu Both service and client. The service provider is processing messages for one account which are meant for another. And brilliantphotos.com may be holding incorrect data too - e.g. they may be storing alice's user details with mallory's access and refresh token. – iandayman Mar 15 '16 at 09:21
  • I have understood it completely. Thank you iandayman very much! – Farwell_Liu Mar 16 '16 at 03:35
  • 2
    @iandayman In stage 6, why does Alice being already logged in with her own account matter? does it change anything? Also, how would a client application associate a state parameter with a specific browser session, given there are two endpoints in play: the `/auth` endpoint that redirects to the OAuth2 provider and the `/exchangetokenforcode` endpoint – uvuv May 18 '20 at 09:48
  • @uvuv I know it might be late but still. What's important to understand that client internally will make an association: "Since Alice is logged in then the token I'll get in exchange for a code will allow me to post pictures to her Acebook account". Authorization code in itself carries information where pictures will be posted to. – Maksim Kviatkouski Dec 29 '21 at 08:18
5

Besides iandayman's already great answer, you can also get some inspiration from this blog post, or at least you can take a look into its illustration.

redirect attact

PS: Credit goes to original blog author.

Community
  • 1
  • 1
RayLuo
  • 17,257
  • 6
  • 88
  • 73
  • 1
    That blog post link is now dead. – andrea Sep 06 '18 at 15:37
  • 2
    @andrea, well, it is unfortunate (and perhaps inevitable) the referencing source becoming dead, eventually. It did not feel natural to quote the entire blog post in a stackoverflow answer. But, at least now we still have that picture, which essentially illustrate [the other answer here](https://stackoverflow.com/a/35988614/728675). So you do not really miss much. – RayLuo Sep 06 '18 at 17:26
  • 2
    The article can still be found via the WayBackMachine :) https://web.archive.org/web/20170211202441/http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html – Mathias Conradt Dec 14 '18 at 17:56