An often overlooked Oauth misconfiguration.

Good afternoon.

Today I will not tell you about typical vulnerabilities in oauth: there is no csrf check, you can change the redirect_uri, and so on. You can easily find all this on the Internet, because many articles have been written about this.

I want to tell you about a feature that I very often meet in popular private programs. I want to say right away that you should have at least a basic understanding of oauth.

Sorry in advance for my english.

So, let’s say you have oauth on your project.

As you can see, this project uses authorization via ok.ru (a popular Russian social network).

Let’s now look at the request:

As you can see, the developer made two mistakes here that will have a significant impact.

1. The developer made an intermediate link like https://www.example.com/auth/ok/
2. The developer did not add the csrf token to this request, because he thinks that state token will “protect him”.

Next, I give you 5 minutes to think about what this misconfiguration can lead to?

*5 minutes pass :3*

So, if you are a seasoned hacker, then you know that 99.9% of companies do not pay for csrf login / logout, and ok.ru is among these companies.

The complete execution plan for this vulnerability.

1) The victim logs in under our ok.ru account
2) We load this link into an iframe https://www.example.com/auth/ok/ on the victim’s side. Since we have already opened access to this project to our account through oauth, confirmation is not required.
3) The victim is linked to our ok.ru account
4) We enter the vulnerable site through ok.ru

I will attach the full payload in my twitter. VipItHunter1

For this vulnerability to lead to account hijacking, the project must have 2 vulnerabilities.
1) Uses oauth with intermediate link and without csrf token
2) There are social networks like ok.ru that do not pay for csrf login/unlogin.

If you have any questions, please ask me on Twitter.