Microsoft OAuth interface XSS can affect User Account Security

Microsoft OAuth interface XSS can affect User Account Security

One day, when I browsed Twitter information, I found a very interesting article, a CSRF vulnerability discovered by Wesley Wineberg on the Microsoft OAuth interface. This article also aroused my curiosity and confidence in finding another vulnerability in this place (The author is as confident as the mystery). Therefore, I plan to analyze this authentication interface in depth.
First, to use OAuth authentication on our test app, We need to register an app first. After searching, I found a link and click it to go to the "Microsoft Developer Center". I found that if I registered an app here, I was asked to enter the "Application name" and "language ".
Any point that allows user input may be the entry point that triggers xss, So I inserted the xss attack vector: '">. Unfortunately, this application rejects the submitted vector and returns an interesting error message:
 

From this error message, we can find that ''in my attack vector is blocked, but '(single quotes) or' (double quotation marks) are not filtered. So I made the following conjecture: If I can find other pages and put the content I entered above in the tag attribute or script tag, but it is not encoded, I can inject JavaScript code. I tried to input the attack vector "onload =" alert (1) and hoped that my attack vector could be added to HTML tags that support onload events.
After entering the address redirect_uri to be returned for OAuth authentication, I completed the registration and then got the link for OAuth verification on the app I registered (about Microsoft's oau2authentication, you can find more content here ).
Open this link and I was pleasantly surprised to find that my guess is correct. This authentication interface has an xss vulnerability.
 

In the source code of the page, we can better understand how the application parses the data I submitted, such
 

In row 3, my attack vector is not encoded, but put in the alt attribute (the data in alt is registered at the app (212nd by default )), the src value is the default value (if the app does not have an upload icon, the icon of this link is used by default). Because this image will exist, our onload event will be executed, cause xss.
Expanded results
Although I already have evidence to prove the existence of a vulnerability, I want to spend more time studying the impact of the vulnerability, using xss to "steal cookies" or "phishing" is too boring for me (smiling face )! So I made the following conjecture: Since this vulnerability exists on the user authentication page, users can choose to accept it based on their judgment (click "Yes) or refuse (click the "No" button) This application. If I can insert JavaScript code so that the "Yes" button is automatically executed, I can obtain the permission to access user resources without knowing it.
So I created a new app and filled in the attack vector that can implement My guess: "onload =" document. getElementById ('idbtn _ Accept '). click () "param =". When triggered by the onload event, this vector automatically simulates and click "Yes" to authorize the app to access users' private resources.
What are the most useful resources that hackers can obtain from their victims?
Once an attacker obtains the user's authorized token, the attacker can obtain the user's resources. The hacker can obtain the following fatal data:
[1] Reading all emails (via IMAP) on the Outlook account, or sending new emails as a user (via SMTP)
[2] Reading all files saved on OneDrive
[3] Reading all your images, videos, and audios
Here is a poc video:
How can this vulnerability be quickly spread?
Considering that this is a storage-type xss and does not require user interaction, we can say that xss can be triggered as long as a user accesses a link and put the link on a social application (Facebook, Twitter, etc, it also provides interesting stories to explain. I believe many people will be tempted!
However, it should be noted that to trigger the xss, the user must have logged on to Microsoft, but this should not be difficult?
Repair
Microsoft has fixed this vulnerability. All characters are now encoded as HTML objects.