Carries and CSRF
We are building 3 MVC, API, SPA (not Angular) apps with ASP.NET Core. All actions in this application are for authorized users only. This is why we are protecting them with IdentityServer.
We use a cookie to store the value of the bearer token. I understand that the cookie value is automatically sent to the server. But since it needs to be added as an authorization header, this is not automatically handled by the browser.
Does CSRF decrease the likelihood of an attack? Or is CSRF still possible with bearer tokens and do we need to add CSRF tokens?
source to share
Yes, you still need CSRF tokens.
If your SPA or MVC app sends requests to your API based on a GET or POST action for the user, you still need CSRF tokens.
Tell someone to spoof your users to click a link that triggers an action in your SPA or that messages to your MVC app, the app will happily execute and send the bearer token stored in the cookie as the request header as well like when the user clicked a link in the app itself.
To make the whole point of CSRF, an attacker treats the request in the same way as if the user was invoking an action in your web application.
source to share
If I understand that you are correct, MVC and SPA authenticate the user with the Identity Server and store the tokens in cookies intended to access the API.
In general, there are two cases here:
-
Your cookies are HTTP only (not available in the frontend). Then you send the MVC and SPA server side cookies, which retrieve the cookies and send the request further to the API. In this case, you are just as vulnerable to CSRF as usual because you efficiently authenticate with cookies and the subsequent token retrieval and API bearer authentication is based solely on the automatic cookie validation result.
-
Cookies are available in the interface. In this case, you can read them using Javascript and send a server side MVC and SPA authentication request to the server side (to go to the API) or directly to the API so that all servers ignore the cookie content as potentially compromised. In this case, you are not vulnerable to CSRF (since you specified that the bearer authentication header must be explicitly constructed). However, you are vulnerable to XSS ( cross-site scripting): any code injected into your page using either a data validation / sanitization security hole, or just a third party dependency can read the cookies and re-send them to any server. This case is very similar to local / session storage, so any articles describing their vulnerabilities also apply to your scenario (for example, here ).
So, you have to choose between CSRF or XSS as the main attack.
CSRF can be completely prevented with anti-forgery tokens, but if you don't, it is very easy to launch an attack.
XSS is theoretically difficult to completely prevent in modern development due to the many third party libraries you use (another XSS attack vector - ingress sanitation is not such an issue generally since most of the MVC framework does it for you by default as ASP NET Core ). However, you have a chance to avoid this, making this a smart choice in many cases, for example. Auth0 recommends it .
source to share