PHP - is it safe to store anything in the $_SESSION superglobal?

Is it safe to store for example user permissions like

$_SESSION['username']='vputin';
$_SESSION['ip']=$_SERVER['REMOTE_ADDR'];
$_SESSION['canlaunchnuclearstrike']=true;

Are there any security issues with this? Is it enough to check this on every page load and based on that either redirect to log开发者_开发问答in page (and exit;) or continue?

It all depends on what you mean by "security". There is no abstract notion of "being secure". You can only be secure against specific threats. (This is called your "threat model".) If you don't say what you want to be secure against, it's impossible to say whether your solution is good or not. There's certainly no guarantee that zombies won't come and eat your site users when they log in to your site!

That said, session variables are inaccessible through the web server, so they form part of the opaque state of your web application which the user cannot see or exploit directly.

On the other hand, there are numerous avenues of attack that allow for leaking, stealing or abuse: If the session cookie is stolen, someone else can take over the session (and perhaps launch the nuke); this is an entirely common Starbucks-type scenario. Another vulnerability lies on the server itself: If the session data is stored in a file that is readable by other users, say on a shared host, then it is possible that others may obtain the session ID and the session data behind your back, by reading them directly from the server's disk.

It all depends! Probably best not to write your nuke strike management app in PHP on a shared host...

It is usually much better to store only the current user's ID in the session, and to look up permissions "live" from where they come from - e.g. a permissions database.

That way, you can be sure that changes in permissions reflect immediately upon what the user can and can't do.

There could be session hijacking or other ways to read information from the session. So an unencrypted password would be a security issue, but until the username is not a big deal you can save it in the session.

(Or use an user id and encode it to the username in your script)

So as a conclusion: only save "public" data, "nuklearmissile" etc should be resolved in the code an not rely on session data.

Session data is saved on server. User just gets the session id into cookies, so server knows which user is it.

Issues:

• Session id can be stolen, thou someone can fake the identity
• Session data on shared hostings can be shared among same users of one hosting server (on bad hosters ofc), so someone else can access your session data using same hosting server.

Session is pretty good way to store user identification, but it's not a good idea to store sensible information there.