To clarify. Using CSP is a general best practice for every JS app.
Once tokens are stored in the browser you want to specifically focus on injection attacks (XSS) - disabling inline scripting is key to that. ——— Dominick On 24. July 2019 at 23:04:20, Aaron Parecki (aa...@parecki.com) wrote: On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier <dba...@leastprivilege.com> wrote: > I think you are mixing authentication and API access here. Depending on application scenario it makes a lot of sense to use OIDC - but rely on the resulting session to control API access. > Unless you want to dive into the details here, I suggest you remove the mention of OIDC because it is misleading. I agree, I removed the mention of OIDC. > I would rather say that ANY JS app should use CSP to lock down the browser features to a minimal attack surface. In addition, if refresh or access tokens are involved - further settings like disabling inline scripting (unsafe inline) and eval should be disabled. I'm not sure what to do with this suggestion. It feels like a blanket recommendation of enabling CSP will likely be ignored since it's too broad, and recommending disabling inline scripts is overreaching unless backed up by a specific threat it's protecting against. Did you have a particular threat in mind? ---- Aaron Parecki aaronparecki.com @aaronpk On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier <dba...@leastprivilege.com> wrote: > > Hey, > > Just read the spec - good to see the progress. Some feedback: > > I am yet undecided if I like the categorisation of the “Application Architecture Patterns”. I definitely want to distinguish between applications only accessing same-site back-end services and “others”. Not sure if “dynamic application server" and “static application server” should be handled differently - they are deployment details and should not decide on the application security architecture. Also not sure how realistic it is to deploy a typical applications solely from e.g. a CDN. But I don’t have the right answer wrt to categories right now. > > 6.1. Apps Served from a Common Domain as the Resource Server > > > OAuth and OpenID Connect provide very little benefit in this > deployment scenario, so it is recommended to reconsider whether you > need OAuth or OpenID Connect at all in this case. > > I think you are mixing authentication and API access here. Depending on application scenario it makes a lot of sense to use OIDC - but rely on the resulting session to control API access. > Unless you want to dive into the details here, I suggest you remove the mention of OIDC because it is misleading. > > > 6.2. Apps Served from a Dynamic Application Server > > I have a .NET sample for that > > https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore21/BFF > And a blog post > https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/ > > 9.7. Content-Security Policy > > A browser-based application that wishes to use either long-lived > refresh tokens or privileged scopes SHOULD restrict its JavaScript > execution to a set of statically hosted scripts via a Content > Security Policy ([CSP2]) or similar mechanism. > > > > I would rather say that ANY JS app should use CSP to lock down the browser features to a minimal attack surface. In addition, if refresh or access tokens are involved - further settings like disabling inline scripting (unsafe inline) and eval should be disabled. > > Thanks for doing this work! > > ——— > Dominick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
