this is crossing my mind and I'm wondering if it is possible, how secure can it be to store info in the $_SESSION variable of PHP?
Storing variables in the $_SESSION variable has two potentials for "insecurity".
The first as described by the other answer is called "session fixation". The idea here is that since the session ID is stored in a cookie, the ID can be changed to that of another user's. This is not a problem if a user gets a new ID every single session therefore making it very difficult to find an ID of a currently working session and hijack it.
The second depends entirely on your code. If your code leaks the values of the secret information you store in $_SESSION then it is insecure. If your code allows the user to control the values of that information it is insecure. Otherwise if something is in the $_SESSION variable and your code never allows the user to see it or write to it then it is secure.
PHP Session's work by storing a PHPSESSID cookie on the end user's computer that acts as an access key for server-based session information. That cookie value is a hashed string (the security of which depends on your PHP settings) that is used to link the particular browser to the specific session values you set.
That string looks something like b420803490a9f0fe8d6a80657fec3160. So, the end user could alter that string, but then their session will become invalid, since it almost certainly won't match one that's being stored by PHP, and they won't have access to data.
There is a risk, as others have mentioned, that someone's PHPSESSID become exposed, and people use that to hijack someone else's session.
The $_SESSION is stored entirely on the server, so the user cannot modify it. However, it is possible for session-hijacking exploits where the user gets connected to another user's session.
Where as less secure $_COOKIES are on the client computer, the $_SESSION is stored on the server. It's location is determined by the session.save_path of php.ini. However there are still security issues such as session fixation
Related
I am using PHP $_SESSION variables with the login workflow of my website and I just wanted to make some clarifications. Much like Facebook, I want to store a secret code only known by the server which is used to sign each request that is sent to and from the server. My initial approach was to generate a random string and store that inside of a MySQL table, but then I learned about session variables. I know that session variables by default work by using cookies that store session names and id, correct? None of the actual data is stored on the user's computer? So if I wanted to implement:
# assume that $rand_string is not null and a string
session_start();
$_SESSION['secret'] = $rand_string;
there would not be any way for the user to decode the session cookies and determine the actual value of $rand_string, right? Just want to make sure the data is secure, otherwise I will revert back to the less smooth MySQL technique. I just like the thought of the easily accessed and managed session variables.
Session data is stored server-side.
Cookie data is stored client-side.
I would prefer doing the random stuff by generating a guid` function, because it will generate a unique identifier and will be more secure than a simple random:
# assume that $rand_string is not null and a string
session_start();
$_SESSION['secret'] = com_create_guid();
And yes, $_SESSION variables are stored on server side.
Yes, you are right, the user only knows about the session ID or something similar, just something to identify the session the user corresponds to.
The rest of the data is temporarily stored on the server.
There is no way for the visitor to get hands on the session data unless you have major bugs on your website which i don´t think you do.
What you say is correct. All data inside $_SESSION is accessible only on the server, but only as long as the session has not timed out.
Nonetheless you should be careful that session IDs which are stored in the cookie can be captured quite easily. See Sessions and Security for details.
I know about all the issues with session fixation and hijacking. My question is really basic: I want to create an authentication system with PHP. For that, after the login, I would just store the user id in the session.
But: I've seen some people do weird things like generating a GUID for each user and session and storing that instead of just the user id in the session. Why?
The content of a session cannot be obtained by a client - or can it?
You're correct. The client just sees a randomly generated session id token. There are ways this token can be misused (hijacked, etc.), but having a GUID on top adds nothing. In contrast, options like session.cookie_httponly (JavaScript can't see session cookie) session.cookie_secure (Cookie can only be transmitted over HTTPS) protect against certain attack scenarios.
The short answer is that $_SESSION is safe and you do not need to worry about its contents being leaked to a user or attacker.
The content of the session is not normally be accessible to the user. You should be able to store the user's primary key and you'll be fine. There are cases where the session can be leaked, on a normal linux system the session folder is in /tmp, however this could be changed in your php.ini to the web root (/var/www/tmp) and then could be accessible. The only other way is if the user is able to get access to the $_SESSION super global by hijacking a call to eval() or by the variable being printed normally.
If you are running on a shared host and using an old version of PHP and/or your server is misconfigured it might be possible for another user on this system to read or even modify a session file stored in /tmp/. I don't know of a single application that takes this attack into consideration. If this is a problem you can store the information in a session table in the database.
Sometimes, for added security, developers may assign a long string to the user's session in order to make hijacking even more difficult. By setting a cookie with this new string at the time of session creation, the app can check for the correct string on subsequent requests to better ensure it is the person who actually logged in.
It's just adding one more thing a wannabe hijacker would have to guess. However, it can be a false sense of security as it does little to protect the session if sniffing is involved because the new cookie is sent right along with the php session cookie. Also, session id's are very hard to guess as it is (as I'm sure you know, just don't place it in the url but, rather, in the cookie).
Session info is stored on the harddrive so it's not obtainable by clients without application intervention.
I've never seen GUIDs being used for sessions, but there are a couple of additional methods I have seen that do add a little more security.
Storing the user's IP - if you need to force a session change based on locations (sometimes geoIP stuff will do this)
Storing the user's HTTP_USER_AGENT header string. Can provide a bit of security against hijacking if the hijacker happens to be using a different browser.
There's a great article on session hijacking countermeasures on Wikipedia, actually.
That being said, I would imagine that anyone storing a GUID as part of a session to use in session security might be failing to see a better solution (such as session regeneration). I can see other uses for a GUID to be stored (maybe it's part of a random generator for a game), but not for use with session security.
IN PHP:
Is there a way for the user to fake a session variable?
Is it secure to trust in the value of a session variable for a login system?
The session data is stored on the server. Only the session id is transferred forth and back between the client and the server. Unless a server-side script messes up (or there is a bug) the client cannot change the session data directly. But you have to ensure that only the "correct" client knows the session id, as it ties this particular client to a particular session. E.g. (since you mentioned a login) use session_regenerate_id() whenever a login (attempt) is performed to prevent session fixation
Sessions are stored on your server, either in a file or in memory. The user only holds a cookie that defines the path (usually a hash of some form) to the session data on your server. Theoretically you could change the cookie to someone else's hash, but that is very, very improbable, unless you store them as files and don't delete them after they expire, in which case the probability of someone exploiting an old session would increase.
Yes.. It's called session forge/hijack.
You change the value of the session cookie until you get another user session.
To avoid storing session data in the server, you can sign the content you want to protect from change, before storing it on session, and then validate just after retrieval from session. In PHP this process is reasonable simple and eliminates server storage issues.
Notice that this does not protect session data from being visualized. If you need this protection, you can still avoid server storage by using safe encryption. Just beware that virtually every encryption scheme based on key size can be broken on near future. So if you need to protect your session data for say, 5 years, the secure choice of key and algorithm might create performance issues.
ive heard a few timse that sessions need to be cleaned with mysql_real_escape_string or htmlspecial chars because they can be modified. what im wondering is how are they modified because when i look at a websites session named PHPSESSID the value it contains is always encrypted.
first of all what encryption method is it using and how is it modified. the reason i want to know this is to better understand how to secure myself based on what methods people are using out there to high-jack sessions
thanks.
They cannot be modified, they're stored on the server. The PHPSESSID is just an identifier, it's not encrypted but randomly generated (so it's unique to each user). People hijack sessions by stealing the PHPSESSID cookie, usually through a cross site scripting attack. Read the answer to this for a nice summary of sessions in php - What do i need to store in the php session when user logged in
Sessions are stored on the server. That means all data is stored in temporary files and are deleted after an x amount of time. The browser does not store session data. It stores an ID of the session, which the server uses to get the right temporary file.
So the user never actually has access to variables stored in a session. But has a reference to their session. It is possible to get someone else's session ID. This way you can pretend to be another user. If sessions are used for validation.
Read up on session hijacking here.
The thing that can get modified is the session id send to you by the client. So, as with all user supplied data, this needs to be 'cleaned' before you use it anywhere, like for example with mysql_real_escape_string before inserting it into a MySQL database.
I'm working on a website and want to create user login and session. What is the safest way to check if session exists or not (like cookie or session variable check), or any better idea then using sessions in php?
session_id() returns the session id for the current session or the empty string ("") if there is no current session (no current session id exists).
http://de.php.net/manual/en/function.session-id.php
but that just tells you if a session is active or not.
most of the time, i just call session_start(); at the beginning of every script (even if the user's not logged in). on login, i set $_SESSION['user'] with the userid or an user object. on logout, i just unset($_SESSION['user']);. by checking empty($_SESSION['user']) i can check if someone's still logged in or not. don't do this if you're storing user-dependant information elsewhere in your session, otherwise the next guy logging in may get info he's not supposed to see (in this case use session_destroy();).
but safety? just deactivate session-id propagation by GET/POST url rewrites (cookies only), so they don't end up in URLs that can be cached or distributed to others (in this case, session hijacking would be possible). you can do that by setting session.use_only_cookies in the php.ini.
there may be additional safety issues if you're hosting on an untrusted and/or misconfigured shared server - it could lead to other people on the same machine reading your session data. in this case you could store your session data in a database by rewriting your session handler. just search for session handler mysql on the intertubes, i'm sure there are enough ready-to-go solutions. and don't store sensitive information like passwords in the session, better do a query everytime you need to compare it.
other than that ... use ssl/https for login and user management, so no plaintext passwords are transfered. store only pw-hashes with salt in the database. don't let anybody see the passwords (meaning: never print them to html or emails). don't use auto_increment values for ids the user can see (and therefore, guess). ok, that's already out of the questions scope.
Here's some tutorials on Session Safety
PHP Security Guide: Sessions
Notes on PHP Session Security
PHP Session Security - php|works 2004 (old but still interesting)
PHP Session Security (PDF)