Hello fellow developers
I have obviously under estimated a thing when developing my first complex web site, where user creation and login is required.
It appears that cookies can be edited and modified by the user logged in, by using some developer tools i.e. in Google Chrome. That, I never gave a thought.
So, here is my issue.
When the user is logged in, I store the user name in a cookie.
If username-cookie is not blank, and I can find a user file with that name, the user is logged in, per se. Otherwise, no user is logged in.
When the user logs out, I simply expires the cookie, which works fine.
Now, the problem is, that a user obviously can edit the content of a cookie, outside the web application, or with javascript.
What would be the correct approach here to ensure, that the username cookie is not compromised in any way, other by my web application?
Making them read-only is not possible, I assume. Encrypting the cookie and then decrypting might work, I guess. Then, the cookie would be nonsense to the user, and if modified, result in a logout, as no valid username can be found upon decrypting the edited cookie.
I have stalked Googles cookies, and it appears that there are a lot of xxID cookies, which contains garbage. Does that mean, that encrypting/decrypting is the only way to make it work? I also considered some kind of login-ticket, but that would require a table lookup every time a user interacts with my web page.
Can anyone give me a hint as to what would be the correct approach?
Thanks in advance
Best regards,
Karsten Heitmann
You should look up session management for the language you are using.
The traditional approach is that when a user logs on, your application generates a long, cryptographically random token called the "session id" and sets that into a cookie. It stores data like who is logged in on the server side identified by the random value, so when a logged on user comes back, the browser sends the cookie with the random session id and the application can look up session data on the server side. This way an attacker has no way to guess a valid session id for a logged on user, assuming the session id is cryptographically random and long enough (which more precisely means it has enough entropy). Logging out means deleting the session data on the server side, and also removing the cookie, but that is not the most important part - the session will be invalid anyway.
Note that you should not code this yourself. You did not mention the language and environment you are developing in, but session management is rather tricky business if you want to secure it, and it is already provided by most languages / frameworks.
Just for curiosity, the encryption approach you mention is by the way a valid one. Some frameworks actually do that, but you should not attempt to code that either, because it is very easy to get it wrong, lots of things need to be taken care of to make it secure enough. Unfortunately an answer here is not the right format to go into details I'm afraid.
Btw you mention looking at Google. They use their own single sign-on solution, it is very complex compared to simple session management, so it's probably not the best example for you to look at. Find simple websites, most of those work the traditional way.
Related
I read sessions and security questions on stackoverflow, and much beyond. I think I know the answer, but I want to confirm it with one concise simple question--security is too important.
Conjecture: My black hat web visitor does not have direct access to his $_SESSION contents.
that is, after my server executes
$_SESSION['myuserprivilege']='user' ;
I can assume that even the most clever blackhat cannot somehow find out even that my code did this, interrogate to what my php program set his server $_SESSION to (both keys and contents), or (much worse) engineer $_SESSION['myuserprivilege'] = 'admin'. only my own server php code can do so.
I still have to be concerned that a blackhat can steal the cookie of a different admin user ( => https and session rotation). but that's a different issue.
correct?
The values of the session are stored in your server, not in the user machine. So, no... No one can see or set that value without access to your server or any security problem in your code. It's like money in a safe, only who have access can get it or if the safe isn't secure enough.
And about cookie stealing, this is called session hijacking. It's common tecnique used to steal a session from another user. You can get more information here.
Basically if a person get the id of the session of a logged admin and the application doesn't have any approach to avoid this kind of situation, this person can have access to that user privileges.
Anyone can set a cookie in your website, but sessions has one thing called "PHP Session ID", so to get some value from a session, this person need to know a valid session id that have privileges to some part of application.
Session routation is not a problem, the chances to get some session from anyone that have this privileges is really, really hard. You also can use more characters in your session to make it more harder, but o don't think it's necessary.
Final answer: No one cannot set a session in our website, just who has access do the code and your server can do it.
I want to password protect a web page. I'm wondering if anyone would critique my approach.
An anonymous user would go to the page and a modal would open up asking the user to enter a password. I would of course not display any content at the back in case anyone decides to be clever and display:none; the modal.
Once the user enters the password, I would redirect and save a randomly generated token as a cookie and check for that so that user wouldn't have to keep entering the password.
Just wondering if there are any security issues here aside from a personal physically accessing the computer and also if there would be any improvements that could be made.
I know I'm still being a little vague on some details, so let me know if there's anything important that I left out in regards to exact implementation.
Even though what you describe might work, in general it's a bad idea to implement your own security. Even if you use https to prevent sniffing of the token, someone might find that your random numbers are not really random and be able to guess the next number.
You will be better off using one of the security feature that comes with the framework in which you are building your application. Most frameworks support something like forms-based authentication. It might even support claims-based authN with security tokens.
As you're not mentioning what framework you're using, I can't recommend anything.
It's a horrible idea. The password as a cookie would be transmitted in the clear in every HTTP request. There are plenty of examples of how to do this correctly. I am not going to elaborate because this question is very likely going to be flagged. NEVER save a password anywhere. The first thing to do with a submitted password is compute a hash value. The hash becomes the password.
I'm writing a GWT application where users login and interact with their profile. I understand that each form entry needs to be validated on the server, however, I am unsure about potential security issues once the user has logged in.
Let me explain. My application (the relevant parts) works as follows:
1 - user enters email/pass
2 - this info is sent back to the server, a DB is queried, passwords are checked (which are salted and hashed)
3. if the passwords match the profile associated w/ the email, this is considered success
Now I am unsure whether or not it is safe to pass the profile ID back to the client, which would then be used to query the DB for information relevant to the user to be displayed on the profile page.
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
-Nick
What you are dealing with here is a session management issue. Ideally, you want a way to keep track of logged in users (using random values as the session key), know how long they have been idle, be able to extend sessions as the user is using the site, and expire sessions.
Simply passing the profile ID to the client, and relying on it to send it back for each request is not sufficient - you are correct with your concern.
You want to keep a list of sessions with expiration times in a database. Every time an action is executed that needs user permissions (which should be pretty much everything), check to see if the session is still valid, if it is, extend it by however long you want. If it is expired, kill the session completely and log the user out.
You can store your session keys in a cookie (you have to trust the client at some point), but make sure they are non-deterministic and have a very large keyspace so it cannot be brute forced to get a valid session.
Since you're logging a user in, you must be using a backend that supports sessions (PHP, .Net, JAVA, etc), as Stefan H. said. That means that you shouldn't keep any ids on your client side, since a simple id substitution might grant me full access to another user's account (depending on what functionality you expose on your client, of course).
Any server request to get sensitive info (or for any admin actions) for the logged in user should look something like getMyCreditCard(), setMyCreditCard(), etc (note that no unique ids are passed in).
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
Stefan H is correct that you can solve this via session management if your session keys are unguessable and unfixable.
Another way to solve it is to use crypto-primitives to prevent tampering with the ID.
For example, you can store a private key on your server and use it to sign the profile ID. On subsequent requests, your server can trust the profile ID if it passes the signature check.
Rule 1 - Avoid cooking up your own security solution and use existing tested approaches.
Rule 2 - If your server side is java then you should be thinking along the lines of jsessionid. Spring Security will give you a good starting point to manage session ids with additional security features. There will be similar existing frameworks across php too (i did not see server side language tags in the question).
Rule 3 - With GWT you come across javascript based security issues with Google Team documents and suggests XSRF and XSS security prevention steps. Reference - https://developers.google.com/web-toolkit/articles/security_for_gwt_applications
So lets say i have a member base website and when the user signs in i put put a cookie (or a session) with a key value pair remembering who the user is. But its just come to my attention which information i should use to remember the user so that its secure. I cant use username=username or user_id = user_id (because my user_id will be 1), because people then can just simply guess what the cookie values are and logged in as that user. So what key/value pair should i use to be able to identify users and still connect their information to the database securely? Thanks.
Ben, there are a few different types of attacks you need to be concerned with. For example simply encrypting the identifier with a private key doesn't prevent someone who can intercept the encrypted value from simply replaying it to your server (and appear to be the user). Some common security risks are detailed here (and in associated links at bottom of this page):
https://www.owasp.org/index.php/Session_hijacking_attack
Session management can be quite complex and depending on the level of security you require, it is not something you want to tackle yourself, because likely your development environment / framework already has a solution that has been vetted moreso than a homebrew solution. Here is a link detailing some things to consider, unfortunately this topic has more to it than a simple Stack Overflow post:
https://www.owasp.org/index.php/Session_Management
If you dont prefer encryption for whatever reason, then a simpler solution could be to use a GUID to identify the user. This way, a hacker would have to launch a denial of service kind-of attack on your application to be able to run through even a very small fraction of the GUIDs.
If you want to do this properly, then you should have a look at http://jaspan.com/improved_persistent_login_cookie_best_practice also.
I'm definitely not an expert in security, but I have recently implemented user management tool and I have done the following.
Don't use encryption, its slow and most of the time for simple implementation its just a waste of time.
Here is what you do need to store on the server - in order to authenticate each request.
UserId (obvious)
CookieHash (made out of userId, some secret private key and crypto randomly generated number)
LastLogin
SessionRenewed (useful for when to cancel someone's session eg. renew cookieHash every 10 min, otherwise log out user)
LastIP
What I store in cookie is following
UserId
CookieHash
How to use this basic security
Simply when user logs in you check username/password etc. (just the usual) If everything is fine then log in user and generate new cookiehash and fill those values given above.
Every request check UserId against its hash. If someone gave UserId = 4 but hash didnt match then automatically drop a session and forward user to login screen. Possible log is good to see how often people try to play around with your hard work.
I hope this helps.
You can just encrypt the user id with a private encryption key that you keep on the server. There are a few things to watch out for with this approach:
Every call to the server will require you to decrypt the cookie to get the id of the user. This will add overhead to each request.
If the key is ever compromised, you will be forced to abandon the current name for the cookie you use and use another encryption key when assigning to the new cookie name; this will cause the user to have to re-login, of course.
While I don't think that these are major hurdles, they might be to you, and you would have to evaluate the impact on your site for yourself.
Most web sites you can log on to also provide the feature so it remembers you between sessions.
What's the accepted and secure techniques for implementing that ? (What do you put in the cookies and how do you handle it on the server/db?)
This recent 2009 chapter in Spring Security 3.0 discusses Remember-Me type authentication. The general concepts are not specific to Spring Security so you should be able to benefit from it even if you are not using it. The chapter also cites a Barry Jaspan's 2006 blog posting which is an improvement over the techniques described in Charles Miller's 2004 blog posting.
The blog entry basically comes down to:
When the user successfully logs in with Remember Me checked, a login cookie is issued in addition to the standard session management cookie.
The login cookie contains the user's username, a series identifier, and a token. The series and token are unguessable random numbers from a suitably large space. All three are stored together in a database table.
When a non-logged-in user visits the site and presents a login cookie, the username, series, and token are looked up in the database.
If the triplet is present, the user is considered authenticated. The used token is removed from the database. A new token is generated, stored in database with the username and the same series identifier, and a new login cookie containing all three is issued to the user.
If the username and series are present but the token does not match, a theft is assumed. The user receives a strongly worded warning and all of the user's remembered sessions are deleted.
If the username and series are not present, the login cookie is ignored.
Signed cookies that can not be tampered with can be a good idea when you don't require a whole server-side state ... lean mean and efficient.
You still run the risk of cookie theft but you can always sign the cookie using IP address, User-agent and other things to help minimize the threat.
It's just a cookie with a long life value assigned. However it will only work so long as the cookie exists. For example, I have my Firefox set to clear my cookies when I close the browser. So this wouldn't work for me.
Cookies, but the user can decide to delete it.
In the same spirit there is some kind of solution, using Flash. Flash can store informations on the client-side, not a cookie, it's not erased (usually) by the browser. With it, you can remeber which user is asking for pages, but you're stuck using a plugin-using solution, and need to know Flash..
I don't see any other solutions.
Do not try to implement session cookies yourself.
Most web frameworks give you an abstraction over this, leaving you care-free about the many security issues you might be exposing yourself to.
A simple API in pseudo-code in a web framework might look something like this, on login:
authFrwk.loginUser(request.POST.get(username), request.POST.get(password));
This will return a cookie to the client (handled exclusively by the framework).
A securely authorized operation will look something like this:
if (authFrwk.isLoggedOn()) // implicitly checks user session cookie
doSomethingImportant();
else
return notLoggedInMsg();
Basically, a session cookie is given a unique ID on the server-side, which a malacious user cannot generate/guess by himself, and which identifies the client as a logged-on user.