I have a REST API based on ASP.NET Core 3.1. This API will is called by other servers, currently there is no client application which calls this API.
In such a scenario do I need Anti-Forgery tokens? Also if its needed how inject anti-forgery tokens in a Server-to-Server communications scenario?
Here is an offical document about csrf.
A CSRF token is generated based on Http Session. If your API endpoint is relying on a cookie /or some mechanism to reestablish the session.You need to prevent CSRF attack.In the official link,you can see the example of CSRF attack,it includes an authentication cookie.
Related
When using Passport, a session is used to transfer the user information. This breaks the statelessness of my REST api. How can I use OAuth statelessly on a node/express server?
Most APIs will use the Authorization header, but this is not fundamentally different from putting it in a cookie. Having an authentication token in either header doesn't really break any REST constraints.
The Authorization header is probably preferred unless you want your API to be usable by web browsers.
I am currently implementing a API project using express-js.
There are multiple clients for the API. This includes a front-end web app and some backend services.
I am looking at using a normal session based management for authentication using express-session.
I am preferring this over jwt since session based + secure cookies is easier for many use cases which I would need need
Ability to revoke user access from server side
Allow only single active web session for a user
I am sure I can maintain a separate persistance table with userid + refresh_token + access_token to achieve the above.
Its just that session based gives me these in straightforward.
Now when it comes to my daemon services, I would still like them to go via API route. This will be more like Client Credentials Flow.
Since these are non-http clients, cookies will not be supported.
I am not sure how my app can API's continue to support both of them ?
The only option I have now based on readings on various blog sources is to use JWT in the cookies for the web front end and using JWT as bearer in header.
This means that
I will need to implement all the security mechanisms like token black-listing, regenerating refresh_token etc.
I will potentially lose out on main benefit of JWT of statelessness.
What are the options I have to ensure that my API layer can support both front-end web apps like react/angular and other micro services
The standard solution here is to use an API gateway:
APIs receive JWT access tokens regardless of the client, and validate them on every request
Browser clients have their own routes to APIs, and send cookies that contain or reference tokens
Mobile clients call API directly, but with opaque access tokens
APIs call each other inside the cluster using JWTs, typically by forwarding the original token from the web or mobile client
The API gateway can perform translation where required. Here are a couple of related articles:
Phantom Token Pattern
Token Handler Pattern
Done well, all of this should provide a good separation of concerns and keep application code simple.
I am integrating a legacy application (an ASP.NET MVC 4 app) with OpenID Connect. Once I obtain the id_token and access_token from my OIDC provider I need to store them. In typical fashion they have to be sent 'over the wire' from the client side to the server side because the server side must process the id_token to determine which user made the request. The access_token is not processed by my application. It's just stored in my application until I need to make a request to an API that requires JWT Bearer authentication.
The way I see it is that the id_token and access_token are sent from client and server either way - whether it's an a header or a cookie. Can I store the id_token and access_token securely in a cookie if it's marked as HTTP only?
Edit:
I should add a little more information about my scenario.
1) My application always uses HTTPS, and all cookies are marked as secure. This removes MITM (Man In The Middle) vulnerabilities
2) Every PUT, POST and DELETE request uses ASP.NET's anti forgery token classes. This protects against XSRF.
3) All input is escaped and sanitized using ASP.NET libraries which removes XSS vulnerabilities.
4) The cookie that would contain the id_token would be marked as http only, removing the ability to read and access the cookie from the client side.
You should probably not store the tokens in cookies. Ideally the access token would be stored in memory on the client. This way they aren't sent automatically with requests to the server which is why there are risks involved with cookies. Anywhere else could open you up to potential vulnerabilities.
The RFC 6819 specification, titled "OAuth 2.0 Threat Model and Security Considerations" touches on the risks and vulnerabilities around OAuth tokens. Specifically, I would recommend reading the following sections:
4.1.3. Threat: Obtaining Access Tokens
4.4.2.2. Threat: Access Token Leak in Browser History
5.1.6. Access Tokens
In applications I have written the tokens have been stored in local storage and in memory.
I'd recommend reading through the OAuth 2.0 specification so you know the risks involved when using OAuth 2.0.
Please don't count on that, HttpOnly is a flag that tells the browser that this cookie should not be accessed by client side scripts and it is true only if the browser supports it.
You can find more info here: https://www.owasp.org/index.php/HttpOnly
Also I suggest to dive a little in the OWASP web site as they have documents regarding best practices for problems like the one you listed.
You can see if your browsers support HttpOnly here: https://caniuse.com/?search=httponly
As of 2021, 95% of browsers support it.
I have a load of api endpoints that I want to protect from CSRF. I'd like to do this in a stateless way, so naturally JWT comes to mind.
The problem is, these endpoints do not require the user to be logged in.
So, my problem is, I can use JWT, but I have no way of verifying the token on the server side -- I have no logged in user I can match it to.
Is there any way JWT can be used in such cases?
CSRF is only a problem for requests where the browser implicitly authenticates the request (cookies or basic authentication). But if you do not have any authentication, any site could potentially call your API.
So if I understand you correctly, you are looking for a way to make sure that the request to your API is coming from your web application.
Take a look at the client credentials grant in OAuth 2.0. It basically issues a token to authenticate the application instead of the user.
Is there any problem if I sent the identity token, which has been issued from a trusted IdP, to javaScript code in order to use it in calling a web method with authentication?
Is there any security concern from doing that whether the token is encrypted or not!
In my case, there is a web application which is asking an IdP to authenticate users. I'm using a WCF web service with Ws2007FederationBinding in order to send the security token. Everything is fine when I call the service from the server, but now how can I consume it from the client side using JavaScript as well?
I'm not familiar with Ws2007FederationBinding. Considering that you need to do calls from the client side, I don't see a problem with embedding that token in the client.
I believe that's as the same when you need to use an external API and you have some kind of "auth" token associated to your service.
Ws2007FederationBinding is a SOAP binding with a SAML security token in the envelope. It will be very difficult to call a service with this binding from JavaScript.
This binding requires the client to talk to an STS to get the SAML token and prove it was the requester of that token (holder-of-key) to the service (relying party). This involves cryptographic operations that are hard to do in JavaScript.
The 'best' way to solve this issue is to create RESTful proxy services that your JavaScript layer talks to and have this REST service talk to the SOAP backend services. You should secure the REST services with a bearer token (JWT) and exchange it for a SAML token before you call your SOAP service.
You can use the JWT token handler class in .NET for the translation between JWT and SAML.