Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Securing Browser-based Applications using the BFF Pattern

Duende Software
September 21, 2021

Securing Browser-based Applications using the BFF Pattern

BASTA 2021

Duende Software

September 21, 2021
Tweet

More Decks by Duende Software

Other Decks in Programming

Transcript

  1. Securing Browser-based Applications
    using the BFF Pattern
    Dominick Baier
    @leastprivilege
    https://duendesoftware.com

    View Slide

  2. 2
    @duendeidentity
    Me
    • 15+ years consulting and project work in the identity space
    – co-creator of IdentityServer & IdentityModel OSS Project
    – certified OpenID Connect & OAuth 2.0 Engine for ASP.NET Core
    • Co-Founder of Duende Software
    – the new home of IdentityServer
    – https://duendesoftware.com
    email [email protected]
    blog https://blog.duendesoftware.com
    twitter @leastprivilege
    slides https://speakerdeck.com/duendesoftware

    View Slide

  3. 3
    @duendeidentity
    Agenda
    • Some history
    – the cookie era
    – the token era
    – problems
    • Getting the best of both worlds
    – Backend for Frontend Pattern
    – TMI BFF vs "full BFF"

    View Slide

  4. 4
    @duendeidentity
    Setting the scene

    View Slide

  5. 5
    @duendeidentity
    "Modern" Business Applications
    Browser-based
    Application
    call APIs
    authentication,
    SSO, federation,
    access tokens
    OAuth 2
    OpenID Connect

    View Slide

  6. 6
    @duendeidentity
    History 1 – The Cookie Era
    • Most applications started as "classic web apps"
    – "spiced up" with JavaScript over time
    • Cookies have been used in the first place for authentication sessions
    – "just worked" for doing Ajax calls as well
    • Cross Site Request Forgery (CSRF) was discovered

    View Slide

  7. 7
    @duendeidentity
    Server-side Application
    Threat: cross-site request forgery (CSRF)
    Browser
    Tab/Process Tab/Process
    login &
    set authentication cookie
    http://app.com http://app.com/delete/5
    send authentication cookie

    View Slide

  8. 8
    @duendeidentity
    CSRF mitigation with anti-forgery tokens
    • Add explicit “credential” on every request
    Server-side Application
    render page &
    anti-forgery cookie



    post-back:
    cookie + hidden field
    Page
    web api call:
    cookie + header
    [ValidateAntiforgeryToken]

    View Slide

  9. 9
    @duendeidentity
    History 2 – The Token Era
    • With OAuth 2 the IETF tried to solve the cookie problem
    – encourage the use of token-based API calls in the browser
    – explicitly send tokens as opposed to automatic cookie transmission
    – OAuth 2 implicit flow to overcome same-origin restrictions
    • Lots of security compromises
    – token transport over URLs
    – token storage in the browser
    • Threat: Cross Site Scripting

    View Slide

  10. 10
    @duendeidentity
    OAuth 2 Approach (Implicit Flow)
    HTML, JS, CSS
    APIs
    use access token
    store & manage
    token
    /cb#acess_token=…
    request token
    1
    2
    3
    4

    View Slide

  11. 11
    @duendeidentity
    Challenge: Token Transmission
    • Token transmission over URL is leaky
    – log files
    – browser history
    – referrer headers
    – implementation errors
    – proxies
    • No solution for token injection
    • Deprecated in OAuth 2.1
    – in favour of OAuth 2 Authorization Code Flow

    View Slide

  12. 12
    @duendeidentity
    Authorization Code Flow
    Front-Channel
    • browser redirect
    • user interaction
    • retrieve authorization code
    Back-channel
    • retrieve token
    2
    1
    Authorization
    Server
    HTML, JS, CSS
    store & manage
    token
    3

    View Slide

  13. 13
    @duendeidentity
    Challenge: Token Storage
    • The browser does not have "secure" storage
    – by design storage is accessible via JavaScript
    • Code injection attacks allow exfiltration of storage content
    – injection attacks top threat on OWASP top ten
    – https://www.securityweek.com/google-releases-poc-exploit-browser-based-spectre-attack
    • That's why Implict Flow does not allow refresh tokens

    View Slide

  14. 14
    @duendeidentity
    Challenge: Token and Session Management
    • Access tokens need to be managed
    – in absence of refresh tokens, the "silent renew" technique has been commonly
    used
    – utilizes iFrame with session cookie to request new tokens
    – additional benefit of being session bound
    • Frontend applications needs session change notifications
    – JavaScript checkSession iFrame technique
    – relies on a session cookie in iFrame

    View Slide

  15. 15
    @duendeidentity
    JavaScript Client Libraries
    • Good client libraries implement all before mentioned techniques
    – OpenID Foundation also provides a certification program
    • We maintained a certified library over the last 7 years
    – oidc-client.js
    • Lots of pain-points
    – pretty complicated JavaScript necessary
    – ever changing JavaScript landscape
    – browser changes and incompatibilies

    View Slide

  16. 16
    @duendeidentity
    Browser Changes (1)
    • Browsers more restrictive how they deal with 3rd party cookies
    – especially in iFrames
    • Safari
    – https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
    • Chrome
    – https://www.theverge.com/2021/6/24/22547339/google-chrome-
    cookiepocalypse-delayed-2023
    • Firefox, Brave…

    View Slide

  17. 17
    @duendeidentity
    Browser Changes (2)
    • Affected features
    – silent renew
    – session notifications
    • both JS and front-channel
    • End result: do your own token management with refresh tokens
    – refresh tokens end up in the browser
    – requires complicated token rotation techniques (that do not really work)
    • Session change notifications do not work anymore
    – back-channel notifications rarely implemented

    View Slide

  18. 18
    @duendeidentity
    Browser Changes (3)
    • Browser vendors emphasize the "same site" sandbox and architecture
    – SameSite cookies
    – CORS for additional sandboxing
    September 2021

    View Slide

  19. 19
    @duendeidentity
    New IETF Recommendations
    • OAuth for Browser-based Applications Best Current Practices
    – https://tools.ietf.org/wg/oauth/draft-ietf-oauth-browser-based-apps/
    • Proposal for alternative application patterns
    – https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/

    View Slide

  20. 20
    @duendeidentity
    • Application Server
    • iniates protocol flow
    • stores & manages tokens
    • proxies cross-domain calls
    • Browser
    • stores no tokens
    • uses cookies
    JavaScript Applications with a Backend JavaScript Applications without a Backend
    • Browser
    • initiates flow
    • store & manages tokens
    • makes all API calls
    • use no cookies

    View Slide

  21. 21
    @duendeidentity
    Backend for Frontend Pattern (BFF)
    • TMI BFF vs "Full BFF"
    For the sake of clarity, in this document we will use Full
    BFF to refer to the approach where both token acquisition
    and API invocation are handled by the backend, and TMI-BFF
    for approaches where the frontend retain the responsibility
    to implement some functionality.
    Although the Full BFF approach offers better security, by
    virtue of keep all tokens out of the user agent, it is not
    always viable.

    View Slide

  22. 22
    @duendeidentity
    TMI-BFF Overview

    View Slide

  23. 23
    @duendeidentity
    Full BFF Overview

    View Slide

  24. 24
    @duendeidentity
    Building a BFF with ASP.NET Core
    Session Management
    OpenID Connect/OAuth Client Library
    Token Management
    UI Assets
    BFF Host
    Local / Remote API Endpoints

    View Slide

  25. 25
    @duendeidentity
    Duende.BFF
    • Full disclosure
    – we built a commercial BFF framework for ASP.NET Core
    • works with JavaScript and Blazor WASM applications
    – source code is on GitHub
    • https://github.com/DuendeSoftware/BFF
    • Fair Trade Software
    – free for companies and individuals with <1M USD gross revenue
    – commercial license for others

    View Slide

  26. 26
    @duendeidentity
    Building Blocks (1)
    • Serve static content
    – ASP.NET Core StaticFiles middleware
    • User authentication and token requests
    – ASP.NET Core OpenID Connect authentication handler
    • Secure frontend to backend communication
    – ASP.NET Core cookie authentication handler
    • SameSite cookies
    – additional antiforgery protection

    View Slide

  27. 27
    @duendeidentity
    User authentication and token requests

    View Slide

  28. 28
    @duendeidentity
    Triggering login/logout
    • Frontend can trigger login and logout operations by invoking application-
    local endpoints
    GET /bff/login
    GET /bff/logout

    View Slide

  29. 29
    @duendeidentity
    Secure frontend to backend communication (1)
    • SameSite sandboxes to site boundaries
    – e.g. *.mycompany.com

    View Slide

  30. 30
    @duendeidentity
    Session Management / Query
    • Frontend can retrieve session information
    • Or check current session state
    GET /bff/user
    GET /bff/user?slide=false

    View Slide

  31. 31
    @duendeidentity
    Session Change Notifications
    • Backchannel logout notifications is the only technique that works reliably
    – BFF host should implement a logout notification endpoint
    – https://openid.net/specs/openid-connect-backchannel-1_0.html
    • ASP.NET also allows storing sessions server-side
    – cookie then only contains the session ID
    – allows server-side session termination

    View Slide

  32. 32
    @duendeidentity
    Calling local APIs
    • Antiforgery protection
    – requiring a static custom HTTP header will trigger CORS pre-flight request
    • same-origin sandbox
    – can be enforced via middleware POST /data
    Cookie: xxx
    X-CSRF: 1

    View Slide

  33. 33
    @duendeidentity
    Calling remote APIs
    • Calls to remote APIs are proxied via BFF host
    – adds antiforgery protection
    – attaches access token for user/client

    View Slide

  34. 34
    @duendeidentity
    Summary
    • Securing browser-based applications is not trivial
    – browsers allow for some unique attack vectors
    – guidance has often changed over the last years
    • Browser vendors optimize their security to same site scenarios
    – SameSite cookies
    – block third party cookies
    • Backend for Frontend takes advantage of browser sandbox and simplifies
    frontend code
    – same site and origin

    View Slide