Securing Browser-based Applications using the BFF Pattern

BASTA 2021

Transcript

1. Securing Browser-based Applications using the BFF Pattern Dominick Baier @leastprivilege https://duendesoftware.com
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 dominick@duendesoftware.com blog https://blog.duendesoftware.com twitter @leastprivilege slides https://speakerdeck.com/duendesoftware
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"
4. 4 @duendeidentity Setting the scene
5. 5 @duendeidentity "Modern" Business Applications Browser-based Application call APIs authentication, SSO, federation, access tokens OAuth 2 OpenID Connect
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
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
8. 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]
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
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
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
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
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
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
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
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…
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
18. 18 @duendeidentity Browser Changes (3) • Browser vendors emphasize the "same site" sandbox and architecture – SameSite cookies – CORS for additional sandboxing September 2021
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/
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
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.
22. 22 @duendeidentity TMI-BFF Overview
23. 23 @duendeidentity Full BFF Overview
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
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
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
27. 27 @duendeidentity User authentication and token requests
28. 28 @duendeidentity Triggering login/logout • Frontend can trigger login and logout operations by invoking application- local endpoints GET /bff/login GET /bff/logout
29. 29 @duendeidentity Secure frontend to backend communication (1) • SameSite sandboxes to site boundaries – e.g. *.mycompany.com
30. 30 @duendeidentity Session Management / Query • Frontend can retrieve session information • Or check current session state GET /bff/user GET /bff/user?slide=false
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
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 <body>
33. 33 @duendeidentity Calling remote APIs • Calls to remote APIs are proxied via BFF host – adds antiforgery protection – attaches access token for user/client
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