|Sessions and Posts and Gets Oh My!|
What to use and when
| 2:19 am on Jan 30, 2008 (gmt 0)|
Is there any benefit whatsoever to using POST or SESSION? For example in prg1 I can send variable information with <input type="hidden" name="var1" value="foo"> or $_SESSION["var1"] = $var1
Is there any operational or security reason to use one over another? Aside from the fact that the hidden input is viewable in the source?
| 7:54 am on Jan 30, 2008 (gmt 0)|
They're not really analogous - SESSION keeps persistent data relating to a particular visitor and POST is for a visitor to submit data via a form. GET is analogous to POST.
Session data doesn't fly between browser and server; it stays on the server (it may have, at some time, originated from a post or get). POST or GET data is transmitted from the browser to the server. You can never trust data that comes from "the outside" - it always has to be validated against either malicious intent or inadvertent inaccuracy. As an example, ask a user to input today's date. That user may enter the wrong date entirely, in a format that you don't expect to receive, some prankster may hope to corrupt (or obtain) your database through SQL injection, or a 3rd party may be sniffing around in hopes of receiving information valuable to him/her, the visitor, or you.
So if it's information you want to associate with a visitor and you can generate/retrieve it yourself, it's better to keep it in a session - it doesn't fly around and it's information you can trust - if it's info you received from a visitor, you've supposedly already validated it/rendered it harmless. If it's information that you're receiving from a visitor, POST and GET are the only vehicles (via internet anyway) so you're pretty much stuck with trying to make sure it's valid and harmless.
The hidden input isn't only viewable in the source, it can be modified before it gets sent back to you - so you have to validate it again.
| 10:41 am on Jan 30, 2008 (gmt 0)|
As cameraman and you have said hidden variables are not secure. Sessions are 'secure', note that is pseudo-secure not secure. The actual ability of a person to break into the server and get the actual information that is stored by php in its session handler is about as secure as it will get.
The problem with sessions is that we use them and send user supplied data to them. This allows attackers to hijack the sessions. So while a session is infinitively more secure than a hidden variable, you do have to work to make sure that your use of the sessions is as secure as the php back end.
There are a lot of good articles on the web about trying to secure your sessions. So if you are going to be using them then it is well worth reading up about session security [uk.php.net].
| 4:22 am on Jan 31, 2008 (gmt 0)|
As far as operational, SESSION data is shared between all windows/tabs of the visitor's browser, whereas hidden values in POST/GET can be different in each window. Simplistic example: let's say you're selling widgets on your website and when the visitor clicks on Buy Now, they see a form to specify quantity, size, color, etc. Somewhere for this form you need to keep track of the product ID being bought. Now let's say a visitor clicks on Buy Now for widget A but before completing the form, in another window they click on Buy Now for widget B, then go back and fill out the form for widget A...
If you keep track of the product ID in the SESSION, the ID for widget B will overwrite the one for widget A and the visitor ends up ordering the wrong thing (unless you create a separate session for each form). If you store the product ID in a hidden value, then all is fine. On the other hand, you probably want to keep the current contents of the visitor's shopping cart in the SESSION variable so that items can be added from any open window.