Secure Web Messaging in
HTML5
Krishna Chaitanya T
Microsoft MVP, Internet Explorer

@novogeek



                                   MUGH Developer
                                       Day
                                     29th Jan, 2012
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
A mashup with widgets




               PageFlakes.com
An interactive mashup




                 HousingMaps.com
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
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.
Demo
Same Origin Policy in action!
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
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
Cross-Window Attack!




                                                                awglogin




    window.open("https://attacker.com/", "awglogin");



                          Courtesy: Stanford Web Security Lab
Same-Window attack!

           top.frames[1].location = "http://www.attacker.com/...";
           top.frames[2].location = "http://www.attacker.com/...";
                                    ...




                 Courtesy: Stanford Web Security Lab
Frame Navigation Policies

Permissive



Window



Descendant



Child
Frame
Communication
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;
  }
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
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
     }
 };
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
Demo
 Playing with HTML5 Post Message API

 Bonus (if time permits) – Recursive Mashup Attack!
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
Thank You!


http://novogeek.com | @novogeek


        http://mugh.net

Secure web messaging in HTML5

  • 1.
    Secure Web Messagingin 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 withwidgets 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.
  • 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.
  • 13.
  • 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 MessageAPI  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 MessageAPI 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 withHTML5 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