How does CSRF work without state parameter in OAuth2.0?

Question

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!

Answer 1

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.

Answer 2

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.

PS: Credit goes to original blog author.