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.

Transcript

1. Securing web apps
   with modern platform features
   Lukas Weichselbaum
   Staff Information Security Engineer
   Google
   @we1x
   

   View Slide

2. 1. Common web security flaws
   2. Web platform security features
   

   View Slide

3. 1. Common web security flaws
   2. Web platform security features
   

   View Slide

4. View Slide

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
   ...
   

   View Slide

6. Injections
   
   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=<br/>

   View Slide

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, ...
   
   
   
   
   
   
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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%
    

    View Slide

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
    

    View Slide

12. 1. Common web security flaws
    2. Web platform security features
    

    View Slide

13. 1. Injection defenses 2. Isolation mechanisms
    

    View Slide

14. 1. Injection defenses 2. Isolation mechanisms
    

    View Slide

15. Injection defenses:
    Content Security Policy Level 3
    Mitigate XSS by introducing fine-grained controls on
    script execution in your application.
    

    View Slide

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!
    <br/>scripts get executed plugins are loaded<br/>Developers can control which<br/>

    View Slide

17. Enabling CSP
    Response Header
    Two modes
    Enforcement: Content-Security-Policy
    Report Only: Content-Security-Policy-Report-Only
    https://example.com
    

    View Slide

18. View Slide

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.
    

    View Slide

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'
    alert('xss') // XSS injected by attacker - blocked by CSP
    alert('this is fine!')
    
    

    View Slide

21. The Problem of Nonce-Only CSP
    An already trusted script cannot create new scripts without explicitly setting the nonce
    attribute!
    ALL tags need to have the nonce attribute!<br/>✘ Third-party scripts/widgets (You may not control all scripts!)<br/>✘ Potentially large refactoring effort<br/>Content-Security-Policy: script-src 'nonce-random123'<br/>✔ <script nonce="random123"><br/>var s = document.createElement('script')<br/>s.src = "/path/to/script.js";<br/>✘ document.head.appendChild(s);<br/>
    

    View Slide

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

    View Slide

23. STEP 1: Remove CSP blockers
    STEP 2: Add CSP nonces to tags<br/>STEP 3: Enforce nonce-based CSP<br/>1..2..3 Strict CSP<br/>How to deploy a nonce-based CSP?<br/>

    View Slide

24. A strong CSP disables common dangerous patterns
    → HTML must be refactored to not use these
    javascript: URIs: a
    inline event handlers: b
    STEP 1: Remove CSP blockers
    

    View Slide

25. javascript: URIs
    inline event handlers
    HTML refactoring steps:
    a
    b
    document.getElementById('link')<br/>.addEventListener('click', alert('clicked'));<br/>
    STEP 1: Remove CSP blockers
    a
    b
    

    View Slide

26. nonce-only CSPs (without 'strict-dynamic') must also propagate nonces to dynamically created scripts:
    Only tags with a valid nonce attribute will execute!<br/>STEP 2: Add <script> nonces<br/>HTML refactoring: add nonce attribute to script tags<br/><script src="stuff.js"/>
    doSth();
    
    doSth();
    <br/>var s = document.createElement('script');<br/>s.src = 'dynamicallyLoadedScript.js';<br/>document.body.appendChild(s);<br/>
    <br/>var s = document.createElement('script');<br/>s.src = 'dynamicallyLoadedScript.js';<br/>s.setAttribute('nonce', '{{nonce}}');<br/>document.body.appendChild(s);<br/>
    

    View Slide

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
    

    View Slide

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'
    

    View Slide

29. Detailed guide at
    csp.withgoogle.com
    

    View Slide

30. Use the CSP Evaluator
    to check your policy
    csp-evaluator.withgoogle.com
    

    View Slide

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

    View Slide

32. Injection defenses:
    Trusted Types
    Eliminate risky patterns from your JavaScript by
    requiring typed objects in dangerous DOM APIs.
    

    View Slide

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/#
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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;
    

    View Slide

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)
    

    View Slide

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
    →
    

    View Slide

41. Try Trusted Types now!
    bit.ly/trusted-types
    

    View Slide

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'
    

    View Slide

43. 1. Injection defenses 2. Isolation mechanisms
    1. Injection defenses
    

    View Slide

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
    

    View Slide

45. Attacks on windows
    Examples: XS-Search, tabnabbing, login detection, Spectre
    Why do we need isolation?
    Open new window
    evil.example victim.example
    

    View Slide

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/
    

    View Slide

47. Isolation for resources:
    Fetch Metadata request headers
    Let the server make security decisions based on the
    source and context of each HTTP request.
    

    View Slide

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
    

    View Slide

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
    
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

52. Fetch Metadata based
    resource-isolation
    middleware for Python
    github.com/empijei/sec-fetch-resource-isolation
    

    View Slide

53. Isolation for windows:
    Cross-Origin Opener Policy
    Protect your windows from cross-origin tampering.
    

    View Slide

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
    

    View Slide

55. Isolation: Cross-Origin Opener Policy
    evil.example victim.example
    Cross-Origin-Opener-Policy: same-origin
    victim.example
    )
    Cross-Origin-Opener-Policy: same-site
    or
    

    View Slide

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.
    

    View Slide

57. Recap: Web Security, 2019 Edition
    Defend against injections and isolate your
    application from untrusted websites.
    

    View Slide

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

    View Slide

59. Thank you!
    csp.withgoogle.com
    csp-evaluator.withgoogle.com
    bit.ly/trusted-types
    github.com/empijei/sec-fetch-resource-isolation
    Helpful resources
    Lukas Weichselbaum
    Staff Information Security Engineer, Google
    @we1x
    @lweichselbaum
    

    View Slide