minor change
← Older revision
Revision as of 23:21, 14 December 2013
(2 intermediate revisions by one user not shown)
Line 1:
Line 1:
−
{{
Template:OWASP Testing Guide v4
}}
+
== Brief Summary ==
+
+
Web Messaging also known as Cross Document Mesaging allow applications running in different domains to comunicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy enforced by the browser, however developers used multiple hacks in order to accomplish this tasks that were mainly insecure.
+
+
This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced withint he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.
+
+
The Messaging API introduced the <pre>postMessage()</pre> method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:
+
+
data: The content of the incoming message
+
origin: The origin of the sender document.
+
source: source window
+
+
+
Let's see an example:
+
<pre>
+
Send message:
+
+
iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);
+
+
Receive message:
+
+
window.addEventListener(“message”, handler, true);
+
function handler(event)
{
+
if(event.origin === 'chat.example.com')
{
+
/* process message (event.data) */
+
} else {
+
/* ignore messages from untrusted domains */
+
}
+
}
+
</pre>
+
−
== Brief Summary ==
−
<br>
−
..here: we describe in "natural language" what we want to test.
−
<br>
== Description of the Issue ==
== Description of the Issue ==
−
<
br
>
+
−
..
.here
:
Short Description
of the
Issue: Topic
and
Explanation
+
<
b>Origin Security Concept</b
>
−
<
br
>
+
+
The origin is made up of a scheme, hostname and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url
.
+
For instance, https://example
.
com/ will be considered different from http
:
//example.com because the schema in the first case is https and in the second http, same applies to webservers running in the same domain but different port.
+
From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish that is using a whitelist. Also within the sending domain, we also want to make sure they are explicity stating the receiving domain and not '*' as the second argument
of
postMessage() as this practise could introduce security concerns too, and could lead to, in
the
case of a redirection or the origin changes by other means, the website sending data to unknown hosts,
and
therefore, leaking confidential data to malicious servers.
+
+
In the case a developer failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risks so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message listeners, and get the callback function from the
<
pre
>
addEventListener</pre> method to further analysis as domains must be always verified prior data manipulation.
+
+
+
<b>event.data input validation</b>
+
+
Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.
+
+
+
== Black Box testing and example ==
== Black Box testing and example ==
−
'''Testing
for
Topic X vulnerabilities
:
'''
<
br
>
+
−
...<
br
>
+
Vulnerable code example:
−
'''Result Expected
:
'''
<
br
>
+
−
...<
br
><
br
>
+
<pre>
+
Access needed
for
every subdomain (www, chat, forums, ...)
+
+
window.addEventListener(“message”, callback, true);
+
+
function callback(e) {
+
</b>if(e.origin.indexOf(".owasp.org")!=-1) {<b>
+
/* process message (e.data) */
+
}
+
}
+
</pre>
+
+
The intention is to allow subdomains in this form
:
+
+
<
pre
>
+
www
.
owasp
.
org
+
chat
.
owasp.org
+
forums.owasp.org
+
...
+
<
/pre
>
+
+
Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match
+
+
+
Example of lack of origin check, very insecure as will accept input from any domain
:
+
+
<
pre
>
+
window
.
addEventListener(“message”, callback, true);
+
+
function callback(e) {
+
/* process message (e
.
data) */
+
}
+
</pre>
+
+
+
+
Input validation example: XSS
+
+
+
+
<pre>
+
window
.
addEventListener(“message”, callback, true);
+
+
function callback(e) {
+
if(e.origin === "trusted.domain.com") {
+
<
b
>
element.innerHTML= e.data;
<
/b
>
+
}
+
}
+
</pre>
+
+
+
This code will lead to Cross-Site Scripting (XSS) vulnerabiltiies as data is not being trated properly, a more secure approach would be to use the property textContent instead of innetHTML.
+
+
== References ==
== References ==
−
'''
Whitepapers
'''
<br>
+
Whitepapers
<br>
+
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html
<br>
...<br>
...<br>
−
'''
Tools
'''
<br>
+
Tools<br>
...<br>
...<br>