How I Got $5000 for Out-of-Scope XSS

A few months ago I received an invitation to participate in a private bug bounty program on the HackerOne platform. I first ran my usual tests and found various vulnerabilities such as lack of access control (BAC), leakage of other users' authorization tokens, etc.

After I reported these vulnerabilities to the program, I noticed that XSS was considered out of scope according to their policy. The program's business was to provide services for creating content management systems and website builders. When creating an account, users receive a unique subdomain like .target.com, which they can customize.

Given the application's design, XSS was limited to affecting only its own subdomain, and the program excluded XSS on .target.com from coverage. This prompted me to look up the self-XSS vulnerability and try to link it to another vulnerability to show the more serious implications.

I was able to find several XSS chains that increased its impact. Since only one chain has been confirmed so far, I will only write a report on that one. When the remaining reports are resolved, I plan to publish separate materials for each of them. Now let's move on to the story itself.

It didn't take long to find self-XSS.

Now it's time to find another vulnerability to link to XSS. I started testing the website to identify bugs that could be combined with XSS. One of the vulnerabilities I decided to check was CORS misconfiguration. To test this I like to use a Burp extension called CORS.

To use this extension, simply click on the “Activate CORS*” checkbox and browse your target resource, letting the extension do its job. It will attempt to apply various CORS bypass techniques to all requests passing through your Burp proxy. All you have to do is check the results.

After activating the extension, I discovered a possible incorrect CORS setting in the request www.target.com/api/me. This API request is responsible for retrieving users' personally identifiable information (PII) such as first name, last name, email address, and account ID.

When sending a request with a header

Origin: 7odamoo-target.com

the answer was as follows:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: 7odamoo-target.com

Great, looks like I found a vulnerability. In normal cases, I would register the domain 7odamoo-target.com and upload a CORS PoC to it to demonstrate the vulnerability. However, when I checked the cookie flags, I found that the problem was with the flag SameSite. The browser will not include a cookie in the request if the origin is not allowed.

I think you understand what I'm going to do next. I'll use XSS, which is considered out of scope, to send the request and the session ID will be included in the cookie.

So I have implemented the following script on my own subdomain .target.com so that when someone visits my subdomain a request will be sent to www.target.com/api/me and their personal information will be displayed in the alert popup window as a PoC:

function cors() {
  var xhttp = new XMLHttpRequest();
  xhttp.onreadystatechange = function() {
      if (this.readyState == 4 && this.status == 200) {
            document.getElementById("demo").innerHTML = alert(this.responseText);
      }
  };
  xhttp.onload = cors;
  xhttp.open("GET", "https://www.target.com/api/me", true);
  xhttp.withCredentials = true;  xhttp.send();
}
cors();

Bypass SameSite Cookie Flag Using Self XSS

Great, I was able to successfully link a CORS misconfiguration to XSS that is considered out of scope to bypass the origin check for a cookie with the SameSite flag.

The team quickly responded to the vulnerability by eliminating the incorrect CORS configuration. They no longer allow *.target.com to read the response from www.target.com.