On Wednesday, November 05, 2003 5:43 PM, Lang wrote: /*-------------------------------*/ 1. Have register_globals set to off in your php.ini and 2. Check the values before you put them in the session. You should be ok. ie. if you just go $_SESSION['g_id'] = $_GET['g_id'] on one page, then you still have the same security risks as using just $_GET.
If you are slightly more paranoid then you have to look at the way session variables are stored between one page and another. If you are using files (the default), can someone else edit the files on your server? Even if you use a custom session handler to store session variables, the main question is.. Can something else change the session variables, other than my php scripts. If the answer is yes, then you need to do more checking. /*-------------------------------*/ Hi, Lang. Thanks for the reply. Currently I do have register_globals turned off, and the session values are all set with values pulled from a database. The $_POST values passed to the query which retrieves this info are validated using regular expressions. I just checked the PHP session files and they're stored in /tmp and owned by apache. Should I change this to another directory and lock down the directory to make this a little more secure? As to your last point, can something else change the session vars other than my php scripts, answers to that question are exactly what I'm looking for. In all honesty I don't know enough about how one would go about attempting to hack the values of a session other than through hacking into the session files, so if anyone has any input on this please pass it along. Cheers, Pablo Pablo Gosse wrote: > Hi all. A quick question as an extension to the threads about input > validation over the past weeks. > > It's obviously best practice to rigorously check and validate all input > coming via $_GET or $_POST, but what about $_SESSION values? > > Without proper checking of $_GET and $_POST, it is very easy for someone > to exploit an application. But what are the potentials of this > happening with session values? > > As an example, in my CMS when the user logs in a number of session > variables are registered, including a user id, group id and clearance > level, all of which are used extensively in queries. > > Throughout the CMS I use a custom function to validate any ids coming > from $_GET or $_POST, but are those which come from $_SESSION equally > dangerous? It would seem to me that they wouldn't be quite as > dangerous, but I can't really say for sure. > > For example, if someone is attempting to retrieve a specific content > block within the CMS for editing, the following query is executed: > > > $query = 'select c.* from cms_content c, cms_access x '; > $query .= 'where x.status = 1 and x.c_id = c.c_id and '; > $query .= 'x.p_id = '.$p_id.' and c.p_id = '.$p_id.' '; > $query .= 'and x.u_id = '.$_SESSION['u_id'].' and '; > $query .= 'x.g_id = '.$_SESSION['g_id'].' '; > $query .= $_SESSION['clearance'] < 2 ? 'and (c.release < now() and > (c.expires is null or c.expires > now()) and ((c.begin_suspend is null > and c.end_suspend is null) or (now() not between c.begin_suspend and > c.end_suspend))) ' : ''; > > > What are the implications of not validating the $_SESSION['u_id'], > $_SESSION['g_id'] and $_SESSION['clearance'] values? > > In this query, for example, the last ternary statement checks if the > clearance value for the current session is less than 2, and if so the > content can only be accessed if the conditions run against the timestamp > fields for that specific record are valid. > > However, if someone were somehow able to hijack the value of > $_SESSION['clearance'] and set it to 3 or 4, then this check would be > ignored. > > How big of an issue is this? I'd be very interested in some opinions > from those with more experience on the security side of things. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
