Disclaimer : Couldn't find any reference on the subject so I will use a questionable tool called "logic". If someone find any good reference, please add them.
CSRF is dangereous
There is no doubt about it and OAuth2 is no exception. In fact, there are multiple ways that you can exploit CSRF attack while using OAuth2. The reason is that there are multiple message that are sent that could be use to trigger a CSRF attack. The section OAuth2 Spec Section 10.12 gives a good overview of what you could do with CSRF
But, let's look at what happen in details when a user want to login using OAuth2. In our example, we will have the following actors :
- The user (you and your browser)
- The attacker (usually a malicious website)
- The client (web application you are using)
- The provider (oauth2 server that authenticate the user)
Then, let's look at what happen from the user point of view when he tries to authenticate with the provider.
- The user click a link on the client website and get redirected to the provider authentication form
- The user authenticate with the provider and get redirected to the client website where he gets authenticated too, automatically
Where can we attack?
From the user point of view, it's just 2 simple steps but there is multiple places where you can attack it. One of the root problem here, is that often the OAuth2 provider will redirect you automatically, if you are already logged in. A good example, is stackoverflow. See this answer for details :
OAuth2 Cross Site Request Forgery, and state parameter
So the different attacks are :
An attacker can replace the authorization code with his own to make you login into his account instead of yours. Might look like a crazy idea but if you decide to enter some confidential information in his account, he now has access to it. Ex.: bank information
An attacker can generate a valid provider link on his machine and then he serves it to you, if the provider is redirecting automatically then you will be logged in to the service the attacker want to attack.
The attacker make you generate a valid provider link from the client website (only works if the link is generated via a post/get on a static url), then if the provider is redirecting automatically you will be logged in to the service of the attacker want to attack.
How to protect against them?
Simple, you just need to pass your CSRF anti-forgery token in the state parameter of OAuth2 to protect against #1 and #2. Then, to protect against #3, you need to make sure that the link cannot be generated without the user interaction, meaning protect that link with CSRF protection. But back to #1 and #2...
By including, a CSRF token as the state, you will defeat those attacks as it will be impossible for the attacker to serve you links that you didn't generate yourself. A simple implementation of a CSRF token is a random number that is stored in the session and then included in every form sent by that by a user. If the form contain the token, the client consider it as valid. If it doesn't contain it, then the client assumes that the request is invalid.
Usually, that CSRF token is only accessible to the user/browser and the client, but in the case of OAuth2, more parties get access to it. To understand what to do, we need to know which are these additional parties.
The Answer : Just send the token
So, in that case, the token will be known to
- The client (the one who created it)
- The user
- The provider
It's a simple round trip over HTTPS. An attacker cannot insert himself in that conversation so you don't need to worry about that.
Do you need to protect the token against the provider?
No. If the OAuth2 provider is malicious you have already lost. He doesn't need your CSRF token to take over all your accounts if he wants. When you chose to use OAuth2, you basically made him god of all your user accounts.
Don't worry too much how you send the CSRF token; just make sure you send it. Also, the fact that it's sent as a url parameter would be another point to worry for a permanent password but since those tokens are temporary is shouldn't be much of a problem.