1. Secure Web Messaging in
HTML5
Krishna Chaitanya T
Microsoft MVP, Internet Explorer
@novogeek
MUGH Developer
Day
29th Jan, 2012

2. Agenda
Web 2.0 Communicatio HTML5 Security
A quick overview of n How the new Web Solved problems &
new needs of Web 2.0 Messaging API helps new concerns
Traditional data
era
Case study of few Mashups
exchange & drawbacks
Quick overview: Why there is a need for a new Reduced scope for XSS
JavaScript, Ajax, specification for web based Improved trust model
Understanding their Browser Sandbox, SOP, messaging,
technical limitations Frames, Navigation Newer security concerns
policies, Fragment Counter measures
Identifier

3. A mashup with widgets
PageFlakes.com

4. An interactive mashup
HousingMaps.com

5. Embedding Remote JS
 Assumption - script is from trusted source
 No isolation of origins
 Runs in the context of window
“A mashup is a self-inflicted XSS
 Has complete access to DOM attack”
-Douglas Crockford,
 Can read & export your data
Inventor of JSON
 No user involvement needed

6. Same Origin Policy
 Browser has to isolate different origins
 Origin = protocol://host:port
 Ex: http://bing.com, http://localhost:81/, https://icicibank.com
 Privileges within origin
 Full network access
 Read/Write access to DOM
 Storage
 Embedded scripts have privileges of imported page, NOT source server
 AJAX calls to cross domains fail due to SOP.

7. Demo
Same Origin Policy in action!

8. Isolation with Frames
 Different security contexts for different origins
 Brings modularity but less interactive than embedding JS
 No standard communication mechanism
 Comply with SOP - Run remote code safely
<!-- This is allowed -->
<iframe src="sameDomainPage.html"> </iframe>
alert(frames[0].contentDocument.body); //works fine
<!-- This is **NOT** allowed -->
<iframe src="http://crossDomain.com"> </iframe>
alert(frames[0].contentDocument.body); //throws error

9. Frame Navigation
 Beware! Frames can be navigated to different origins!
 Frame-Frame relationships
 Can script in Frame A modify DOM of Frame B?
 Can Script in Frame A “navigate” or change the origin of Frame B?
 Frame navigation is NOT the same as SOP - often mistaken!
<iframe src=“http://crossDomain.com"> </iframe>
<!-- This is **NOT** allowed -->
alert(frames[0].src); //throws error – SOP restriction
<!-- This is allowed -->
alert(frames[0].src=“http://bing.com”); //works fine - frame navigation

10. Cross-Window Attack!
awglogin
window.open("https://attacker.com/", "awglogin");
Courtesy: Stanford Web Security Lab

11. Same-Window attack!
top.frames[1].location = "http://www.attacker.com/...";
top.frames[2].location = "http://www.attacker.com/...";
...
Courtesy: Stanford Web Security Lab

12. Frame Navigation Policies
Permissive
Window
Descendant
Child

13. Frame
Communication

14. Fragment Identifier Messaging
 Work around before HTML5
 Limited data, no acknowledgements.
 Navigation doesn’t reload page
 Not a secure channel.
//Sender.html
function send(){
iframe.src=“http://localhost/receiver.html#data”;
}
//Receiver.html
window.onload=function(){
data=window.location.hash;
}

15. HTML5 Post Message API
 Cross-origin client side communication
 Network-like channel between frames
 Securely abstracts multiple principals
 Frames can now integrate widgets with improved trust

16. HTML5 Post Message API
Syntax: otherwindow.postMessage(message, targetOrigin);
 targetOrigin can be a trusted source or wild card *“*”+
//Posting message to a cross domain partner.
frames[0].postMessage(“Hello Partner!”, "http://localhost:81/");
//Retrieving message from the sender
window.onmessage = function (e) {
if (e.origin == 'http://localhost') {
//sanitize and accept data
}
};

17. Few security considerations
 Do not configure target origin to “*”.
 Sensitive data can be leaked to unknown widgets
 Always check for sender’s origin
 Client side DoS attacks can be launched
 Always validate data before use.
 Do not consume data directly with eval() or innerHTML
 Follow best practices of DOM based XSS prevention
 Eavesdropping with framing attacks!
 In spite of above checks, data can still be lost
 Ex: Recursive Mashup attack
 Follow frame busting techniques

18. Demo
 Playing with HTML5 Post Message API
 Bonus (if time permits) – Recursive Mashup Attack!

19. References & Reading
 “Secure Frame Communication in Browsers”-Adam Barth, Collin
Jackson, John Mitchell-Stanford Web Security Research Lab
 W3C HTML5 Web Messaging Specification -
http://dev.w3.org/html5/postmsg/#authors
 Dive into HTML5 – http://diveintohtml5.info
 IE9 Guide for Developers - http://msdn.microsoft.com/en-
us/ie/hh410106.aspx

20. Thank You!
http://novogeek.com | @novogeek
http://mugh.net