Common security problems in OAuth authentication mechanisms

If the website uses the OAuth login mechanism, there is a simple method that allows attackers to log on to other users' accounts. The protection mechanism will not function, in addition, the OAuth mechanism can also be used for authentication.
Oau22. It is very popular now. Although many people do not have sufficient knowledge about OAuth, they cannot write proper and secure code. OAuth1 is incompatible with oau22. some services use the former, while others use the latter. There are a lot of unreliable articles about OAuth network. I spent a few hours reading the oau2specification document and found some interesting things. One of them will be discussed in this article.
The following is a very dangerous but common vulnerability that uses the OAuth mechanism to log on to a website.
 The following are some theories:
1. response_type = code is the authorization process of the server. It should be used when necessary, which is safer than response_type = token. The authorization server returns 'code' and the User-Agent of the User, and the client sends the content together with the User's certificate information to obtain 'Access _ token '. Callback information will be used after user authorization, as shown in the following figure. Site.com/oauth/callback? Code = AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI
2. I would like to remind you that OAuth is generally an authorization mechanism rather than an authentication mechanism. You may ask what is the difference between the two: the OAuth protocol only gives you the permission to use user resources on the provider server. However, the client often authenticates your permissions based on 'profile _ info'. Therefore, we can also regard it as an authentication framework.
 Conditions for malicious attacks: Using the OAuth Mechanism + adding OAuth provider Information to the configuration
 Attack OAuth step by step:
1. Select "client" that meets the preceding conditions-start the authentication process-click "Add OAuth Provider Login ". You need to get a callback from the provider but do not access it first. This is difficult-all modern browsers will jump automatically. I recommend using bundle FireFox + NoRedirect2, don't access the following URL (http://pinterest.com/connect/facebook? Code = AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI # _ = _), just save it under the or <iframe> label.



3. Now you need to make the user (a specific user or a random user on target.com) Send an HTTP request to your callbackURL. You can force them to access example.com/somepage.html, which contains <iframe src = URL>, send a message to his blog message board, and send an email or private message. The target must be logged on when an HTTP request is sent. Well done. Your oauth account has been connected to the account on site and com. Now, press "Log In withthat OAuth Provider"-you can directly Log on to the account at the site and com. Enjoy it: read private messages, send comments, change the payment details, and do whatever you want. In fact, this target account is yours. When you have enough fun, you only need to disconnect from the OAuth provider and log out. No one knows what happened, leaving no trace!
 How can we find the OAuth vulnerability?
1. If the website does not send the 'state' parameter and the 'redirect _ uri 'parameter is static and does not contain any random hash value-then it is affected. 2. I know that at least 10 + popular websites have been affected by this problem: pinterest, digg, soundcloud, snip. it, bit. ly, stumbleupon, and so on. If you know more websites, please be sure to contact me through homakov@gmail.com. 3, and Rails + Omniauth will also be affected by this issue. Have fun (about 23300 search results)