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.
Related
I successfully use mycrypt to encrypt id's in an admin panel as they are often seen in the URL. I have previously added a key manually as I code, but this time I plan to use the users account id which is kept in a session. Is this a good way, or should I keep with a fixed key throughout the site.
Thanks
Never pass SESSION IDs over URLs, even if encrypted (though it's weird and still quite unsafe). Transferring SESSION IDs has been deprecated long time ago by PHP (session.use_trans_id=0). Session ID is transferred automatically by browser, you don't need to take care of it at all.
The only use case might be if you want forcibly allow browsers with disabled cookies, then you would need to append such a parameter to all links (mimicking deprecated bahaviour). However:
it would be still great security risk, since mostly attackers and malicious webbots disable cookies,
encrypting in any ways makes no sense coz string can be still hijacked and server will decrypt into original session ID
So you just pull out userID stored in session and don't worry about transferring session ID over URL.
Lately I have stumbled upon some articles that suggest using a cookie to store session data.
I liked the idea and extended my session storage by adding a CookieStorage class which works fine (note that per user I use a unique hash key for sigining and encrypting data)
However, there are a lot of other articles that suggest against storing sensitive data in a cookie, even though you encrypt and sign the value.
Personally, I find no reason why not do it especially when encrypting and signing the value with a different key for each user. The risk of the data being compromised is the same as with normal sessions, no? Not to mention that if you use SSL then the risk for hijacking is eleiminated.
What I see as a benefit with such an approach, if the session data are not large, is fewer IO operations on the server for opening/reading/writing session data, whether the storage is file, db, memory based
I would appreciate your feedback on the matter
Thanks
If you're using pure cookie storage with no server-side component at all, then the user is in control of the data. The only thing keeping him from it is your encryption/signing method; but that can be attacked. If you're not using encryption/signing keys specific to the user's session (i.e. you're not using a server-side session), then you're pretty much limited to a static secret. Someone could attack that offline, trying to brute force it. Once they did, they could spoof their entire session.
If you are using more secure one-time random secrets stored in a server-side session... you're already storing data in a server-side session! Why not keep it simple and store everything there? It would also reduce the bandwidth needs required to transfer all the cookies back and forth with every single request.
If you're doing this mainly to save I/O operations on the server: use a more efficient session store like a memcache based store.
Although nowadays session id transferred only via cookies, initially there was other ways, which are still supported and can be used.
Sometimes server needs to know or alter the session info.
That point from #CBroe on the cookie size.
I currently use PHP sessions (without database saving) to identify users on a small website. However, I would like to make it more secure by saving session data to a MySQL database along with using a cookie with PHP.
I'm thinking of having a PHP script which I will include on every page which will:
Try to validate a session based on a database entry
Create a session if needed
Set special session variables I might need
Is this the best way to go about things? Am I missing anything in my script?
Session automatically try to use cookies for session ID.
The common practice is to store everything important into $_SESSION on login (and check only for privileges change).
If you want to make it more secure you may store $_SERVER['REMOTE_ADDR'] and $_SERVER['USER_AGENT'] into session and check them on each request.
The last thing I can think of right now is checking 'life time of session' manually.
Anyway I think that using https instead of http would bring you much more safety than reinventing sessions.
Storing each request/session into DB would make sense only if you needed to have special handling for parallel request.
That's a pretty big question. You want to do a bit of research on learning the tools I'll provide you for the job. I cannot write every detail about them here, but I'll try to get you pointed in the right direction.
check the user cookie to see if they have your session id variable set. if it isn't, start them a new session and offer a login perhaps.
if they have the cookie, check if it is a valid session id
if it is, load that session.
You'll need tools like setcookie, session_id(), $_SESSION, $_COOKIE. Making a users table is a whole other topic really.
I work with MVC's all the time that do just exactly what your referring to. Its a real piece of junk setting it up that way, but it can be useful in certain situations.
But the most important thing you should know is that when combining the login to an active session, it won't really make it more secure unless you use 2 session identifiers. is this what you want to do?
This would also be useful if you wanted to track where users log-in from. Gook luck!
Is it slower to retrieve a user's cookie and get its value as a PHP variable, than it is to retrieve a session variable?
In general, you should not worry about the retrieval speed of a session variable or a cookie.
You should however be aware of the differences between them:
Sessions are stored on the server, which means clients do not have access to the information you store about them. Session data, being stored on your server, does not need to be transmitted in full with each page; clients just need to send an ID and the data is loaded from the server.
On the other hand, Cookies are stored on the client. They can be made durable for a long time and would allow you to work more smoothly when you have a cluster of web servers. However unlike Sessions, data stored in Cookies is transmitted in full with each page request.
No. In pure technical terms, it is likely the opposite, as there would be a bit of minor overhead to initializing a session.
Cookie data comes in as part of the HTTP request no matter what, and PHP reads it into $_COOKIE by default. So it's always going to be there. $_SESSION requires you to call session_start() at some point.
However, the performance difference between the two is going to be ridiculously small and not worth worrying about.
A session is by default 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), so your concern actually makes no sense.
It's only easier to make use of $_SESSION instead of reinventing it with a "custom cookie".
I would believe it would be about the same except the session would be coming from disk. Also the session is coming from the cookies anyways.
From a security standpoint, do you really want to be storing information on the client-side? Typically, I would not store things with the client.
While roughly equivalent from the perspective of manipulation in code, cookies and session variables are very different things.
Cookies are stored in the browser, and transmitted to the web server with each request. If you store large cookies or lots of small ones in the user's browser, you increase the size of each request/response, which makes each hit more expensive (bandwidth) and slower (time). Also, anything stored in a cookie is visible to the client, so avoid storing anything sensitive there.
Session variables, on the other hand, have their own sets of issues. Since they're stored within the server context, they don't propagate between clustered servers. If the server/service resets or the user's session times out, whatever was stored in the session[] collection is lost. Storing large data in a session variable incurs a performance penalty on the server, which can get really bad if you have a lot of traffic. Session variables require a cookie, which the server uses to identify a user's session. It is feasible for a user to alter their cookie to gain access to data stored in other sessions, though this would be pretty freakin' difficult to do with any kind of value since session IDs are randomized, nonsensical pseudo IDs.
Ultimately, all of this crap should be stored in a database anyway. Sessions are a lazy convenience that should be avoided when developing any robust application. Cookies should be used minimally - typically, I store a guid in a cookie which helps me identify a user (similiar to a sessionID cookie, but application-specific), but everything else goes in the database. This gives you server-agnostic data availability, secure storage, data lifetime set by your app instead of the server config, good query and report ability, etc.
Databases are easy when done right. There are many, many reasons that any state information you collect should be stored in a database, and no good reason not to.
In some browser it is not possible to store cookie ,to avoid this problem you can pass a SID (session id) or some hidden,filled,textbox values , instead of cookies, by using GET and POST methods.
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.