I've built an API with Node.js/Express which I'm currently using alongside my Angular app.
For authentication, I have a username/password setup which then returns a JWT which is happily used.
Now, I've been spending some time (and reading such Stormpath articles) I want to use cookies rather than localstorage for storing these JWTs. And thats where my questions begin.
So what I've essentially done thus far is updated the saving and reading, e.g. for saving from $window.localStorage['jwtToken'] = token; to $cookies.put('jwtToken', token);. And for reading, from return $window.localStorage['jwtToken']; to return $cookies.get('jwtToken');
At this stage I was wondering whether someone could help me understand a few bits, kindly correct and inform me of any missing parts of knowledge:
1 - So in addition to the actual saving and reading as above, is there anything else I need to explicitly set - what I think is HttpOnly cookie flag (so JS can't access the cookie data.
1b - Do i also need to update my node API so that instead of returning res.json its doing res.cookie?
2 - Do i also need to set the Secure cookie flag so that its sent via HTTPs. So at present i wrote a simple authInterceptor that attaches a header with each request: config.headers['x-access-token'] = token;. Is this where that secure cookie flag would be set?
3 - So using cookies am i correct to understand XSS attacks are minimised as JS can't touch the cookies however I need to concentrate on CSRF. For this I am thinking of using this CSRF middleware on my node api server side and use this alongside Angulars built in XSRF-TOKEN as described here. Is this a good implementation to follow?
4 - When looking at Chrome inspector, I see the cookie containing the JWT, however the HTTP/Secure/Same-Site are all untucked, also the Expires says Session. Could someone please explain what this means:
Sigh, I think thats it, sorry if its a little long winded. Hopefully others can gain from what we learn here.
Any help appreciated.
Thanks.
If you set HttpOnly $cookies.get('jwtToken'); wouldn't work...
1b. Don't understand the question here...
The Secure flag tells the browser to only include the cookie if the request is an HTTPS request. You can still make HTTP requests, but the cookie will not be included. document.cookie = "name=somevalue;secure"
If you set HttpOnly so that JavaScript can't read the cookie, that's some protection, but if you have XSS, then all bets are off. The injected script could still perform network requests, and do exactly what your code is doing to include the CSRF tokens. You still need CSRF-protection, but in most cases XSS means circumvention of CSRF-protection.
Session means the cookie will be deleted automatically if you close the browser (which people don't really do all that often anymore).
Related
We have a token based OAuth authentication mechanism for our angularjs application. The acunetix tool indicated that XSRF threat is there.
Is CSRF an issue for token based authentication (Because we are not using any cookies for user identification / authentication / sessions)?
If CSRF is an issue for token based authentication, is there be any way to implement prevention without using cookies?
As far as I know token based authentication is in no way affected by CSRF. E.g. if you use cookies, and bad guys lure users into their site where they can create a special button that will do a post to your site -> here is CSRF where you can execute some requests on behalf of the users.
Now if you use tokens that are stored in session/local storage e.g., they are never automatically passed with the request. You probably use something like angular interceptor or similar technology to pass it along with every XHR request. This never happens automatically.
You can read a bit more on token auth in this very good post. In point number 6 there is a little section about XSRF/CSRF, XSS.
In my modest experience these big security tools can often tell you something that is not true just to make themselves more "significant". But it would be interesting to know exactly how it plans to execute CSRF and what exactly made it think it is possible? E.g. you might have a cookie that you missed?
P.S.
XSS attack (to steal token) gets more possible with tokens, since you can put HTTP-only like for cookies. So any successful XSS will be able to read your token, so you need to make sure that you have a good protection against that. But it's usually covered well by frameworks.
I've been diving into authentication between Angular and Express, and decided on using token auth with JWTs and the npm jsonwebtoken package. I've got everything set up on the server side and am receiving the token on the client side, but now I need to know how to make it send the token with every request.
From what I've found, most resources out there say to use an $http interceptor to transform every outgoing request. But people at work have always used $httpProvider.headers.defaults.common["Auth"] = token in a .config block, which seems a lot more straightforward to me. Here's a blog explaining how to do it both ways.
But the accepted answer on this stackoverflow post says it would be better to use interceptors, but he doesn't give a reason why.
Any insight would be helpful.
After a bunch more research and a conversation on Reddit, it seems like the best way to do it is through the interceptor. Doing the setup in the .config or .run blocks may be good for checking if the user is already authenticated when they first load the app (if there is a token in local storage), but won't be possible for handling dynamic changes like logging out or logging in after the app is loaded. I'm pretty sure you could do it through the $http default headers, but might as well just do it in one place.
Hopefully this helps someone in the future!
I need some advice regarding using session tokens to authenticate users. I am building an AngularJS app which uses an API to tie in with the backend. I am only building the front end, not the backend. The documentation states that all calls to the API have a session token attached in the body of the request (POST).
I would like to know about the security of storing this token in localStorage. That is where I am storing it now and retrieving and attaching it to each API request. After login, the server sends the session token in the body and I save it from there.
There is no documentation about an x-access-token header that should be sent with the request made to the server. It is not being checked server side. What are the implications of this? I feel that it is susceptible to attacks without this added layer of security.
My main concern is the security of this setup. I want to know what the best setup is to make sure this app is as secure as possible and recommend changes to the way the backend is setup to facilitate this.
Thanks!
As you tell, you are only working on the UI part and not the backend. It is up to the backend team to ensure headers are properly evaluated and security is enforced (btw request headers do not belong to request body). Just put the token into the x-access-token header as they tell.
Storing the token inside the localStorage gives you a little more control over the cookie: You will not accidentally send it to unnecessary URLs. However, older browsers do not support it - you may need to use a shim for that.
In a case of SPA, you may consider not storing the token at all: It could be fetched each time your application is accessed and then stored within a service in angularjs, but it depends how your fetch/login operation is implemented (is it always interactive, how long does it take, etc).
I would suggest use $cookies rather than localstorage. As localstorage does not support some legacy browser.
I am using cookies to store token in my project
It is common to authenticate to web services using an authorization header which contains a secret token. And since the security of this mechanism depends on the token to be secret care should be taken that this token is not leaked.
There are countless tutorials on the web which explains how such an authorization header can be set using angular and least the ones that I have actually read use an $http interceptor and now one discusses that the token is not leaked.
There are some public and some private APIs out there which can be talked to cross domain thanks to CORS. And obviously I do not want to send my internal authorization tokens on any of those requests.
Some other techniques come to mind such as setting the token manually only on each and every request, but that means lots of duplicate code. The $http server could be wrapped in an $authenticatedHttp service so that it is always appearent from the object used whether it is the authenticated service or the normal one. However the $http service has so many methods to be wrapped.
Is there a better solution?
UPDATE
From the answers I have the impression that my question was not understood. I try it with a more concrete example:
I have a private web page. People have to login with username/password and let's say for simplicity's sake that we use HTTP basic auth, so username/password are bas64 encoded and are transmitted on every request in the HTTP header "Authorization". So far there is no problem.
But there is this great&free weather widget. I can retrieve the current weather information in JSON format from https://myWhateverWeatherService.tld/weather.json. After the login to my private web service I also retrieve the weather information (CORS allows me to do this).
The problem is that even though myWhateverWeatherService.tld does not require any authentication at all, angular's $http service will still append the Authorization header. And I don't trust the guys at myWhateverWeatherService.tld. Maybe they just set up the service so they can steal Authorization token and do lot's of nasty stuff with them.
I need some reliable way to deal with that. I already thought about checking the url with some regex in the interceptor. This is possible, but it is also not to difficult to forget about a certain case that my regex will miss.
The token is always sent through the wire, I guess that is the most vulnerable part of it.
Since the token must always be present on the http header itself, the only way to make the request more secure is to encrypt the whole request, and for that you should use SSL.
If you are concerned about the safety of storing the token on the client machine, you can keep it only on the browser´s memory, without persisting it on a localstorage or something like that. So every time the user closes the browser and open it again, s/he must log in.
I've read almost every answer on SO and some blog postings, but I can't figure out one simple thing. In a simple token authentication scheme where the server generates a token and sends it back to the user after verifying credentials, how does the client store and then resend that token in each request? I have seen both cookie examples and header examples. I would like to use the HTTP Headers if possible, but I can't figure out the mechanics of how to send the token to the client, where it will sit, and then have it sent back in the header upon requesting a REST resource.
I am using Jersey/Guice with AngularJS on the front end. Here are the resources I started with:
http://porterhead.blogspot.co.uk/2013/01/writing-rest-services-in-java-part-6.html
Session management : How to generate Authentication token for REST service ? (Jersey)
It depends on your needs. You can use HTTP basic or digest auth, if it is appropriate for you. If not, then if you don't need a permanent storage, you can store credentials in memory. If you need a permanent storage, then you can store them in localstorage, or any other client side storage, but aware, that they are considered not secure.
Anyways I think if your client or service is compromised somehow with xss, then you lost, and it does not matter what else you do about it. Otherwise you can send the credentials in plain text securely as long as you use HTTPS with proper settings. (But that's just an opinion, I am not a security expert, at least not in this topic.) So I think you should concentrate on not being xss vulnerable. For example you should use the proper headers and filter the input against js injection (and by firefox data URI injection). And use TextNode in your client instead of innerHTML wherever it is possible.
For example if you are using Javascript you can store the token in localstorage like window.localStorage["token_id"] on the client side.