HTML5 security - Cross domain messaging

HTML5 is a technology for the next generation web applications and has come with a lot of new features to the web. In the mobile app world HTML5 applications are widely used. Besides a lot of features, HTML5 has brought to the table various attack vectors. Before talking about security concepts of cross domaing messaging, we need to understand the basics of the HTML implementation of cross domaing messaging.

Cross domain messaging

Because of the same origin policy restrictions before HTML5, sending messages between Windows was only possible if both Windows used the same protocol, port, and host. With the introduction of HTML5, all those restrictions are gone and we can now pass messages across domains without having to worry about Same Origin Policy restrictions. HTML5 has a new method called postMessage(). Using this, we can pass messages between windows regardless of their origin. Below is the syntax of postMessage().

Sending window

otherWindow.postMessage(message, targetOrigin, [transfer]); ‘otherWindow’ is a reference to another window. ‘Message’ is the message to be passed to the receiving window. ‘targetOrigin’ refers tothe URL of the receiving window. If we don’t have any specific preference, we can specify it as “*”. Specifying “*” as ‘targetOrigin’ has some security implications we will discuss in later sections of this article. ‘Transfer’ is optional.

Receiving window

When otherWindow.postMessage() is executed, a messageEvent will be dispatched at the receiver window. We can receive the message dispatched by the sender using the following code snippet. window.addEventListener("message",receiveMessage, false); function receiveMessage(event){ if (event.origin !== "https://goo.gl/Brmfny") return; // ... } From the above code snippet, we can access the data and origin of this message as shown below. ‘event.origin’ gives the origin of the message (the URI from which we are receiving this message). ‘event.data’ gives the actual message being sent. Now, we have got some basic knowledge of what cross domain messaging in HTML5 is and how it is implemented in the applications. Let us now see the security implications of cross domain messaging. For demonstration purposes, we have set up the following lab. A: https://goo.gl/SN1Ow B: https://goo.gl/MTtd As we can see, we have two different ports on the above two URLs. The first URL is running on port 8387 and the second URL is on the default port 80. So, it is obvious that they have two different origins, since the port numbers are different. In our lab setup, A is the message sender and B is the receiving window. We are going to load the second URL https://goo.gl/MTtd as an iframe in the first URL. I can send messages from the domain https://goo.gl/SN1Ow to the domain https://goo.gl/MTtd using the postMessage method. We can check it by clicking the “Send Message” button as shown below. The iframe which is loaded into the first URL is from a different origin, but we are able to send a message to it using HTML5’s postMessage() method. Now, let us look at some scenarios where this postMessage() implementation can introduce vulnerabilities into our applications.

Case one

Code at sender:

receiver.postMessage('Hi There..!', '*');< When the sender has the above code where he specifies the target origin with a wildcard “*”, an unintended recipient (window) can receive this message from the sender. Since the receiving window is listening for incoming messages, anyone can load it into an iframe and can listen for the messages coming to it. So, it is a bad idea to give a wildcard when passing sensitive data to the receiving windows.

How to fix this:

It is possible to fix this just by adding the specific target in the target field. So, in this case https://goo.gl/MTtd is the only origin that can receive this message. This is as shown below. receiver.postMessage('Hi There..!', ' two

Code at receiving window:

function receiveMessage(e) { do something..! } In the above code, we are receiving the message from the sender and directly processing it without checking who sent this message. It is always important to check the origin of the message to prevent receiving messages from unauthorised senders.

How to fix this:

function receiveMessage(e) { if (e.origin !== "") return; do something..! } Always validate the origin from which you want to receive the messages. In our case, we want to receive messages only from . So, we are making a simple check to see if the message is coming from using the property event.origin. If this is not matching, we won’t receive the message.

Case three

The next attack vector is the infamous cross site scripting. Both the sender as well as receiver should always validate the messages being passed. If the data is inserted into HTML DOM without proper validation, then the application becomes vulnerable to DOM based cross site scripting. The following code snippet shows how an application may become vulnerable when a malicious message is received from the attacker and it is inserted into the receiver’s HTML DOM using innerHTML property.

Sender

receiver.postMessage("< img src='x' onerror=alert(1); >", ' receiveMessage(e) { if (e.origin !== "") return; messageEle.innerHTML = "Message from localhost:8387: " + e.data; } When the above code is executed, it causes an XSS in the receiving window as shown in the figure below.

How to fix this:

The easiest way to fix this issue is to assign the data value to an element using textContent rather than using innerHTML. This is done as shown below.

Sender:

receiver.postMessage("< img src='x' onerror=alert(1); >", ' receiveMessage(e) { if ( e.origin !== "") return; element.textContent = " Message from localhost:8387: " + e.data; } When the above code is executed, we should see the text displayed in the receiving frame as “data” rather than code.