I am creating a php application and need to enable different permissions. I could, for example, have a regualr user and an administrator. I've assigned a permission integer in my DB with which I can assign the correct permissions to each user. My question is whether it is safe enough to store this permission varriable in a session varriable. Alternatively, I could store it in a coockie, but for some reason that doesn't seem too safe. Are there any other alternatives? Which is most common? What if my users don't have coockies enabled?
Users can easily forge cookie data. There's even an extension for firefox that lets you edit your cookies to whatever you want. To 'remember' user data across different page requests, you'd need to use sessions. How you want to implement sessions is up to you but the built-in PHP session handling is usually sufficient. The session, as opposed to simply storing values in cookies, has all the data stored on your server. Obviously the end user can't alter that - you simply use a unique session id to match each user to their session data. The client will only be able to edit the session key, the key is sent to the server which then lookups the corresponding session data. The built in PHP session handler can do all this for you. The exact behaviour depends on your configuration but normally it'll attempt to send the session id as a cookie - if cookies are accepted, it'll use cookies, otherwise uses the query string to pass the session id as get data. The only downside is there is no additional 'security' to protect sessions from being hijacked. It's already a lot lot safer than storing user data in cookies but if someone can get hold of someone else's session id/key, they will be assigned all their session data. There's no foolproof way of preventing this but commonly the script may check the current users user agent (browser) or ip address, or both, against values already stored within the session data itself. Then if either change during a session, it may be an attempt to hijack the session and the script can destroy all the session data and start a fresh one. You just have to decide on an appropriate level of session security - while a change of IP or user agent could suggest an attempted hijack, it also could be a genuine user with no malicious intent and they may not be too keen on getting logged out for no reason.
That's because cookies can be edited by the visitor. They're totally insecure in this context. Sessions are better but they still aren't perfect. The main danger is someone getting access to the computer of an administrator, copying the session cookie and putting it on their own computer. They would then have admin permissions. To prevent these sorts of issues you'll want to keep the time to expire on sessions fairly short, regenerate the session id occasionally and as an extra precaution recheck the password before letting an admin do anything really dangerous. Another potential security threat is that anyone who has access to your server will be able to see values attached to a session. Generally this isn't too major a problem unless you're storing passwords in plain text and then decide to store them in session variables as well.
I suggest you to use only an id in the session and perform sql queries based on that id in order to retrieve data.