I am handling sessions by storing the user data in the sessionStorage of the browser using AngularJs. The basic flow I am using is as follows:
Login by front-end
Returning the user from node i.e back-end
Storing the returned data in sessionStorage
sending id of user with every request to the server
clearing the storage when signing out
Is my approach correct?
If not then how can I manage sessions efficiently in a MEAN app?
Storing critical data as tokens into LocalStorage or SessionStorage is definitely not a good idea, as it is vulnerable to XSS attacks.
A better practice would be to store these informations in a cookie... However, we're not done here, as cookies are vulnerable to CSRF attacks.
Thus, best possible way to do it is to store critical infos in a cookie, and protect your clients from CSRF by storing a randomly generated session key in SessionStorage.
Check this answer :
CSRF Token necessary when using Stateless(= Sessionless) Authentication?
Related
I am developing a project using Django REST API (backend) and React JS (front end). I am using Json Web token for authentication. But I am confused at the point that whether should I store Json Web token in local storage or in the cookies? Which one is more safe and why? How big companies handle this kind of security between API and client side?
The fundamental question is more secure against what?
The primary threat is cross-site scripting (xss). With regard to that, a cookie is definitely more secure, if and only if it is set as httpOnly.
However, if the auth info is in a cookie, cross-site request forgery (csrf) becomes an issue, and you have to implement csrf protection. Not the end of the world, but you need to care about it. If you store the auth token in localstorage and send it as a header, csrf is not an issue.
Also cookies with an expiry (persistent cookies) often get saved to plaintext files on the client, which may or may not be a valid threat in your threat model.
So in short, it depends. Overall, storing the token in an httpOnly, secure cookie is usually considered the most secure, but it has implications as described above. Storing the token in localstorage is acceptable too in most cases. Even more so because if you need to send the token to multiple backends (on different origins), you can't have it in a cookie, because that would only be sent to its own origin.
As always, the devil is in the (implementation) details.
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
I'm working with AngularJS and Parse (through the REST API). I am making a SPA and I have the following problem, all variables are erase when the browser refreshes the page. This means the user's session is closed. I thought of storing the session Token in a cookie to avoid this but If someone is able of retrieve this value, he or she could access all the users information.
What is the most secure way of archiving user's session persistence?
Thanks you all very much
Use sessionStorage. It will not be erased upon refresh.
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.
I'm building an AngularJS application that interacts with an API that uses authentication tokens to authenticate users. Everything seems to be working fine, but I'm struggling with a way to properly persist the authentication token between requests.
At the moment, when a user logs in with correct credentials an authToken is returned, and I'm setting that on $rootScope.authToken. I'm also sending that auth token for future requests, but if I do a hard reload reload the webpage with F5 $rootScope gets cleared and I have to authenticate again.
I'm aware I can store the authToken in a cookie, but would that be the most secure way? Am I better off using local storage to store the token? If local storage is used, would that not get cleared when the user restarts their browser? I'd ideally like the login to persist for a few days.
Firstly, I'm not sure what the format of your authToken is but localStorage should not be used for any sensitive data. Using localStorage works great (and survives browser restarts) as long as your authToken is relatively tamper-proof either through some form of encryption or nonce.
Essentially, you should be careful that since the value is "visible" to all client-side users it should be assumed to be possible to modify or increment.
Have you thought about revocation of login sessions? For example, if you want to log out all active sessions of your application, how would you do it? Since the authToken is stored client-side, you may need to add a timestamp (or some other unique value) to it that can be checked server-side.