I'm using (server side, not cookie) sessions in an application that I writing, if the users has not obtained access to the server can I trust the $_SESSION variable or should I verify it's content on every page load?
Note:
I'm trying to limit the number of queries to my database and currently I am verifying the data on every page load, and I', thinking that I can probably eliminate the queries, but I want to be 100% sure.
Yes you can store it in the session safely. You should make sure that the Validation method is safe. (the method you use before storing in the session).
You just need to make sure that session is stored in safe place. By default sessions are stored on somewhere like /tmp/ on linux. If user can access your server they can edit the session variables.
You should consider saving sessions to database, and/or adding hash calculation (md5+secret seed) verification to sessions, and always check that session variables are not modified against that hash.
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
Why is it recommended to store CodeIgniter sessions in a database table? I know it's about security but how?
why is it required to set an encryption key in the config when using the Session class?
Are you supposed to decrypt the session?
Does $this->session->sess_destroy(); delete the entire cookie or just the data you put in the cookie? And does it end the session completely, by which I mean undoing
$this->load->library('session')?
CI's sessions are, actually, cookies. Encrypted, but cookies nonethelesss. That's why is preferrable to store session in a database, because you're (supposedly) dealing with a less unreachable target from attacks, especially if you use Active Records wich automatically escapes your queries (so that SQL injections are avoided).
Also, contrary to cookies, DB doens't have such limited amount of memory available, so you can store any amount of data you want there, cache the operations, and have them hidden from the frontend.
I'm not sure about why it is required, apart from the fact that some sessions datas are automatically encrypted by CI. So, even if you don't make use of the Encryption library, some encrypting is still caried one (while saving session ID, for example.). As Kai Qing correctly noted, you don't have to do any decryption on datas already handled by CI.
$this->session->sess_destroy() just deletes the data stored as sessions. While being also cookies, in order to delete the whole content you need to use the dedicated functions (look into the cookie helper, for example). Keep in mind, though, that when you call this function you delete also flash messages (as they are sessions), so if you just want to unset some elements, use unset_userdata($item).
It doesnt end the library loading, also. As for any other library, or class, or controller, or whatever, everything is re-loaded from zero after each request. Each time you make a request the scripts runs, reinitializes everything, and when the script ends all is lost like tears in the rain. That's the regular lifespan of a php script. If your script is not bound to end after you call the session->sess_destroy(), the session library will be still loaded, though the data will be erased.
To answer your first question - It is recommended to store via DB to minimize the data found in the session and reduce the risk of foolishness - like a helper. Since DB stored sessions will only store the id in a cookie, the information available is reduced to an unusable bit of information.
You don't need to decrypt anything. The engine handles that for you.
as for destroy - I don't know exactly. But I imagine a simple var_dump would answer that.
I'm bit confused. I've been building my sites with my own session system, but i'm not sure how secure the php's own session system is. My session system usually just has user id and quite harsh hash, which does not include user name or password for generation. I save the hash in the user database and as a cookie to confirm the user session on every page load. So my question is can i trust php sessions or keep using my own?
PHP saves a unique session id in a cookie, and all values related to the session in it's own text file on the server. You have to get the session id to steal the session, which means you have to steal the session cookie from the victim's computer. PHP's own system is at least as safe as your homebuilt system
The difference may be how hard it is to find an active session by brute force. That is entirely up to the hashing algorithm and the random number generator.
You can configure PHP to use different hashing algorithms or you could even use your own algorithm to create the session ids for PHP's session system if you don't trust PHP to do it properly.
Storing data in cookies versus using PHP's sessions is very different. Cookies store data on the client-side; sessions store data server-side, which has a number of benefits:
The user can't see it
The user can't modify it
The browser doesn't need to send the data to the server with every request
Normally PHP sessions do store the session key as a cookie (although they don't have to), but none of the data you actually care about is ever sent to the user, it's stored on the server and looked up using the session key
i'm not sure how secure the php's own session system is
And the rest of the world is not sure how secure your's is. A lot of people have looked at the session handler in PHP and not found any flaws in implementation. Its also well characterizied and integrated but supports the notion of user defined handlers.
I'd recommend using the standard session code - but you might want to write your own handler functions.
C.
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.