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.
Related
I have a quite simple question, which I'm asking because I'm unsure of the answer. I'm building an application where there is a multistep registration form. There are 7 steps and each one is on a different PHP page. I'm also validating the submitted form data once the client goes to the next page.
My questions is:
Is it secure to store all the Validated(only the validated) information in a Session variable and when they've finished with the registration, I'd write those session values into the Database. Is it secure to use sessions for this purpose? If not, how can this method be exploited?
I am also providing the option for people to go back to each step and change the values if they've mistyped something. In this case I would update the Session variables only. Is it safe too?
I'm currently using session_regenerate_id() to prevent Session stealing.
So basically will I be safe to store the data in Sessions temporarily, and then insert them to the database? Can a hacker change that Session data in the meantime, so what I'll insert into the DB will not be the same what I've saved into the session?
I hope you understand my question. Any help would be appriciated!
Yes, it is secure. Session data is stored on the server side, and cannot be manipulated by the client. The only thing the client holds is a session key, which allows the server to match a client up with the stored session vars for that client. As long as you're validating the information before storing them into $_SESSION, you can dump the session variables into the database at the end of the process.
Here is more information on sessions and security. The simple solution to any concerns with session stealing is to just use SSL.
I am also providing the option for people to go back to each step and change the values if they've mistyped something. In this case I would update the Session variables only. Is it safe too?
You will also be fine with this approach, again as long as you're re-validating the session variables.
if you protecting session ids for session stealing then go ahead, sessions are safe variables stored in server-side , every client has own session so if you sure to keep safe your session ids then no problem
Currently a friend of mine and myself are working on a site together. We have our login system down, but are using sessions. I, myself, have always used cookies for logins, though my friend prefers sessions.
I keep telling him we should have two or more sessions we can compare with the database to make sure it's the accurate user, and not someone who somehow scammed the ID.
For example:
$_SESSION['id'] = $YourId;
$_SESSION['salt'] = $SomethingElseTheDatabaseHas;
This making it more secure instead of just one session that the database can compare with.
Using multiple session variable to store information does nothing for security since the session data is stored server-side. The only thing that the client knows about the session is the session ID that it stores in a cookie. The server uses the session id to lookup data for the user. If you're using a hash stored in a cookie to identify users, you might as well use sessions since that basically does the same thing, but makes working with a user's data much easier.
I'm not sure exactly what you mean by using cookies to store the data, but if you mean that the client would have a cookie with their user id that the server uses for authentication, you should rewrite that immediately since it basically allows the user to be whomever they want.
Heyo,
Odd question... is it possible/ ok. To use a combination of SESSION variables and COOKIE variables... in PHP?
I know SESSIONS are stored server side and COOKIES client side...
Is there any chance of interference? What is the best practise?
Christopher
Actually, sessions are a combination between sessions and cookies since the session ID is stored in a cookie client side. You are free to do pretty much what ever you want with both as long as you remember:
Cookies are stored on the client computer. A savvy user has absolutely full control of the contents of a cookie, so don't make assumptions about it's content
Session variables are stored in memory on your server, so keep in mind the amount of data you hold for each visitor
PHP's documentation on sessions
You can mix them. By default, the session cookie is set to PHPSESSID that contains the unique session identifier used to associate the client to the session data on the server. As long as you don't interfere with this cookie, it is okay.
In terms of interference it is like just any other two arrays in PHP.
There are some specific issues with each you need to know, like at what phase you can assign variables to each of them etc.
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
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.