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

How to use postMessage to make use of DOM-based XSS loopholes in Facebook, many novices are not very clear about this. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

Overview

The first vulnerability we discovered would allow a malicious attacker to send cross-domain messages from the facebook.com domain name over postMessage. The vulnerable end node will receive user-controlled content in the request parameters and use the send message in postMessage to build a data object that will be sent to the open window along with postMessage. Next, the second vulnerability we discovered relates to the first vulnerability, which an attacker can use to construct an insecure script based on the form submission data received by Eventlistener.

Send a message via postMessage from the facebook.com source

The node with the vulnerability is https://www.facebook.com/payments/redirect.php, whose response information can be controlled by various parameters. One of the interesting parameters we found is "type". If this parameter is changed from "I" to "rp", it will use postMessage to communicate with the window that opens the page (if it is "I", then it will use the window.parent.paymentsFlows.processIFrame method).

It should be noted that the target source needs to be set to our.intern.facebook.com. Now, we know that the postMessage method is only available to Facebook employees, because they are the only ones with full access to the our.intern.facebook.com domain name, and if they are not Facebook employees, they will be redirected to www.facebook.com.

Here, I try to bypass this restriction by accessing the same node alpha.facebook.com in another domain. If you are accessing our.alpha.facebook.com/payments/redirect.php, it will return to our.alpha.facebook.com, because this is the address set by targetOrigin in postMessage. Unlike our.intern, our.alpha does not redirect to www. Note here that the our.alpha.facebook.com domain name contains the same content as www.facebook.com. In this way, our message can be delivered to the open window, because the targetOrigin condition has been met and the message will be sent to our.alpha.facebook.com.

Now we know that we are looking for a page that contains EventListeners, and it only receives messages whose source is accept facebook.com.

Discovery and Utilization of XSS vulnerabilities

The Facebook Canvas application is hosted on apps.facebook.com, and if you visit the application hosted by this domain name, you will find that Facebook will load a URL in iframe and send a new POST message with a similar "signed_request" parameter to this URL address.

By tracking the source of the request, I found that this page also loaded https://www.facebook.com/platform/page_proxy/? from iframe. Version=X, and then send a message to it using postMessage.

The page_proxy page contains the following code:

The above code accomplishes two main things. First, it uses postMessage to send messages with frameName to any source. Second, it will set up an EventListener and wait for the message to be received. If you receive a message that meets all the criteria, it will submit an form form after setting its properties based on the data in the message.

What's interesting about the form constructor submitForm () is that the action property in this form is directly set to "a.data.params.appTabUrl", which is received by message. The URL in the "appTabUrl" string in URL does not check if it starts with http/https, so we can use JavaScript to exploit the XSS vulnerability.

Next, we need to construct a Payload object in the page_proxy script that meets all the conditions, as shown below:

Https://our.alpha.facebook.com/payments/redirect.php?type=rp&name=_self&params[appTabUrl]=_javascript:alert(1);&params[signedRequest]=SIGNED_X&platformAppControllerGetFrameParamsResponse=1OBJ: {"type": "rp", "name": "_ self", "params": {"appTabUrl": "_ javascript:alert (1);", "signedRequest": "SIGNED_X"}, "platformAppControllerGetFrameParamsResponse": "1"} vulnerability exploitation

The target user needs to visit a malicious website hosted by the attacker, and the page of the site needs to contain the following code:

Start Attack

Here, we are not going to redirect directly to the page_proxy node, because we need to set a delay to ensure that the https://www.facebook.com/platform/page_proxy/ loads successfully.

Page2.html:setTimeout (function () {_ window.location.href = 'https://our.alpha.facebook.com/payments/redirect.php?type=rp&merchant_group=86&name=_self&params[appTabUrl]=_javascript:alert(1);&params[signedRequest]=SIGNED_X&platformAppControllerGetFrameParamsResponse=1';}, 3000)

Here I set a three-second delay, then redirect to the vulnerable page and execute alert (1), while the PoC I set will steal the user's access token, which will directly allow us to take over the target Facebook account.

Vulnerability repair

Faceboos has so far successfully fixed this vulnerability by directly removing the postMessage component from payment redirection (/ payments/redirect.php) and adding http/https detection to appTabUrl.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.