Shulou(Shulou.com)05/31 Report--

How to comprehensively use Self-XSS and OAuth misconfiguration to achieve Stored-XSS, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

The following is a combination of two low-risk vulnerabilities, Self-XSS and OAuth misconfiguration, to form a combing process of Stored XSS, only when the train of thought is expanded. Due to the confidentiality of the test, the target test site uses redacted.com instead of the description.

Loophole discovery

In an invitation test project that the HackerOne platform participated in, I found a Self XSS vulnerability in the AngularJS client template and a misconfiguration vulnerability in the OAuth implementation. Individually, these two vulnerabilities are low-risk vulnerabilities and do not cause serious hidden dangers. But through my combination of them, I can form a perfect Stored XSS!

The target testing site redacted.com, which mainly provides file storage services, is a bit like Google Drive and DropBox. Users can upload, download and share files by signing up to use this platform.

The place where XSS exists is located in the file name of the file to be uploaded. If you change the file name of the file to be uploaded to {{constructor.constructor ('alert (1)')}} .jpg, it will cause XSS in the upload file management panel. Ah, but it is a Self XSS.

After testing, there is an easy way to turn the Self XSS into Stored XSS, which is to share the upload link of the file with other users, which will cause Stored XSS when the file is imported from the upload panel with the same file name. But here, I also want to show you another interesting way to make the transition to Stored XSS.

OAuth misconfiguration

In the settings menu, I found a function that can import files from DropBox. With this function, users need to associate redacted.com applications with Dropbox accounts under the OAuth mechanism. Here, let's briefly introduce the general OAuth mechanism of redacted.com applications:

1. First, the user clicks the Dropbox association button, and then a GET request is generated:

Https://dropbox.com/oauth3/authorize?client_id=***********&response_type=code&state=****************&redirect_uri=https%3A%2F%2Fwww.redacted.com%2Faccount%2Fsettings%2Fdropbox-callback

2. Next, the user of the current redacted.com app will jump to Dropbox, log in to Dropbox and allow the button to click:

3. After clicking allow Allow, a GET request is sent to redacted.com with state parameter and verification code auth_code, as shown in the red box below:

4. After the redacted.com backend receives and processes the GET request, the user's Dropbox account can be synchronized with the current redacted.com application, and all Dropbox-related documents can be imported into the redacted.com application.

In the process of testing this OAuth mechanism, I aimed to find out if I could link my Dropbox account to other redacted.com applications, but found nothing.

The redirect_uri involved is white, the state parameters are reasonable, auth_code cannot be reused twice, and so on. I also tested the state parameters, that is, whether the redacted.com application validates it with the current user session, and there is no problem.

So, based on the above tests, I certainly can't use the link https://www.redacted.com/account/settings/dropbox-callback?state=********code=********** from Dropbox to associate with other redacted.com user accounts.

Out of curiosity, I deleted the state parameter from the https://www.redacted.com/account/settings/dropbox-callback?state=********code=********** link, changed it to https://www.redacted.com/account/settings/dropbox-callback?code=**********, and put it in other user accounts on redacted.com. Surprisingly, my Dropbox account was then associated with other user accounts.

In other words, I can associate my Dropbox account with anyone else's redacted.com account with only one GET request. Here, you may have questions, I do not use a Dropbox account to log in to the redacted.com app, so there can be no account hijacking. But as mentioned earlier, there is a XSS in the name of the file to be uploaded, so we can consider making the most of it.

Vulnerability exploitation scenario

1. In Dropbox, upload a malicious file named {{constructor.constructor ('alert (1)')}} .jpg, which is allowed by Dropbox

2. Send the final OAuth link https://www.redacted.com/account/settings/dropbox-callback?code=********** that Dropbox verifies the redacted.com application and does not contain state parameters to the target victim.

3. When the victim's redacted.com app is associated with our Dropbox account, once he imports that malicious file into the redacted.com app, our filename XSS payload will be executed.

The problem here is that although the redacted.com backend validates the user's state parameter with the current session session, it does not verify its existence. The verification logic of the redacted.com backend looks something like this:

If (isset ($_ GET ['state'])) {if ($_ GET [' state']! = current_user_state) ACCESS DENIED exit ()} ACCESS GRANTED

Therefore, using the low-risk misconfiguration of OAuth and Self XSS, the harmful Stored XSS is finally realized.

After reading the above, do you know how to make use of Self-XSS and OAuth misconfiguration to achieve Stored-XSS? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.