In-depth analysis of cross-domain vulnerability chain： from postMessage to the precise attack path of CSRF

In short

In an engaging journey of vulnerability mining, several months ago, I discovered a series of clever links with security flaws in a bug bounty project. This vulnerability chain integrates various technical elements, including but not limited to improper use of postMessage, coarse protection of JSONP endpoints, bypassing of Web Application Firewall (WAF), application of DOM-based cross-site scripting (XSS) on non-target subdomains, loose CORS configuration strategies, and ultimately leading to the core target: implementing cross-site request forgery (CSRF) attacks on protected assets. In accordance with the principle of confidentiality, this article omits identifying information, focusing on the exciting technical details and story.

Searching for elusive CSRF

My target's bug bounty program scope is limited to www.rxxxxd.com and several other subdomains under rxxxxd.com. At that time, my idea of finding vulnerabilities there had run out. However, there was still a possibility of an exploitable cross-site request forgery (CSRF)...

I noticed that some subdomains, such as inscope.rxxxxd.com, can perform sensitive operations (such as updating the personal profile of authenticated users) by sending POST requests to endpoints rooted at https://www.rxxxxd.com/api. The authentication of these requests depends on environmental permissions, specifically reflected in a cookie named sid, marked as SameSite=None and Secure.

Unfortunately, those endpoints require a CSRF defense token (bound to the session of authenticated users) as the query parameter csrftoken exists. Client code running in the context of https://inscope.rxxxxd.com will obtain this CSRF token through an authenticated GET request to https://www.rxxxxd.com/profile, which is appropriately configured with CORS.

In addition, I have not found a direct method to steal the CSRF token of the victim. During my quest for CSRF, it seems that I have encountered an insurmountable wall.

Loose CORS policy allows me to go beyond the scope

When my progress on the target is like this, I usually start exploring out-of-scope assets, hoping to find and abuse the trust relationships between them and certain in-scope assets. After further testing the https://www.rxxxxd.com/profile endpoint, I realized that its CORS configuration not only allows sources from https://in-scope.rxxxxd.com but also allows any web source composed of any subdomain of rxxxxd.com:

Therefore, if I can find a cross-site scripting (XSS) instance on any subdomain of rxxxxd.com (even an out-of-scope one), I can steal the victim's anti-CSRF token and then launch a CSRF attack on the https://www.rxxxxd.com/api endpoint. With this plan in mind, I began to carefully review the out-of-scope subdomains of rxxxxd.com.

Insecure message event listener on an out-of-scope subdomain

With the help of the postMessage-tracker Chrome extension tool, I locked on to https://out-xx-sxxe.rxxxxd.com/search, which has an eye-catching listener on the 'message' event:

The event listener clearly lacks source checking, meaning that any malicious page (deployed anywhere on the Web) that holds the interface https://out-xx-sxxe.rxxxxd.com/search and references it can send malicious web messages to the interface, which will be accepted and processed unconditionally. The impact depends entirely on the logic of the listener. A simple static analysis of the code reveals that the message event listener performs the following operations:

1. Parse the data attribute of the event as JSON and store the result in an object named t.
2. Split the method attribute on the periods.
3. Iteratively access the nested properties of the window.APP object (declared elsewhere on the client) using the result from step 2.
4. Invoke the function obtained from this, and pass an attribute named arg of the t object (see step 1) as a parameter.

Then, my malicious page can send a request to https://out-xx-sxxe.rxxxxd.com/search