1 / 19

The Postman Always Rings Twice: Attacking & Defending postMessage in HTML5 Websites

The Postman Always Rings Twice: Attacking & Defending postMessage in HTML5 Websites. Ankur Verma University of Central Florida, Orlando. Prior/After HTML5. Same Origin Policy communication Cross Site Communication. Protocol + Host + Port. postMessage. New Web Approach.

trung
Download Presentation

The Postman Always Rings Twice: Attacking & Defending postMessage in HTML5 Websites

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Postman Always Rings Twice:Attacking & Defending postMessage in HTML5 Websites Ankur Verma University of Central Florida, Orlando

  2. Prior/After HTML5 Same Origin Policy communication Cross Site Communication Protocol + Host + Port postMessage

  3. New Web Approach • postMessage enhance user experience

  4. postMessage: Inter-frame Communication Different Frames

  5. What Worries? Changing Web Landscape: Inclination on Client Side Greater Functionality JavaScript Application Logic Fast Query Response Extended Functionality

  6. Usage Message Target Origin Usage: targetWindow.postMessage(<Traffic Data Request>, <Google Analytics>) Third Party

  7. Security Perspective • postMessage guarantees confidentialityandauthenticity • Sender specifies recipient’s origin, specifying URL(Target Origin) • Recipient origin can also be ‘*’ Developer’s responsibility. To be used Cautiously! 68% websites vulnerable to XSS

  8. Cause of Concern • 25% of top 10,000 websites use postMessage: Alexa • Over 70% of websites do not perform origin check. • Nearly 12% perform semantically incorrect checks

  9. Sample Demonstration (I) • Origin Check: Failing which enables XSS attacks. Window.addEventListner(“ message”, GetMsg, false); function GetMsg(event) { if (event.origin == “ http://www.abc.com") return; event.source.postMessage(“Hi ABC”, event.origin); } http://www.xyz.com VarnewWin=window.open (http://www.xyz.com); newWin.postMessage(“Hi”, http://www.xyz.com); http://www.abc.com Origin Check targetOrigin

  10. Sample Demonstration (II) • Semantically Incorrect Checks Window.addEventListner(“ message”, GetMsg, false); function GetMsg(event) { Var w=/abc\.com(:[0-9])?$/; if (!event.origin.match(w)) return; event.source.postMessage(“Hi ABC”, event.origin); } http://www.xyz.com VarnewWin=window.open (http://www.xyz.com); newWin.postMessage(“Hi”, http://www.xyz.com); http://www.abc.com Origin Check targetOrigin Evilabc.com

  11. Defense from Attacker Website • For third party content providers like Facebook • Based on Pseudo Random Token • Frame with 3rd party content accepts messages only from the origin of the page that loads this frame. Or (More Restrictive) • Frame with third party content accepts messages only from the parent frame. • XSS can’t be prevented, if attacker includes 3rd party frame X.com Y.com X.com attacker.com X.com

  12. Defenses • Attacker including 3rd party frame. • Frame with 3rd party content accepts messages only from content provider’s scripts running in any origin. Example: www.facebook.com https://developers.facebook.com/docs/plugins/like-button/ www.attacker.com www.facebook.com Receivers

  13. Defense from Third Party Content • For website that use untrusted third party content • Based on Content Security Policy (CSP) extension • Restricts origin of messages sent to X.com from attacker.com. • Requires browser support, no cooperation From third party content provider. X.com attacker.com

  14. Using postMessage: Simple Example Data Origin Check Sender Origin Check TargetOrigin

  15. “Light” Threat Model Child C sends message to B via A Third Party Frames Attacker Honest

  16. “Heavy” Threat Model Attacker directly included third party frame attacker.com Attacker can put any script or data in local storage novice.com novice.com Provided Script Can cause session hijacking if website stores user’s identity Can cause also steal stored cookies

  17. X-Frame-Options Header • Allows/ disallows rendering of the document when inside an iframe. • It may have three possible values: • SAMEORIGIN: The document will be rendered in an frame only if the frame and it’s parent have the same origin. • DENY: Document may not be rendered inside a frame. • ALLOW-FROM: Document can be frame in specific uri • Needs to be added to web server’s config file. • 3% of websites posing serious threat, do not use this feature

  18. Defense Techniques Pseudo Random Token • Protect against “Light” threat model • Guarantees only the origin that loaded a third-party frame can send messages to this frame. Shared secret pseudo random token between site owner and inner frame • Web-Kit browsers, provide crypto.getRandomNumber API • http://random.org via an XMLHttpRequest • Outer script attaches token to srcattribute of frame it create Content Security Policy • Enforce security policy on 3rd party scripts. Require structural changes, by removing inline JavaScript • CSP is HTTP header starting with X-Content-Security-Policy • Only 3 out of Alexa top 10,000 websites use this

  19. Questions ?

More Related