Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Secure web messaging in HTML5


Published on

Published in: Technology
  • Be the first to like this

Secure web messaging in HTML5

  1. 1. Secure Web Messaging inHTML5Krishna Chaitanya TMicrosoft MVP, Internet Explorer@novogeek MUGH Developer Day 29th Jan, 2012
  2. 2. AgendaWeb 2.0 Communicatio HTML5 SecurityA quick overview of n How the new Web Solved problems &new needs of Web 2.0 Messaging API helps new concerns Traditional dataeraCase 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 modelUnderstanding their Browser Sandbox, SOP, messaging,technical limitations Frames, Navigation Newer security concerns policies, Fragment Counter measures Identifier
  3. 3. A mashup with widgets
  4. 4. An interactive mashup
  5. 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. 6. Same Origin Policy Browser has to isolate different origins Origin = protocol://host:port  Ex:, http://localhost:81/, 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. 7. DemoSame Origin Policy in action!
  8. 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=""> </iframe> alert(frames[0].contentDocument.body); //throws error
  9. 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=“"> </iframe> <!-- This is **NOT** allowed --> alert(frames[0].src); //throws error – SOP restriction <!-- This is allowed --> alert(frames[0].src=“”); //works fine - frame navigation
  10. 10. Cross-Window Attack! awglogin"", "awglogin"); Courtesy: Stanford Web Security Lab
  11. 11. Same-Window attack! top.frames[1].location = ""; top.frames[2].location = ""; ... Courtesy: Stanford Web Security Lab
  12. 12. Frame Navigation PoliciesPermissiveWindowDescendantChild
  13. 13. FrameCommunication
  14. 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. 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. 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. 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. 18. Demo Playing with HTML5 Post Message API Bonus (if time permits) – Recursive Mashup Attack!
  19. 19. References & Reading “Secure Frame Communication in Browsers”-Adam Barth, Collin Jackson, John Mitchell-Stanford Web Security Research Lab W3C HTML5 Web Messaging Specification - Dive into HTML5 – IE9 Guide for Developers - us/ie/hh410106.aspx
  20. 20. Thank You! | @novogeek