Netease Open Platform third-party application oauth forced user Authorization Vulnerability

With this vulnerability, third-party applications registered on the Netease open platform can skip the page asking users if they are authorized, and directly obtain users' authorized access to user sensitive information.
The normal oauth authorization process should comply with the following steps (assuming that a Netease user has logged on): 1. At login, the application accesses http://api.t.163.com/oauth/request_tokento obtain the request token and request token secret4. The application redirects the target, like http://api.t.163.com/oauth/authenticate? Oauth_token = XXXXXXX & oauth_callback = XXXXXXX. Ask whether the user is authorized. This page details what permissions are granted to What app to help the user make a selection 5, the user clicks the authorization button, the browser sends the corresponding consent authorization information to the authorization server http://api.t.163.com/oauth/authenticate (POST command) 6, the application has obtained the authorization request token through the http://api.t.163.com/oauth/access_token in exchange for access token and access token secret this vulnerability lies in the malicious application can directly ignore step 3rd after step 4th, and execute step 5th, therefore, without the consent of the user (without the user's knowledge), we obtained the user's authentication vulnerability proof: to verify the existence of the vulnerability, we created an experiment app: Application name: oauth_vulnerability_test application type: tool class Consumer Key: ulHM02MWX0CFx75u application Creation Time: Our test code requires users to log on to Netease before clicking the application, but as long as the code is slightly improved, even if the user does not log on when clicking the application, we can guide the user to log on to http: // 158.132.20.52: 25006/t163_php_sdk/index_normal.php to access http through normal authorization: // 158.132.20.52: 25006/t163_php_sdk/index_attack.php can directly observe that this application can be authorized by the user without the permission of the user.

Solution:

Is it recommended that the user access the http://api.t.163.com/oauth/authenticate in step 1? Oauth_token = XXXXXXX & oauth_callback = XXXXXXX, add a random code. In the form that the user submits the authorization, the random code must be submitted at the same time to ensure that the submission form is indeed approved by the user.