I just want to know which one is the best way to handle the cookies?
Using Express.js? Node.js or client side javascript jquery?
I am little confuse with security perspective.
Thanks for all your help/information.
Cookies are HTTP concepts which is irrespective of the language / platform. So, Node.js is a server side platform while Express.js is a server side web application framework for Node.js and jQuery is a client side library.
From security perspective, you should not store cookie information in plain text. Also, "you shouldn't allow client side scripts to set or read the cookie value". If you are already using Express.js, then I would recommend setting & reading of cookies to be taken care by your application using Express.js and ensure you encrypt the cookie values.
You should keep some session id in cookie, not actual data (it's true for most cases, especially for any user-related sensitive data).
The correct approach for using cookies would be:
Make user input his login/password and check "keep logged in" checkbox.
On server side, based on inputed login and password, decide if user credentials are valid.
Assuming valid credentials, create some random id and store information on server side, that this given random id is related to some data (some user id, settings etc.).
On server side, based on value of "keep me logged in" checkbox you would then do following: if checkbox was checked, create cookie that should expire in some time in very distant future (like, say, 100 years). If checkbox wasn't checked, you set cookie to expire once browser session is over or for example in 1 hour. Keep in mind, that user can tampre with expiration date of cookies once you send them, but that's a whole different story.
User (client) is receiving your cookie which has that generated id in it. That cookie is sent to you by browser on every request.
On server side, once you get your cookie from client, check if you know that id and if it is valid. If so - retreive user data from your databse or whatver and operate on those.
Related
I am using PHP, AJAX, and JS for my PWA development. I want the user's logged-in state to stay persistent when he/she come back to the PWA app.
Right now I am doing it via the help of the Access token and saving it in the cookie with HttpOnly via PHP. Defining it here -
User enters details, and log in to the app.
That details sent to the PHP backend, via AJAX.
Backend login code check that details from database and if matched, then code create a random hashed token.
Backend code save that hash to the cookie with HttpOnly and secure flag.
User then prompted with a successfully logged-in message.
When the next time the user comes back to the web app, the server PHP code looks for that login hashed value saved in a cookie and finds the relevant user from Database.
If a match found, the user successfully logged-in.
So now my concerns are -
Is this whole process secure and the same as what gets implemented in Industry.
If not, then what can be the best way to achieve this with security.
You can find the answer you are looking for here:)
"Keep Me Logged In" - the best approach
It is important to use an hashed cookie.
On the client side you should use a cookie that represnting the "id" of the "hashed" cookie,
When the next time the user comes back to the web app -> you will check his cookie("id") with the hashed cookie you saved on the server and check for a match(done on server side).
Note: the hashed function is done on your server.
One more thing: never let that cookie(hashed) leaves the server.
I'm working on a React application. I am defining user roles and restricting access to components based on the permissions level of the role. I am looking in to using signed cookies to set the permissions from a php backend. When I determine whether the application should render a component based on the data in the cookie, how do I verify that the roles in the cookie have not been redefined by the user without sending the cookie to the backend?
That's not the right approach, in my opinion. The components should be free to load - if there's something built-in to a component that an un-authenticated user shouldn't be able to see, there's nothing stopping someone from going into the source and discovering it themselves.
You have to take a different approach for front-end applications - all the components and UI are public. When the component fetches information from the server to display to the user, the server will still do the session authentication and respond with a 4xx (401 would be a good place to start) and the component would handle that response appropriately.
If modifying the role in the cookie would allow the user to gain more rights, then the solution is not to check the validity of the cookie on the client side. The user could also modify the client side script to circumvent/skip the integrity check of the cookies, and you would have the same problem as before.
The only correct solution is, that the user won't get those informations/scripts at the first place. So you need to check on the server side what informations are allowed to be send to the client, only send the data the user is allowed to see, and verify all actions the user sends to the server on the server side before you execute them.
We have a public facing website, in which the user can login using an email address.
After the user logs in, we populate the cookies of that domain with a uniquely generated session id, and the user details, like emailAddress, Name etc, based on which other calls are made to the server like getUserProfile etc.
However the problem, is any user can make changes to his hosts file, and write a simple Servlet to create the cookies of my domain, and can accordingly set any random session id and user details in the cookies, and then can get automatically logged in.
On the client side, how do I maintain that the appropriate session id is correct. If I maintain the session ids on the backend in some caching framework like memcache, then each hit on website every page will hit the server, which is not what i would want.
What is the way to get around this problem and ensure that the fraud user is not able to set my cookies after making changes in his hosts file.
On the client side, how do i maintain that the appropriate session id is correct.
You can't. The browser is controlled by the user. You control the server. You can only perform authentication on the server.
What is the best way to transfer data from page to page on a website? For instance, I'm logged into this site and stay logged in know matter how many times I switch pages and even if I close the browser. How exactly is this done? I'm thinking through the use of cookies, but I"m really not sure?
Thanks!
There are two options Cookies and Sessions
Rule of thumb: do not trust user input. Cookies are user input, session ids that are stored in cookies are user input, http headers are user input -- these things must be triple checked for every possible thing. Session data, on the other hand, is stored on your server, so it is more or less secure if not stored in /tmp.
One of the most popular setups for session authorization is this: session id is stored in cookie, and everything else including password is stored in session. After starting a session based on id from a cookie, you should get user id from session data and then check if password stored there is still valid.
If you set a session variable, the user can't directly change it unless they hijack another session cookie.
What you mainly have to watch out for is on shared hosting, your session data isn't secure (typically other sites can see it).
It's also worth noting that cookie data isn't secure either. It shouldn't be relied upon in the same way that form data shouldn't be relied upon (no matter what client validation tells you).
Your best practices with passwords are:
Store the password in the database in a hashed form, preferably SHA1 (first choice) or MD5 (second choice);
When you receive the user's password, encrypt it and check it against what's stored in the database;
Set the logged in username in the user session;
Expire the cookie after some period (even if its days) rather than having it last forever; and
Use a secure connection (HTTPS not HTTP) where possible. SSL certificates are cheap.
Yes, you stay logged in typically because there is a cookie which stores your session ID.
I am writing an application using Sencha Touch that will require a login to the server. I need a way of keeping track of the session, but I'm not sure what the best way of doing this is. It seems that in HTML5 there is 'sessionStorage' which can be used for this.
From what I understand I need to do the following:
1. Send username/password to server
2. If combo is correct, server sends some session ID variable to phone
3. Phone saves sessionID in sessionStorage
4. Every time the phone communicates with the server it sends sessionID with message
5. Server checks a message for correct sessionID (and possibly checks IP address too)
6. When user logs out of app, sessionID is wiped from phone and server
Can you please let me know if this is the correct route to take?
I usually have handled everything on the client side stored in a JS object. Not sure if it's a best practice or not, but it has worked for me. If I'm storing a password I encrypt it and only match it with the hash to see if it is valid. For session time outs you can set up a timer and for every Ajax request check whether the "session" is still valid.