Is it ideal to generate XSRF Token that will be sent to client (an Angular Application) in .Net CORE REST API? Or Cross Origin is enough to prevent XSRF?
Related
I am learning about CSRF Tokens and how they help secure your web application. I understand the basics of it, but I am confused as to how it works in practice when the web server and api are separate. In practice how is the token generated, added to the HTML and known by the API?
For example, if I host my web app on something like Nginx or S3 and serve APIs via Spring Boot, how does the HTML with the embedded token get generated and passed to the client? Would the Sprint Boot API need to generate the token and HTML and return that to the client? Is there a different flow that am I missing? If this is the case, what is the point of it being embedded in HTML at all?
All of the documentation I have read assumes you are using something like MVC or skips over this entirely.
CSRF protection is only necessary for requests made by a client (for example, a browser) that silently adds credentials for the current user, by sending a session cookie, resending username and password that were previously typed in ("Basic Authentication") or by including a client certificate. This is because users may be tricked into making unwanted such requests by visiting a malicious web page, and these unwanted requests are then made with their credentials, that is, on their behalf.
For requests made by your web server to an API endpoint, this does not apply, therefore the API endpoint need not offer CSRF protection. A web server cannot be tricked into making unwanted requests.
Or can it? Imagine that the web server offers a "proxy" endpoint that converts incoming requests into requests to the API endpoint, and that sends the API response back to the client:
Client --request--> web server --converted request--> API endpoint
Client <--converted response-- web server <--response-- API endpoint
Further imagine that, as part of the request conversion, credentials from the client are forwarded to the API. For example, a session cookie coming from the browser is converted into an Authorization: Bearer <jwt> header that is sent to the API endpoint. Then an unwanted request to the web server endpoint with credentials effectively becomes a request to the API, and a new CSRF vulnerability has appeared: this time on the web server.
The web server must then protect its own "proxy" endpoint against CSRF by issuing and validating a CSRF token.
I'm currently writing a hobbit project. I implemented a REST API service. It reads the authentication token from the Authorization header. Now I'm implementing the web front-end. I know I should store the token in an HTTP-Only cookie for security. However, this means the JS cannot read the token and uses it in the Authorization header when calling the REST API. The solutions I can think of are
Change the REST API, reading the token from the cookie, so the JS code can just make a request. But I've heard this is NOT a good practice.
Make a "proxy" service, translate the request by reading the cookie and filling it into the Authorization header, then forwards it to the REST API service. The web front-end calls this proxy service instead.
Which one or any other solution is the best practice?
I followed several guides on how to set up Authentication on my Web Api, and it does return a JWT when user sucessfully logs in. but what do I do with the token on the client side? the client side at the moment is a blazor server side web application.
I can't find any guides on the second half of adding authentication and authorization to .net core applications. I would like to be able to use the token and extend the authorization down to the user interface.
I suppose I would have to copy the secret key from the web api down to the web application to verify the token.
I want to be able to use the built in Authorization views for blazor, where do I start?
We have a Web App using REST API. The REST API is based on Loopback and uses it's built-in token-based authentication. For the Web App we use forms based authentication over HTTPS, so the user has to enter his username and password which we then use to get access token from the REST API via POST /users/login endpoint.
One of our customers asked us to support single sign-on (SSO) authentication through SAML 2.0 and AD FS.
We configured our Web App as a service provider (Relying Party in AD FS) and managed to support SSO for it. The changeling part is the authentication between Web App and the REST API. The idea right now is to configure both Web App and the REST API as the same Relying Party and add new POST /users/saml-login endpoint to the REST API, so the Web App can send a SAML response to that end point and get an access token based on the claims specified in the SAML response. Everything else should work as it used to work before. Here is the flow I imagine:
Web App generates SAML request and redirects a user to the IdP login page
After a successful login the user is redirected back to the Web App with the SAML Response
Web App acts as a proxy and redirects the SAML Response to the REST API endpoint (POST /users/saml-login) where it is validated
If the SAML response is valid the API returns an access token based on the claims
Web App uses access token for further communication with the REST API same as before
Here is the question: Is it OK to implement SAML-based SSO this way? Do you see any issues or security considerations with this approach? Are there any alternatives?
I have read a lot of articles on the web and questions here on StackOverflow about how to use SAML & REST API together:
Propagate SAML Assertion Response/Security Context to downstream Services/Apps
REST API authentication with SAML
SAML and back-end REST service authentication
Attacking SSO: Common SAML Vulnerabilities and Ways to Find Them
None of them really helped me to confirm or reject the idea described above.
That sounds like a reasonable approach. I can't think of any security issues.
You're simply re-posting the SAML response internally within your application for processing. As long as you then perform the various security checks on the SAML response and assertion within your REST API, there shouldn't be any issues.
My application has been built using SPRING MVC and I have exposed few Restful URIs. (Working Fine)
e.g - http://example.org/alert/alerts //get list of Alerts for the logged in user.
I have configured the application for Cross Site Request Forgery (CSRF) using OWASP CSRFGuard by following the link - (Working Fine) https://www.owasp.org/index.php/CSRFGuard_3_Configuration#Overview
The Restful services is currently been consumed by the same application's UI without having any issues. (Working Fine)
e.g - A data Grid which is part of the same WebApp is displaying list of Alerts by calling this Restful service (AJAX request)
Issue: When I try to access the same Restful services from a different domain/ Chrome Rest Client, it's doesn't return any data except for 302.
If I set The "unprotected pages" property in csrfguard.properties for the restful URIs, I am able to access the Restful service from RestClient/different domain.
Please suggest if I need to do any other configuration so that the same Restful services which are protected by CSRF can be accessed from a different domain/Chrome rest Client.
1.if you are generating CSRF Token at server side then
provide one get request inside that request validate session and send the created CSRF Token as hidden to client, now remaining request should be POST,PATCH,PUT or DELETE which are getting CSRF Token in every request header.
2. if you are generating CSRF Token at client side then from first request which is authentication or authorization get the value of Token and compare it with every request in your custom filter.