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.
Related
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'm not concerned with browser compatibility.
I want to know if I move my state from PHP Controlled ( Server-Side) sessions to the JavaScript Controlled ( Client - Side ) HTML 5 local storage will I gain or loose security.
I think that I would gain security because now instead of having the user identifier residing in a cookie, which is usually a file, or sql database that is easily accessible...it is not inside some sort of internal browser storage. + b.c. it is a newer technology I would hope that more security was designed into it.
Do I gain or loose security by moving from PHP Sessions to JavaScript Local Storage. ( This is for things like user id, page_id, etc, the current state that remains after a reload and longer if needed ).
I have a JavaScript solution I want to replace my PHP Sessions with. That is why I ask. I don't care about browser compatibility.
Here is an informative site on Local Storage. But Security was not mentioned.
Both types of local storage (localStorage and Cookies) use some sort of identifier which is obviously stored on the client.
Both use a hash mechanism to secure it from altering to another user.
Local Storage is more secure then cookies ( see here ).
And obviously you have to write the session protocols if you want to move your user identifier from cookies to localStorage.
Both can be stolen to fake being another user. Though less likely with localStorage.
And to make robust you need a fingerprinting technique that will help with above problem.
I have a JavaScript solution I want to replace my PHP Sessions with.
No. Do not do it. Sessions are stored in the server side. The cookie that is sent out to the browser is typically an identifier for that record. Session stores user-specific data. Almost anything stored on the client side can be easily modified by the user. So if the user modifies the session to point to another user, the security would no longer hold.
LocalStorage is NOT for storing sessions. Stick with PHP sessions, or any other session mechanism that is implemented on the server side.
Update
But the same security flaw is present...a user can login as one
person...fiddle with the session_id of the Session and become someone
else...fiddling with a session_id...equates to fiddling with who you
appear to be to the server ?...this would be the same as fiddling with
an encrypted user_id in local_storage.
No. Suppose I figure out the algorithm you are encrypting with. And I know of another user say UserB. I encrpyted his username using that algorithm. If I somehow overwrite my localStorage with that encrypted string, I am him now. That is not much possible practically. Think of it as there are 100 users and 128 byte-string is the identifier. Are you sure you would be able to fiddle with it and modify it into another record which exists in the table of sessions?
Local storage is best suited for data that you want to cache on the client in a (more permanent) way then with the regular browser cache. The only way it's "more secure" is if you want to allow the user to work with data that's never sent to the server.
If you're worried about session hijacking, the preferred solution would be to use https/ssl and encrypt all traffic between you and the client. There's a general overview of the problem and solutions on wikipedia (we'd need more information to give you anything much more specific than that, though).
You wouldn't gain or lose security as in most browsers all data set by sites are stored in the same folder
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.
I know that codeigniter stores it's sessions as a cookie, which, from reading around I understand to be somewhat insecure. So... I am planning to enable database storage for sessions, which I believe:
a) Is safer?
b) Allows you to store more data than the 4kb limit offered by cookies?
However on the flipside I guess this will be slower for the system to retrieve, for example, in my application I regularly want to query the session data to determine if a user is logged in.
Is is a good idea to store sessions in the database, or will this slow down my app considerably?
Any other ideas or suggestions regarding sessions and cookies would be most appreciated.
Well, that is true and false. CodeIgniter can be configured to store its data on a DB, but it can encrypt the cookies before storing them on the client. It also MD5's the cookies contents to ensure data integrity (basically if the Cookie's MD5 doesn't match correctly, then it is rejected). So while by default it is possible to edit the cookies, it is more than annoying to do so.
Personally, I generally prefer to store session level data in the $_SESSION and have modified my session object to allow me to do that. I also make the PHPSESSID variable a good deal more complicated.
As to your question, "Is it a good idea to store sessions in the database", well, that depends on how fast your database is and what your memory requirements are. It could slow things down or it could, conceivably, speed things up based on configurations et al.
What's the best and most secure way to go when writing an authentication library in a model-view-controller way?
The things that give me a hard time are keeping track of the users activity and remembering users via a cookie or storing sessions in the database?
Thanks in advance :).
If you want to use sessions, you have secure them against attacks like session fixation and session hijacking.
To prevent both you have to ensure that only authenticated requests are allowed to use the session. This is commonly done by chaining as many specific (possibly unique) informations about the client as possible with the session. But as some informations may change on every request (like the IP address), it can be difficult to find good one.
This is why it is useful to use the method denoted as Trending.
Another good protection measure is to swap the session ID periodically. Thus the period for an attack on a valid session ID is smaller.
The simplest way to implement it is with PHP SESSIONS.
just session_start (); near the beginning of your script and you have access to the $_SESSION global array for holding your authentication data.
Depending on the configuration of your server all the data stored in $_SESSION will only be available on the server from which it is hosted (with few exceptions). You can configure it to be saved in a temporary directory, in memcached, or even a database.
The only thing that is transmitted between the client and your server is a "session key". The key can be passed by cookie or URL-rewrites (which are transparently handled by the start_session output buffer).