I'm troubleshooting an issue with a server instance that I need to do some root cause analysis and right now I believe the driver is Express Sessions.
I've implemented sessions as a primary intra-page data storage mechanism, but it seems that sessions are not unique to the visitor relationship.
By this I mean that I have a session that prefills a form on a "shipping information" page. However, if I visit this page from other browsers or other machines the detail from the first session created on server start is prefilled as if the session data is bleeding into these other browser relationships.
So, I'm trying to understand if the intention for sessions is that they are unique to the visitor by default. If not, can they be made to be unique?
I'm especially worried because admin authentication is also done via sessions.
Yes they are unique to visitor, it sounds as if your code is setting some global state, and not sessions. You may want to post the config you are using, plus where you are setting session vars.
Related
I'm trying to develop a website for reviewing TV series, and I want to limit the rating for a show to one rating per user, and I kind of have no idea where to start, since I'm very new to web development. I'm using Vue.js on the front-end; Node.js with Express on the back-end.
From what I understand, cookies should not be suitable for this purpose since they can be deleted by the user, am I right?
I've also read about sessions and how they are stored on the server rather than the browser (but I also don't know what sessions are or how to implement them).
There's also the user registration system possibility. So, which one of these methods should I use for this purpose?
If you could also tell me about where to start (direct me to tutorials, code snippets, ..) I would be really grateful. Thanks.
Like said by Mr. Anonymous, you need User Accounts. However you could achieve this using in your case, for example, expressjs/session to create sessions and passport.js for the user authentication part.
Here there is a simple tutorial using these two libraries and mongo-db for saving user data.
If you want implement your own session library (only for learning purpose), you can follow these advices.
You need to use all 3 and if your new to web development this will take you some time to get right. You will need user registration, a login system, and when users log in you will create sessions ( which internally use cookies) and if you want them to login with "remember me" you need to explicitly use cookies.
Sessions
This is how express/your-web-app will remember that a user is logged in. Under the hood its using cookies on the users machine that map to ids stored in memory on your server. Without sessions and cookies your users will have to log in on every page....You don't have to worry about how sessions use cookies yourself. There is express middleware libraries that handle this for you so you just interact with sessions like any other object, but its good to know that sessions internally use cookies. You can find lots of articles expanding on this.
Cookies
You will explicitly have to create cookies if you want to give your users the "Remember Me" login option. If you don't care about that then you can force them to log in and then create a session so they wont have to log in again for 20 mins or however long you want.
User Accounts
User accounts are records in a database that uniquely identify each user. The sessions and cookies all point back to this. That is where your store your users information such as their username, email, and whether or not they have already voted on a TV series. When a user logs in you lookup their identity in your database and if you find one you then create a session so they don't have log in again as they navigate your site for a set amount of time.
Recommendation
Start small. Forget about Vue.js for now and use plain HTML until you understand these basic components sessions, cookies, and how to build a login and registration page. If, and I respectfully mean if, you get that working then you can work on making it look pretty and fancy in the front using Vue.js.
Regardless of a language and framework, how does this work in a low level -- putting a variable into a session to authentication a user?
put_session(curr_connection, :current_user, user.id)
Does user user saved in a cookie? On a client? Then what prevents a user of a browser change it by storing id of any user they desire and get authenticated on behalf on that user? Or does user.id get saved on a server and on a client we have only a loooooong session id, in a cookie or in url?
The short answer is it depends. All languages / frameworks have their defaults, Ruby on Rails for example stores it in a cookie by default, PHP stores it on the server, etc. But in pretty much all of these languages, you can change your cookie store to whatever you want.
Some options (there may be more):
Cookies - In this case the cookie is encrypted before sent to the client. The key used for encryption is some sort of an application setting. This is somewhat secure, because even if session values are stored on the client, a user still cannot see or modify them, because he does not have the application key. The advantage of this is that it's very simple and requires zero setup, disadvantages include this being less secure than other solutions, and also the amount of data that can be stored in a cookie is limited.
Server memory - In this case, a cryptographically random session id is sent to the client, all session data is stored in the application server memory, identified by the session id. The advantage is that it's not written to disk and also not sent to the client. Disadvantages include the session data being lost when the application server is restarted.
Server Filesystem - The traditional approach (kind of), session data is stored in files so that it's persisted across application server restarts. In this case, access control to these files is key, but usually taken care of by the language or framework.
Server SQL Database - The traditional heavy-weight approach, all session data is stored in a relational database on either the application server or a separate database server. The advantage is that you have direct control to session contents of any suer, not just the logged on one (for example it's easy to do forced logout for an admin by removing session entries from the database). This same thing can also be a disadvantage in case of an application level attack. Also operation is more expensive.
Server NoSQL Database - About the same as a relational database, but a non-relational database like Redis can also be used. One drawback can be that access control in Redis is not very strong to say the least.
Session Service - In some enterprise applications you may want to implement some kind of a session service (RESTful or else). Obviously this just pushes the problem one layer back, session data must still be stored somewhere with one of the options above.
Your language or environment probably already supports some of these, and if you want one that is not supported out of the box, you can implement your own. However, session management is tricky business, it's quite easy to make it vulnerable. OWASP has a nice session management cheat sheet to consult.
I wrote a simple webserver with nodejs and express. I implemented an user authentication with email username and password. Furthermore I have a remember-function which stores the user id and pwd hash into a cookie. Now I would like an extra session that ends when the user will close his browser or click to the logout button.
Which way is the best practice for implementation? Is the session the same like the remember-function with an expire time and in each request I must check the credentials against the database? (I'm not that sure about this)
Technologies that I'm using: nodejs, express, mongodb
This is not a nodejs question only, I would prefer a general explanation for the problem.
Let me get this out of the way first; Storing the password hash into a cookie would allow anyone to login when they have the password hash and that would be disastrous if the password hashes ever got exposed for some reason. Encrypting cookies is just fine, but don't allow the actual hash you store in the database to be used for authentication. Ever.
About re-authentication, Node is a technology that operates on a single thread and is scaled by running more instances over multiple processors and/or machines. Keeping sessions is a good idea to avoid trips to the database, but you have to think about the architecture as well. What happens if you, say, use sessions stored in files (ala PHP) and you need to scale to multiple machines? Nothing good, at least. So you need a central point to keep track of the sessions.
This can be either your database (MongoDB) or something such as Redis, or another centralized mechanism allowing you to check sessions. Either way, you will have to spend time doing the request and retrieving the session values for the client. If you do not have additional values you need to store it makes no sense to create a dedicated session architecture (that needs expiration, and so forth) and just doing the authentication again is the easiest and most logical solution.
Personally I almost never need sessions and just do authentication again.
How do i remember sessions, even after browser is closed.
is there any alternative than extending expire time of cookies.
i am using code igniter
I implement my version based on this article. The article explain a concept, security, and how to implement persistent login cookie.
The summary of what I done is:
Create a table to hold persistent cookie series and token (series is needed to detect if the cookies got stolen).
I write the model to create required cookies (separated from normal CI session).
The model also do database
read/write of the used persistent
cookies.
I integrate this model to existing user model that handle
normal authentication.
When user go to page that need relaxed authentication, without
normal CI session, but have
persistent cookie session in his
browser, my code will recognize it
since the same series and token also
stored in the database. The user
will got a normal CI session, but
with a flag that this session is
generated from persistent cookies,
not from login form.
When the user go to 'sensitive' page that demand a CI session
without persistent flag, then user
will be logged of, and sent to login
form (if you use yahoo mail, then it
similar with that). This usually the
page where user can do
add/edit/delete, and see sensitive
information.
I hope this help.
The cookies is that only solution i suspect. As you said, you need to extend the time. However if you wanted to use PHP sessions instead, you to make sessions life longer using php.ini file but i don't think using sessions for this purpose will be a good idea because data of sessions is stored on server rather than individual user.
Thanks
I would like to improve security on a current application regarding session management and I want the users to be logged in until they explicitly logout.
How does one implement that securely?
Keep session information in database, like sessionid, ip, useragent?
Please provide the requirements, possibly a database layout, do's and don'ts, tips and tricks.
Note:
I know frameworks like asp.NET, rails, codeigniter, etc... already take care of that, but this is not an option. Actually it for a classic asp application. But I think this question does not relate to a specific language.
Read Improved Persistent Login Cookie Best Practice (both the article and comments).
You should know that such a system cannot be secure unless you use https.
It's quite simple:
User logs in.
The server sends the user a cookie with an expire date far in the future.
If you want, you can record the IP of the user.
User requests another page.
The server checks the cookie (possibly the IP stored with the cookie), sees that the user is logged in, and servers the page.
Some security considerations:
As stated above, there is no secure way unless you use https.
If you're using shared hosting, try to find out where your cookies are stored. Often they reside in the /tmp directory, where every user as access to and through that someone could possibly steal your cookies.
Track the IP, if you know that the computer isn't ever going to change it.
Don't store any information in the cookie. Just store a random number there and store the information belonging to it on the server in a database. (Not sensitive information like preferred colour can be stored in the cookie, of course.)
Create a cookie with a ridiculous expiry like 2030 or something. If you need session state, keep a session ID in the cookie (encrypted if security is priority) and map that to a table in a database. IP/UserAgent etc. tend to be meta-data, the cookie is the key to the session.