Security Analysis of HTML5 cross-origin message sending

Security Analysis of HTML5 cross-origin message sending

HTML5 is the next-generation Web application. It has many new features and is a new technology that is widely used in mobile applications. But it is precisely because of the emergence of some of its new features and a wide range of applications that make its security very worthy of attention.

In this article, we will analyze and study the security of HTML5 Web message sending (cross-origin message sending.

Cross-origin message sending
 

Before discussing this issue, let's take a look at how to implement cross-origin message sending in HTML5.

Before HTML5, the same protocol, port, and host must be used for message transmission between two windows due to the restriction of the same source policy.

HTML5 has a new method called postMessage (). Through this method, cross-origin message transmission is no longer restricted by the same-origin policy.

The following is the syntax of postMessage:

Sending window:

Otherwindows: other Windows involved Message: the Message sent to the receiving window targetOrigin: the URL required for the receiving window. If you do not have any special preference, you can define it as "*" and define "*" as targetOrigin. However, there are some security risks in doing so, which will be mentioned later. Transfer: This is arbitrary.

 

Receiving Window:

When otherWindow. postMessage () is executed, the message is sent to the receiving window.

After using the following code, the sender can receive the message.

With this code, we can access the data and the source of this information. As follows:

Event. origin: provide the source of the information (the URL of the information we receive) Event. data: provide the actual content of the information sent

Security instance analysis
 

For demonstration purposes, I set up the following two labs:

A: http://localhost:8383/B: http://localhost/

 

As you can see, the above two URLs have different ports. The first is running on port 8383, and the second is running on port 80. It is because the source is different that the port is different.

 

A is the sending window, B is the Receiving Window

Now we load the second URL (http: // localhost/) as the iframe of the first url:

By using postMessage (), I can easily send messages from the first URL to the second URL.

You can click "send message" to verify the message.

Although the iframe In the first URL is not the same as it, the information can be transmitted through postMessage.

Now let's take a look at some examples of vulnerabilities that can cause applications when using postMessage:

Case1.

Sender code:

 

VcmlnaW5hbD0 = "http://www.bkjia.com/uploads/allimg/150313/0435531U7-4.png! Small "src =" http://www.bkjia.com/uploads/allimg/150313/0435531U7-4.png "title =" image 5.png "/>

 

When the sender specifies the targetOrigin as the wildcard "*", unknown information will be received by a strange receiver (window. The reason is that anyone can load an iframe for listening to messages sent from the receiving window. Therefore, it is a very wrong decision to use wildcards when transmitting sensitive data.

The best solution to this problem is to add a specific target field during sending, as shown below:

 
 

Case2.

Receiving Window code:

 
 

In the above code, we can see that we directly receive the message from the sender and process it without verifying whether it comes from the sender.

However, checking the message source is undoubtedly very important, which can prevent messages from unauthorized senders.

Therefore, we only need to add verification to the sender in the Code. This problem can be solved. The Code is as follows:

 

Verify by verifying event. origin.

Case3.

In this process, both the sender and receiver should verify the. message being sent. If the data is not verified when inserted into the html dom, the application may suffer DOM-based cross-site scripting attacks.

The following code shows that when the application receives malicious information from attackers and has been inserted into the html dom to use the innerHTML attribute, It is very vulnerable.

Sender:
 

Receiver:
 

Executing the above Code may cause XSS to appear in the receiving window.

 

The simplest way to solve this problem is to use textContent instead of innerHTML when assigning data values to elements.

As follows:

Sender:

 
 

Receiver:

When executing the above code, we can see that the frame is used as data rather than code in the text.

As we can see, it does not execute code, but shows normal text.