I'm currently running into a lot of issues with the CSRF token.
Our current setup is a Ruby API and an Angular front-end, both live on a different domain.
The Ruby back-end solely serves as an API for the front-end.
I've spend a lot of time researching this problem, but I can't find a proper solution.
So far the solutions I've found are:
Generate the token and insert it into the DOM (Different domains, so can't do that)
Let the API return the CSRF token on a GET request (Doesn't seem to work, and it's not a good solution since I don't want to make an extra request just to get the token)
So I'm rather stuck here and not sure how to continue.
Is the current implementation just not working? How do other people create an API with oauth without running into this issue?
Not sure if this will help but here is a sample of a simple todo api in ruby with angular as frontend, and i am using token for authentication generated after the user fills username and password.
https://github.com/sirfilip/todoapi/blob/master/app.rb (the api written in sinatra and sequel)
https://github.com/sirfilip/todoapiclient/blob/master/public/js/angular-todoapi-plugin.js (angular client api service that is used for communication with the api)
TL;DR: Secure your rails API with the doorkeeper gem.
This SO post seems to be the accepted answer when your api and client exist on the same domain.
In the post they outline the angularJS docs http://docs.angularjs.org/api/ng.$http :
Since only JavaScript that runs on your domain could read the cookie,
your server can be assured that the XHR came from JavaScript running
on your domain.
To take advantage of this (CSRF Protection), your server needs to set
a token in a JavaScript readable session cookie called XSRF-TOKEN on
first HTTP GET request. On subsequent non-GET requests the server can
verify that the cookie matches X-XSRF-TOKEN HTTP header
It seems that the security of storing and transferring the XSRF-TOKEN session cookie in this way hinges on having your api and your front-end be in the same domain. Since this is not the case, you may have to implement another form of authorization for any given client session, like OAUTH. I'd recommend taking a look at the doorkeeper gem. The gem will give you the ability to interact with your api as if you were any other client.
Related
I am making a VueJS app with a Laravel backend. I see Laravel has Passport which is used to authenticate/authorize APIs. (Sincerely I have not yet succeeded in integrating Passport. I have not understood where the starting point is. Will post that question separately).
I have done a lot of searching and still have not found the best/easiest way of doing authentication and authorization, and also interface control depending on permission. (I know "best" is subjective but basically means a method that is easy to integrate, understand and use).
Anyone who has been there and used one that worked really well?
I generally use JSON Web Tokens for my web and mobile apps. It's simpler to set up than Oauth and is a better fit for many applications.
Basically, the user sends a POST request containing their authentication details to the appropriate endpoint and receives a token in response. The user can then include that token in the Authorization header of future requests to authenticate them.
The token also includes a timestamp for when it expires, and it can be decoded on the client side so that an application can refresh the token before it expires.
There's an excellent implementation of JWT for Laravel which I use all the time and can highly recommend. There are also client-side libraries for handling JWT with pretty much every framework under the sun.
#MatthewDaly, I followed your recommendation and I stumbled on a VueJs-Laravel JWT implementation here: http://jimfrenette.com/2016/11/laravel-vuejs2-jwt-auth/
I followed through the Tutorial and was able to make it work for my case. (Caveat: The post is slightly old (using Laravel 5.2), but with good understanding of Vue and Laravel, you can be able to follow and implement it easily).
Consider a web application that consists of only HTML and JS for Front end and that communicates with a Web API.
I am trying to protect my application against CSRF attacks and for that I have took reference of this article.
Using the methods in this article, I am able to generate Anti CSRF tokens and pass it to the client. However it depends on first AJAX call that must happen before making regular CRUD operation calls.
With this approach, I need some clarity on few things as well as some alternatives if any. Consider a client visits this web application (which is protected by AJAX based Anti CSRF token), and keeping his session open, he visits a malicious website that contains page that makes the same AJAX calls to get CSRF tokens (assume that attacker is aware of this process), I suppose he can use the headers to make unintended calls thus resulting in an attack.
So how can I protect my application against these?
Please provide more detail regarding this, or if its misleading then help me by providing correct details so that I can tackle it better.
First of all you should use an encrypted communication with the server so the attacker won't be able to read any header data.
If your attacker uses the same calls as you do, he is not be able to guess the anti XSRF token that you use in your calls. A new token is generated for every call to your API. I hope this page helps you with some details:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
I think if we use token based authentication, client have to pass authentication token in each request. And if client do not store it in browser cache and store it in localStorage then browser will not send token in call automatically. And if our service receive any request without auth token then it will discard the request.
I use ajax to store, update and delete resources associated with authenticated user. Routes for these actions use web middleware so cookies, session etc are available. Project is based on Laravel framework.
Is it necessary to protect those routes from unauthorized access in any additional way? I've read about API tokens that one could use, but I am not sure if it is necessary.
I will be grateful for any insights on ajax security or how ajax requests work in general, as it is a little over my head at this moment.
I would say no additional work is necessary assuming you have appropriate checks in place such as a user can't delete another user's entities, etc...
AJAX requests are really just like the user browsing to different pages except it's javascript making requests on their behalf. Since everything is already behind the web middleware, there should be no need for additional authentication since your users have technically already logged in.
Look for JSON Web Tokens
What is JSON Web Token?
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a
compact and self-contained way for securely transmitting information
between parties as a JSON object. This information can be verified and
trusted because it is digitally signed. JWTs can be signed using a
secret (with the HMAC algorithm) or a public/private key pair using
RSA.
and this article:
Authenticate users in Node using JWT and Laravel
There are SNS application with 2 servers. Web backend server and REST API server.
The web server allows user login/logout with username/password, and show user information
The REST API server provides APIs like /topics, /comments, it should be stateless without session
The REST API will serve other web applications
There are some potential solutions, but neither is security.
Base Auth, the browser hold the username/password
Token with expiry timestamp, the problem is user could stay on the page until token expires
So, is there a way to protect the REST API when calling it from AJAX?
If I have understood your problem correctly I may suggest you use the Token solution. In order to maintain security you may generate new token on every request (& send it to client in response), which should be used to make next request, and disable token if it is once used or has expired.
Sorry, I meant to mention it as a comment, but I don't have enough reputation.
We have a web-based application in which we are not requiring end users to login. The application uses Ajax to make calls to REST services hosted on the same server. Besides this application, we want to make sure that if any other applications / agents call the REST service they get denied.
What is the simplest way to secure a REST API like this? My guess is that we would include some sort of security token and make the call through HTTPS. However I'm not clear how the Ajax application would create/obtain/encrypt the token and generally what the lifecycle looks like.
I would rather do this outside of Spring Security or OAuth if possible. I have also read that sending username and password over SSL is enough for authentication. In this case, the app would have a "username" and password and it would send it with every request to the REST service. But how would it keep that information secret if the client is just HTML and javascript in the browser?
Thanks.
In general this is impossible. Someone could just do view source on your javascript, read the token, then do whatever they want.
https is not necessary here. For the token, probably the easiest is to set a cookie when they download the javascript from the server, then that cookie will also be transmitted with any AJAX requests.
This is not really secure - anyone can just see what the cookie is and use it, but it's the best you can do.