JavaScript Security

Mastering Cross Domain Communications in JS applications

Transcript

1. Berlin, 2018-01-01 JavaScript Security Mastering Cross Domain Communications in JS applications Smashing Conference, New York City, 2018-10-22 <thomas.witt@infopark.com> @thomas_witt linkedin.com/in/thomaswitt Thomas Witt Co-Founder
2. @thomas_witt
6. The Problem
7. JS Applications need to exchange data with Backend APIs running on domains other than your own SECURELY
8. Challenge Only load code from trusted origins, don't execute malicious JS code, don't let people steal your data.
9. Same Origin Policy For security reasons, browsers restrict cross- origin HTTP requests initiated from within scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request HTTP resources from the same origin the application was loaded from. – https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS “
10. How to … Exchange data from JS applications with backend APIs
11. Two ways how to talk to other services CORS postMessage
12. #1: CORS Cross-Origin Resource Sharing
13. Same Origin Policy A web application using those APIs can only request HTTP resources from the same origin the application was loaded from, unless the response from the other origin includes the right CORS headers. – https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS “
14. The easy one: Simple Requests
15. Simple GET request via CORS var req = new XMLHttpRequest(); var url = 'http://bar.other/resources/public-data/'; function callOtherDomain() { if(req) { req.open('GET', url, true); req.onreadystatechange = handler; req.send(); } } GET /resources/public-data/ HTTP/1.1 Origin: http://foo.example HTTP/1.1 200 OK Access-Control-Allow-Origin: * Client (foo.example) Server (bar.other)
16. The uglyness: Preflight Requests aka not-so-simple-requests
17. Preflighted POST request via CORS - Overview Client (foo.example) Server (bar.other) OPTIONS /resources/post-here/ HTTP/1.1 Origin: http://foo.example Access-Control-Request-Method: POST Access-Control-Request-Headers: Content-Type HTTP/1.1 200 OK Access-Control-Allow-Origin: http://foo.example Access-Control-Allow-Methods: POST, GET Access-Control-Allow-Headers: Content-Type Access-Control-Max-Age: 86400 var invocation = new XMLHttpRequest(); var url = 'http://bar.other/resources/post-here/'; var body = '<?xml version="1.0"?><person><name>Thomas Witt</name></person>'; function callOtherDomain(){ if(invocation) { invocation.open('POST', url, true); invocation.setRequestHeader('Content-Type', 'application/xml'); invocation.onreadystatechange = handler; invocation.send(body); } } POST /resources/post-here/ HTTP/1.1 Content-Type: text/xml; charset=UTF-8 Origin: http://foo.example HTTP/1.1 200 OK Access-Control-Allow-Origin: http://foo.example Preflight Phase Main Request Phase
18. For every new resource accessed,
 a preflight request will be issued.
20. CORS Security Introducing CSP
21. CORS vs CSP CORS CORS allows a server (bar.other) to give permission to a site (foo.example) to read (potentially private) data from a server (bar.other), using the visitor's browser and credentials. CSP CSP allows a site (foo.example) to prevent itself from loading (potentially malicious) content from unexpected sources (e.g. against XSS). GET /resources/public-data/ HTTP/1.1 Origin: http://foo.example HTTP/1.1 200 OK Access-Control-Allow-Origin: * Content-Security-Policy: base-uri 'none'; default-src 'self' 'unsafe- inline' data: https: wss:; object- src 'none'; script-src 'self' https://beta-api.scrivito.com; upgrade-insecure-requests;
22. 0,133% of all 1M Alexa sites implement a CSP June 2015, "CSP adoption: current status and future prospects", Ming Ying / Shu Qin Li
23. Example Response: www.scrivito.com (shortened) HTTP/1.1 200 OK Connection: keep-alive Content-Encoding: gzip Content-Security-Policy: base-uri 'none'; default-src 'self' data: https: wss:; object-src 'none'; script-src 'self' https://assets.scrivito.com https://api.scrivito.com https://maps.googleapis.com https://www.google-analytics.com; upgrade-insecure-requests; Content-Type: text/html; charset=UTF-8 Date: Wed, 18 Aug 2018 19:00:00 GMT
24. Implementation A closer look
25. CSP Directives https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src <script> <img> <link rel="stylesheet"> <style> <audio> <video> <iframe> @font-face WebSocket, XMLHttpRequest, EventSource <embed> <object>
26. script-src Values https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src self unsafe-inline unsafe-eval * none my.url.com <script src="/public/mylib.js" /> <script> alert('Hello JavaScript!'); </script> setTimeout(); eval(); All of it None of it Space-separated (*.js.com | api.js.com | https: | https://api.js.com | data:)
27. A typical CSP Content-Security-Policy: base-uri 'none'; default-src 'self' https: wss:; script-src 'self' https://api.scrivito.com https://assets.scrivito.com https://www.google-analytics.com https://maps.googleapis.com https://whatever.service.you.need.com; object-src 'none'; upgrade-insecure-requests;
28. CSP Key Takeaways
29. Every JavaScript application
 should have a CSP.
30. It will most likely break your site At the first try
31. script-src is most important
32. Always set default-src
33. Test it!
34. #2: postMessage via iFrame
35. Cross-domain communication via window.postMessage <iframe name="receiver" src="https://bar.other/my.js"> <script> let win = window.frames.receiver; win.postMessage("message", "https://bar.other"); </script> window.addEventListener("message", function(event) { if (event.origin != 'https://foo.example') { // Unknown domain? Ignore! return; } alert( "Rcvd: " + event.data ); }); Sender (foo.example) Receiver (bar.other)
36. That's it
37. window.postMessage vs CORS/CSP Advantages CORS is not very simple, postMessage is No pre-flight requests No need to modify HTTP headers Not convinced? Google uses it as well in its Google API JS SDK <iframe name="receiver" src="https://bar.other/my.js"> <script> let win = window.frames.receiver; win.postMessage("message", "https://bar.other"); </script> window.addEventListener("message", function(event) { if (event.origin != 'https://foo.example') { // Unknown domain? Ignore! return; } alert( "Rcvd: " + event.data ); });
38. window.postMessage Security Security caveats No side can figure out whether malicious code has been inserted via XSS! Check-List Does the browser support postMessage? Is the message origin correct and known? Is the message data sanitized and validated? Are origins matched using strict equality
 (no indexOf(".foo.com") > 0)? Are messages sent without using wildcards in the origin? <iframe name="receiver" src="https://bar.other/my.js"> <script> let win = window.frames.receiver; win.postMessage("message", "https://bar.other"); </script> window.addEventListener("message", function(event) { if (event.origin != 'https://foo.example') { // Unknown domain? Ignore! return; } alert( "Rcvd: " + event.data ); });
39. Bonus Tip: github.com/jpillora/xdomain
40. Xdomain A pure JavaScript CORS alternative. No server configuration required - just add a proxy.html on the domain you wish to communicate with. – https://github.com/jpillora/xdomain “
41. Summary
42. Always have a CSP!
43. Use postMessage instead of CORS when implementing Cross Domain Communication.
44. Your questions?