OAuth redirect to /code is insecure

[hitsthings]

In your article about OAuth, your code for a dialog has a button which sends the browser to /code where it will be sent to the client app with an authcode. This implies that a request to GET /code will generate an authcode, which is vulnerable to csrf.

That is, instead of the client app evil.com sending users to oauth_dialog.html, it could send them directly to /code and be given an authcode for that user without the user doing anything at all. They could do this in a hidden iframe and the user wouldn't even know that evil.com can now act as them on your service.

To prevent this, /code should use some kind of CSRF token or otherwise protect from CSRF. https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html This usually is done with a POST instead of GET because you could, for example, use the LAX SameSite cookie policy and be protected. CSRF on GET requests also has drawbacks from having a token in the URL - most people don't use GET for this.

In your article, I would at least switch to a POST to /code and mention the concept of CSRF. Otherwise readers are likely to be implementing this in an insecure if they follow your example.

Cheers!

[vkarpov15]

Hmm that's a good point. But normally hitting /code would require being logged in to the authorizing site - if someone has access to your auth token, CSRF is the least of your worries.

Switching to POST is a good idea as well

[hitsthings]

It's possible that I'm missing something, but I don't think CSRF is the least of your worries here.

Imagine your /code endpoint is facebook.com/code . Everyone is logged into facebook.com. Then you are browsing the internet and happen upon evil.com. Behind the scenes, evil.com opens an iframe at URL facebook.com/code?successUrl=evil.com/oauth (or just redirects the browser to that URL)

So Facebook says "oh look you are logged in and asking for an authcode, here you go. I'll send you back to evil.com/OAuth?authcode=blah" and now evil.com has an authcode for you.

This is not possible if Facebook made /code csrf protected. The only way to get to /code would be via facebook.com/dialog and the user explicitly saying "OK".

[vkarpov15]

Hmm ok, you have a valid point. Correct me if I'm wrong, but there's no way to make an iframe do a post request from outside the iframe, right?

[hitsthings]

You can make a standard form post to anywhere. E.g. evil.com can do <form action='facebook.com' method='post'>...</form>. And then form.submit()

This is not prevented by same origin policy. CSRF tokens are one way to prevent it. Standard forms can't post valid JSON either, so I believe that is safe even without a token. Check out that owasp page I linked for the various options.