Modern web vulnerabilities: issues and remediations

A web security lesson for a master in computer security.

Transcript

1. Modern web vulnerabilities Issues and remediations
2. The vulnerabilities Old and new issues • XSS • CSRF • XSSI • Tabnabbing • Clickjacking • XS-Leaks • Spectre
3. Cross site scripting (XSS) • It’s been there since JavaScript was invented (1995) • Still one of the major vulnerabilities found today • Injection-based attack • Very hard to prevent as the platform cannot distinguish between data and code • Hard to tackle ◦ Server side reflected XSS ◦ Server side stored XSS ◦ DOM XSS ◦ Mutation based XSS (browsers are complex)
4. Cross site scripting (XSS) Server side (stored): <a href="{{.username}}"> Client side (DOM based): foo.innerHtml = window.location.hash ;
5. Cross site scripting (XSS) user=#"><svg onload=maliciousStuff()> Server side: <a href="{{.username}}"> Client side: foo.innerHtml = window.location.hash;
6. Cross site request forgery (CSRF/XSRF) • Client-Side example form: • What the server sees when user submits: • Cookies • action=buy_product • quantity=1000 • There is no secure notion of origin
7. Cross site request forgery (CSRF/XSRF) • It’s been there since the beginning • It’s clumsy to address • Requires developers to add custom protections on top of the platform • Normally addressed by adding tokens in hidden forms parameters • It is not clear what to protect, so even using frameworks might lead to issues ◦ Example: GET requests are usually not protected by frameworks but developers might decide to have state-changing APIs that use GET parameters, or some libraries might automatically parse GET forms and treat them as POST. If this happens after the anti-xsrf middleware the vulnerability is still there.
8. Cross site script inclusion (XSSI) • Affects sites that rely on dynamically generated JavaScript (e.g. JSONP) • Script inclusion sends victim cookies even cross-site https://evil.com <script type="text/javascript" src="https://victim.com/dynamic-script.js> </script> <script> steal(secret) </script> https://victim.com/dynamic-script.js var secret = { “user”: “Rob”, “token”: “AccessTokenForAPIs”, } ;
9. Tabnabbing • Phishing attack that relies on navigations that the user does not expect • Example: ◦ User clicks on a link on GMail ◦ The link opens a new tab ◦ The originating page (gmail.com) gets redirected to a phishing clone (gmai1.com) asking for credentials ◦ When the user closes the new tab, they will go back to the previous context and expect it to still be gmail ◦ User inputs credentials in gmai1.com
10. Clickjacking • Phishing attack that relies on abusing user trust on what they see • The user issues clicks on a different site than the one they think they are interacting with
11. Clickjacking • The web is built on technologies that allow cross-origin frames by default • All services that do not want this must explicitly opt-out
12. Cross site leaks (XS-Leaks) • Extract bits of information via side channels • The attacking page doesn’t need to see the cross-origin content, just the time it took to load, or the error that happened while trying to load • Same-origin policy does not protect against this kind of attacks E.g. Login detection: loading a frame errors if user is not logged in.
13. XS-Leaks: Cross site search (XSSearch) • A notable example of cross-site leaks • Extract bits of information from the time it takes to load search results • In 2016 this affected GMail and Bing to a point where credit cards could be stolen in less than 45s and the full search history in less than 90s
14. Spectre • Extract bits of information via hardware issues • Many things can be obtained cross-origin and access boundaries are enforced by the browser, but within the same process • Get around Same-Origin policy because the memory is in the same process, and it can be accessed via side-channel • Requires precise timers, but they can be crafted
15. Spectre, an example Run many times with small indexes, then with controlled_index > max_index if (controlled_index < max_index) { secret_value = index_array[controlled_index]; _ = data_array[secret_value*cache_block_size]; } Measure access time to different blocks of data_array The one in secret_value position will be faster to access
16. The new mitigations Changes to the platform to make it secure™ • CSP • Trusted Types • Fetch Metadata • Same-Site cookies • COOP • Site Isolation • CORB and CORP • Intersection Observer
17. Content Security Policy (CSP) • Response header to enforce some strict client-side behaviors • Allows applications to instruct browsers to disable common sinks for XSS attacks • It is a rather complex specification but the latest version (v3) is reasonably easy to use and deploy compared with previous ones • The frame-ancestors sets rule for framing, thus protecting against clickjacking • It is a composed headers with many different directives to toggle browser security features
18. Content Security Policy (CSP) Content-Security-Policy: object-src 'none'; script-src 'nonce-safe-random'; base-uri 'none'; report-uri /csp-report More details: csp.withgoogle.com • Execute: <script src=”safe.com/app.js” nonce=’safe-random’> </script> • Won’t execute <script src=”evil.com/atk”></script> <svg onload=”evil()”/> <base href=https://evil.com>
19. CSP v3 nonce-based + strict-dynamic nonce-only nonce-based + strict-dynamic + unsafe-eval + hashed attributes nonce-based + strict-dynamic + unsafe-eval remaining XSS attack surface adoption effort fewer sinks covered more sinks covered easy hard L1 L2 L3 L4 v75 Incremental CSP Adoption start finish
20. Trusted Types • Piggyback on CSP response header • Addresses most of the DOM XSS that CSP could not address • Makes the DOM API typed (yes, types in JS) • DOM sinks can only be used with appropriate types • Trusted Types can only be constructed via policies • Policies are declared in CSP Content-Security-Policy: trusted-types policy-name
21. Trusted Types
22. Trusted Types
23. Server-Side security + nonce-only CSP + TT • Server-Side injections should be taken care of by the server. Only trusted scripts are nonced • Client side code is easier to secure Moreover • If the server has an injection ◦ The attacker has to leak the nonce without JS execution. This is usually very hard. ◦ The attacker has to find a working sink. Since javascript URIs and event handlers are blocked this is hard and sometimes impossible. • If the client has a bug ◦ Client-side sinks are controlled
24. Fetch Metadata • 4 Sec-Fetch-* request headers ◦ Dest (audio, document, embed, script, serviceworker…) ◦ Mode (cors, navigate, no-cors, same-origin, websocket...) ◦ Site (cross-site, same-origin, same-site) ◦ User (true, false) • Inform the server on what caused the request and how it will be used • Servers can now make informed decisions whether to provide the requested resource
25. Fetch Metadata • CSRF ◦ Sec-Fetch-Site: ‘cross-site’ ◦ HTTP Method: “POST” • XSSI ◦ Sec-Fetch-Site: ‘cross-site’ ◦ Sec-Fetch-Dest: ‘script’ • Timing Attacks ◦ Sec-Fetch-Site: ‘cross-site’ ◦ Sec-Fetch-Mode ≠ ‘navigate’ • Most classes of vulnerabilities (including tabnabbing, XS-Leaks and Spectre) ◦ Sec-Fetch-Site: ‘cross-site’
26. Same Site Cookies • Simple server-side CSRF mitigation mechanism Set-Cookie: <name>=<value>; SameSite=(Lax|Strict); [other directives] • Lax allows cross-site navigation • Strict will prevent cookies from being sent in any cross-site action
27. Cross Origin Opener Policy • Server side header to instruct the browser to not perform some cross-site operations • Dictates top-level cross-origin behavior • Still undergoing design and implementation Cross-Origin-Opener-Policy: (same-origin|same-site) [unsafe-allow-outgoing]
28. Chrome site isolation • User-Agent level mitigation, no code change required • If something is cross-origin it is displayed in different render processes, including frames. This partially addresses spectre • Relies on the OS-level process isolation to protect against hardware issues
29. Cross origin read blocking (CORB) • User-Agent level mitigation. Completes SI to protect against Spectre • The browser tries to guess when a cross-origin resource is being maliciously loaded and blocks it • Currently protected by default MIME types: ◦ JSON ◦ HTML ◦ XML • Mimes are sniffed in a smart way to detect mislabeled responses • CORB can be opted-in by servers for all resources with Cross Origin Resource Policy (CORP): Cross-Origin-Resource-Policy: (same-origin|same-site)
30. Intersection Observer v2 • Security-Aware JS API that tracks visibility • Requires client side code change • The first clickjacking protection that still allows framing • The observer knows if it is visible and for how long it’s been visible Potentially evil Observer
31. Questions and discussion Let’s fix it together
32. Protection mechanism Changes required Vulnerabilities Adoption Complexity CSP + Trusted Types Server, Client XSS, Clickjacking Hard Fetch Metadata Server Reflected XSS, CSRF, XSSI, ClickJacking, XS-Leaks, Spectre Medium Same-Site cookies Server CSRF Easy COOP Server Reflected XSS, Tabnabbing, XS-Leaks, Spectre Easy Site Isolation + CORB None XS-Leaks, Spectre None CORP Server XS-Leaks, Spectre Easy Intersection Obs. v2 Client Clickjacking Medium Recap table