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

Securing Browser-based Applications using the B...

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. 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
  2. 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"
  3. 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
  4. 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
  5. 8 @duendeidentity CSRF mitigation with anti-forgery tokens • Add explicit

    “credential” on every request Server-side Application render page & anti-forgery cookie <form> <input type="hidden" name="__RequestVerificationToken" /> </form> post-back: cookie + hidden field Page web api call: cookie + header [ValidateAntiforgeryToken]
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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…
  14. 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
  15. 18 @duendeidentity Browser Changes (3) • Browser vendors emphasize the

    "same site" sandbox and architecture – SameSite cookies – CORS for additional sandboxing September 2021
  16. 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/
  17. 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
  18. 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.
  19. 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
  20. 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
  21. 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
  22. 28 @duendeidentity Triggering login/logout • Frontend can trigger login and

    logout operations by invoking application- local endpoints GET /bff/login GET /bff/logout
  23. 29 @duendeidentity Secure frontend to backend communication (1) • SameSite

    sandboxes to site boundaries – e.g. *.mycompany.com
  24. 30 @duendeidentity Session Management / Query • Frontend can retrieve

    session information • Or check current session state GET /bff/user GET /bff/user?slide=false
  25. 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
  26. 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 <body>
  27. 33 @duendeidentity Calling remote APIs • Calls to remote APIs

    are proxied via BFF host – adds antiforgery protection – attaches access token for user/client
  28. 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