I'm new to PHP, I've read a lot of tutorials about cookies and sessions but I don't understand some things clearly:
The session values are stored on the server, only the session id is stored in the users computer. Right?
Can I make a session that never expires, that is never deleted from the server and to save the session id in a cookie ? If yes than how ? (please provide me some code)
It`s not good to store data like passwords in cookies because cookies are not secure ? Right ?
It`s possible for a hacker to create a cookie with a session id of an another user ? Can a hacker guess the session id of a session or worst, the list with each session id ?
For a good login system (used for forums or websites where the user have some data) that can remember an user is better to use cookies, sessions or a combination of both with session id stored in cookies ?
Please provide me some code about how could I store the session id in a cookie and than how I can access a session if I know the session id
Thanks!
Let's see...
right
session that never expires ? Not quite a good idea :
your served would get filled with old, useless, sessions
Instead, you should store some data in a long-lasting cookie ; and use that cookie to re-create the session (auto-connecting the user, for example) when the user comes back later
cookies are not secure indeed : they are stored unencrypted, and go through the network unencrypted (unless you use HTTS).
If your hacker can get the session id of another user (by reading his cookies, typically), yes, he can access his session
I would use both : anyway, if using a session, you need a way to store its identifier.
storing the session id in a cookie ? PHP will do that for you, if configured properly ;-)
Yes, PHP sessions are stored on the server.
You don't want to do that. It's a waste of disk space.
No, it's not good because cookies are stored unencrypted and in plaintext and you should never send a plaintext password back to the user.
If he knows the session id then he might be able to take over a session (tieing sessions to the user's IP helps against that). That's one of the resons why XSS is a dangerous thing.
Use a session and store the userid in it. There's no need to use a separate cookie if you already have the sessionid cookie.
Use session_set_cookie_params() if you want to change the session cookie settings; e.g. to make it permanent.
Related
Hi I have a security related question I allow users to login and register my question is when a user logs in my script just sets the session no cookies so is it safe to only rely on sessions not on cookies? or I use both the cookies and sessions?
PHP sessions use cookies to track the ID of the session. Thus, it is safe, because you actually are using cookies.
It's worth noting that you should try to prevent session-hijacking - you can do this by validating the IP of the user among other things in your $_SESSION object.
Edit
I suggest you read this. Quote:
The session_start( ) function generates a random Session Id and stores
it in a cookie on the user's computer (this is the only session
information that is actually stored on the client side.) The default
name for the cookie is PHPSESSID, although this can be changed in the
PHP configuration files on the server (most hosting companies will
leave it alone, however.) To reference the session Id in you PHP
code, you would therefore reference the variable $PHPSESSID (it's a
cookie name; remember that from Cookies?)
Note: stores it in a cookie
When a user logs into my site it creates 2 cookies, one with a session ID (that relates to the user ID on the backend) and a remember me cookie that lasts for 3 months.
The remember me cookie is constructed as:
userid:timeout:hash
Where the hash is a HMAC SHA256 hash of userid:timeout to prevent tampering.
If the session ID does not exist (user closes their browser and opens it again so the cookie is gone, or the session ID does not exist in memcached) it looks at the remember cookie and re-generates a new session cookie, providing it has not timed out and the hash is correct.
However I don't see the point of having a session cookie at all, as the session ID just points to a user ID in the backend. I can use the remember me cookie instead to retrieve the current user.
So I am thinking of scrapping the session cookie completely, and would be interested in hearing some thoughts on this. Does this approach sound relatively secure? Could I make it any better?
Thanks in advance!
Yes, it is indeed secure enough for most cases, but why including user specific data in the cookie when you can avoid it? Also, there's a small disadvantage with this:
What happens if an user manages to steal a cookie from another user, you'd have to change the whole way the cookies are generated or that user will always have access, therefore resetting everyone's cookies. Imagine now that it's your cookie that gets stolen...
This is my solution for that: create another row in the user table called 'userhash'. When an user logs in, you generate a random hash without taking any of his input, just random, and store it both in the table and in the cookie. Then you only have to store userhash:timeout in the cookie. You check that against the database to see if it exists, if it does, that's your user. When the user logs out, the cookie and the row in the database gets deleted. For obvious reasons, you'd have to check that the cookie exists before comparing (there will be many empty).
Note: This method would only allow one registered cookie at once, so no laptop + desktop. This is good, since stealing is made more difficult as it only lasts as long as the real user doesn't log in, and bad because it only allows 1 computer. But you see the idea and how you could use this method but having several computers logged in... facebook-like.
PD, it'd be nice if you said how secure your app must be actually...
PD2, in case you haven't think about it yet, there are other more serious security concerns (SSL to say one).
I am trying to understand security when it comes to session cookies in php. I've been reading a lot about it, but I still lack the specifics. I need the basics, someone to show examples.
For example: Do I place session_regenerate_id() before every session cookie? What more shall I think about. I am asking about specifics in code - examples if possible.
Thank you very much.
I am using 4 session cookies after logging in.
SESSION "site_logged_in" = true
SESSION "site_user_nr" = the number of the user to access user_table_nr
SESSION "site_user_id" = the user's id to use when changing data in tables
SESSION "site_user_name" = the name of the user to display on page
When I check if the user has access, I check if all 4 cookies are set, and if site_logged_in is set to true.
Are there better ways? Do I have the completely wrong idea about this? Can users easily be hacked?
In fact you need to have only one session in your website. When you call session_start() session is being created on server and user automatically gets session cookie. Think like session is a some sort of container that placed on the server, you can put whatever you want in that container. However session cookie is just a key to access that container on the server.
It means that you can safely put some data in the $_SESSION and only the user that have cookie with matching session id can read it.
About users being hacked. Yes they can be hacked as long as you don't use HTTPS connection, because cookies and all other data is being transferred in clear text, so if someone intercept users cookie he can access the data stored in the session.
Always use a security token for logging users. This security token could be generated by using crypt(). After logging users in, change the security token periodically until they log out. Also keep the server backup of all the session variables including the security token (in a database). This would also help you to track user login history.
One more personal suggestion: Never use any data from the database as session variables without encrypting it with any of the hashing functions or functions like crypt().
The session information is stored server-side. What you should check is that they're logged in, and that they exists/can log in (in case of deletions/bans).
As you're checking they exist/can log in, you can pull the other information from the database such as name, nr and so on. All you really need is a key called 'logged_in_user' or something that stores the ID of the logged in user. As Alex Amiryan said, the cookie can be copied, so you might also want to store the IP address of the last accessing view in the session, so you can try to ensure security.
I have created a registration/login system for my members area. Once the user has logged in I want to store a session variable that I can use to retrieve data associated to the user from the database.
Should I in encrypt the variable in any way? The data I want as a variable will either be the username or the id, which is best?
Should session ids be regenerated in anyway and when??
Data storage in session is considered to be "safe", so you dont need encrypt-decrypt it.
You should regenerate your session id after a successful login/logout. For security reasons, I would reccomend to ask the user for his password if he want's to perform a critical action (changing important data, deleting account or submit an order for example).
As AurimasL stated, you don't have to worry about session data on the server side. I reccomend this reading, if you are on a shared host, because then there are some security aspects: http://phpsec.org/projects/guide/5.html
Session IDs are stored like a cookie on the client's machine, and are passed back to the server for every single request. This is how PHP determines what information to load into a session once it receives the request.
Since sessions live on the server and not on the client, you only need to worry about session hijacking in regards to whether the information stored in them is secure or not. The answer to your question is no, I would not try to encrypt the information that is stored in session.
Just an add in the comments bellow,
Keep in mind that creating a sessions are expensive for your server app. Sometimes is a good idea stores the id in the session and other informations in cookies (informations that dont need security as the username).
I save some important info in $_SESSION, not in $_COOKIE. So, my question, is it dangerous? Or is it protected from malicious users trying to edit it and I'm fine?
Thank you.
By the way, is it possible also to edit $_COOKIE? I heard yes, but if yes, then how?
$_SESSION is stored server-side. The best a hacker could do would be substitute another user's session for the existing session, but the hacker could not insert arbitrary data into $_SESSION. $_COOKIE is, however, stored client-side, so a hacker can insert arbitrary data into the cookie, by just editing the cookie.
By default, the $_SESSION is already backed by a cookie with the name phpsessionid (so that the server is able to identify the client and associate it with one of the sessions in server's memory). If a hacker knows the cookie value of someone else and copies it in its own cookie with the same name on the same domain/path, then the hacker has access to the same $_SESSION. The cookie value is however long and random enough to minimize the risks the session being hijacked within half a hour (the default session timeout).
If you're worried about people altering sessions (session hijacking) look into session_regenerate_id()
$_SESSION is stored on your webserver, so it's not possible to directly alter it via the web. Of course, your PHP application can update $_SESSION, so it still might be possible for an attacker to trick your application into doing something to $_SESSION that it shouldn't - it all depends on the specifics of your application.
$_COOKIE is stored on the user's browser, which means that the user has the power to change their own cookies.
One of the main uses for cookies is authentication. A user logs in and information is stored in $_SESSION. A cookie (stored in $_COOKIE) records the session id of the user so that your application knows which session belongs to the logged-in user.
Yes Hacker can hijack the session you can use session_regenerate_id() , or stole it
look
if you are admin and you logged in ,( session is in the server )
hacker have it via xss = > will make cookie in his pc with this session and log , change the pass or add admin , besore the end of the session
cookie can stole too ,
look this code
setcookie("admin","admin_log",time()+3600);
if hacker know the code like opensource he can log as
make cookie by firefox addons as the cookie name and value
Cookies are sent via the user-agent every time a page is requested. The user-agent doesn't need to be a browser. It could be a small shell script. Even if it is a browser, there's an "edit cookie" extension for Firefox.
$_COOKIE contains information that the client sent to your web server. Most commonly this is the contents of browser cookies but t could contain ANYTHING, so don't trust it.