Hi Emond, Sorry I missed this email before my last update to the draft. I wanted to address some of the questions anyway though.
> 6.1. Apps Served from a Common Domain as the Resource Server This section has been renamed to "6.1. Browser-Based Apps that Can Share Data with the Resource Server". In particular, this section is meant to point out that in some cases you can use traditional cookie mechanisms instead of OAuth access tokens. I wouldn't say HTTP-only cookies make APIs "very vulnerable to CSRF attacks" though. The SameSite cookie attribute will prevent CSRF attacks, and is easily deployable in this case. I will rephrase this section to better clarify this. > 8. Refresh Tokens Draft -04 rewrote the refresh token section to allow refresh tokens in browser based apps as long as they follow the recommendations in the Security BCP. > Without the browser, there is no application. There are starting to become cases where browser based applications can actually run without the user being present at the device now, such as all the work around progressive web apps and background sync. In these cases it may make sense to let JavaScript apps use refresh tokens to perform work without the user being present. > Shouldn't this BCP give actual recommendations on how to manage this > (preferably without full page redirections) This is a valid point and I'll bring this up in the next meeting to see if there are any ideas about how best to handle a recommendation. > 9.7. Content-Security Policy > I think it should explicitly state the policies that should NOT be allowed I'll bring this up in the next meeting. Thanks for the feedback! ---- Aaron Parecki aaronparecki.com On Tue, Aug 6, 2019 at 8:20 PM Emond Papegaaij <emond.papega...@gmail.com> wrote: > > Hi all, > > After my vacation I've finally found time read up on the new BCP draft for > browser based apps. First of all, thanks for the great work on this spec. I > think this is a very important area to work on, as browser based applications > are getting more and more common. Here's my feedback: > > 6.1. Apps Served from a Common Domain as the Resource Server > > This section has seen quite some comments, but IMHO one important aspect has > not been emphasized enough: using an HTTP-only cookie to secure an API can > make it very vulnerable to CSRF attacks. This was already mentioned by David > Waite, but has not seen any response. Storing the access token (or session id, > or whatever it is called when stored in a cookie) in an HTTP-only cookie will > make it hard to steal, but also hard to protect from misuse. Any page can > embed links to your API, and the browser will simply send the cookie. > 'Traditional', server based, web applications require special protection > against these kinds of attacks, but RESTful APIs often don't have such > protection. IMHO advising to use a cookie to secure your API is therefore a > dangerous advice. > > 8. Refresh Tokens > > This section also has seen a lot of comments. Why all this focus on the > refresh token? All the attack vectors apply to the access token as well. If > tokens cannot be stored securely in a browser based application, the > authorization server should not issue any token at all. Leaking a single valid > access token is likely to be more than enough for an attacker to get all the > information he/she needs, even if it is only valid for a couple of minutes. > Also, when an attacker manages to get an access token once, it is likely he/ > she will succeed a second time (i.e. via an XSS attack). Placing these > restrictions on refresh tokens, without addressing the access token seems > senseless to me. > > I think this section should be about the lifetime of the authorization and > detecting potential leaks of tokens. For a browser based application, I see no > use at all for offline tokens. Without the browser, there is no application. > Therefore the access should be scoped to the browser session, and this is IMHO > best checked by the authorization server. At Topicus, we plan to implement > this with short lived access tokens and performing re-authentication in a > hidden iframe with prompt=none. The disadvantage of this is that is requires > OIDC for the prompt parameter. In this setup we do not need refresh tokens, > but other solutions may also apply. Shouldn't this BCP give actual > recommendations on how to manage this (preferably without full page > redirections, because those destroy the state of a SPA), rather than simply > forbidding refresh tokens? > > 9.7. Content-Security Policy > > A very important measure to secure your browser based application is a strong > CSP, but it is also very hard to do correctly. The current advise is a bit > broad. I think it should explicitly state the policies that should NOT be > allowed (inline scripting, eval). This was already mentioned by Dominick > Baier. Also, it could benefit from a few examples (correct and wrong). > > Best regards, > Emond Papegaaij > Topicus KeyHub > > > _______________________________________________ > 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
