What Are the Risks of PHP Sessions

What are the risks of PHP sessions?

Mainly here are the risks:

• Session hijacking
• Session fixation

Consider using OWASP to do against it.

Also have a look at:

PHP Security Guide

How safe are PHP session variables?

Sessions are significantly safer than, say, cookies. But it is still possible to steal a session and thus the hacker will have total access to whatever is in that session. Some ways to avoid this are IP Checking (which works pretty well, but is very low fi and thus not reliable on its own), and using a nonce. Typically with a nonce, you have a per-page "token" so that each page checks that the last page's nonce matches what it has stored.

In either security check, there is a loss of usability. If you do IP checking and the user is behind a intranet firewall (or any other situation that causes this) which doesn't hold a steady IP for that user, they will have to re-authenticate every time they lose their IP. With a nonce, you get the always fun "Clicking back will cause this page to break" situation.

But with a cookie, a hacker can steal the session simply by using fairly simple XSS techniques. If you store the user's session ID as a cookie, they are vulnerable to this as well. So even though the session is only penetrable to someone who can do a server-level hack (which requires much more sophisticated methods and usually some amount of privilege, if your server is secure), you are still going to need some extra level of verification upon each script request. You should not use cookies and AJAX together, as this makes it a tad easier to totally go to town if that cookie is stolen, as your ajax requests may not get the security checks on each request. For example, if the page uses a nonce, but the page is never reloaded, the script may only be checking for that match. And if the cookie is holding the authentication method, I can now go to town doing my evilness using the stolen cookie and the AJAX hole.

How secure are PHP sessions?

No, a session is stored on the server and cannot be accessed by the user. It is used to store information across the site such as login sessions.

Here is an example of the usage:

<?php
session_start();
if (password_verify($_POST['password'], $hash)) {
    $_SESSION['auth'] = true;
}
?>

The session can then be accessed across the site to check to see if the user has been authenticated.

<?php
session_start();
if ($_SESSION['auth']) {
    echo "You are logged in!";
}
?>

The user cannot edit these values however the session's ID is stored on a computer through a cookie as a long random string. If an unauthorized user gains access to these strings it is possible for them to access the site.

PHP: $_SESSION - What are the pros and cons of storing temporarily used data in the $_SESSION variable

Well Session variables are really one of the only ways (and probably the most efficient) of having these variables available for the entire time that visitor is on the website, there's no real way for a user to edit them (other than an exploit in your code, or in the PHP interpreter) so they are fairly secure.

It's a good way of storing settings that can be changed by the user, as you can read the settings from database once at the beginning of a session and it is available for that entire session, you only need to make further database calls if the settings are changed and of course, as you show in your code, it's trivial to find out whether the settings already exist or whether they need to be extracted from database.

I can't think of any other way of storing temporary variables securely (since cookies can easily be modified and this will be undesirable in most cases) so $_SESSION would be the way to go

Security with PHP Sessions

Session security risks come from three different possibilities:

• Prediction
• Capture
• Fixation

Prediction would mean that someone that's not the user for whom the session was created guessed their session ID. The chances of that happening are almost 0, although they do grow as more users use the site simultaneously.

With your code, you would make that risk even lower because it would only work if the attacker shared the user agent and the ip of the predicted session. But the difference is trivial in this case.

Fixation would mean that an attacker can create a session and then force another user into using their session. In this case it would depend: If the attacker knows that you are doing it and they fake the user agent and ip of the client, they could fixate the session. Or if they share ip and user agent.

And finally we have session hijacking, probably the most common method of the three. In this case an attacker would somehow gain access to the session id of a valid logged in user, and then use it to log in to their account. As with the previous method, this would only work for them if they know that you are checking the ip and user agent, and faked the same ones as the user. The technique you are using is not unique, and some attackers might fake them just in case.

---

That being said, is it secure? Yes and no

If you are obsessed with security, the answer is always the same: Use SSL

Unless your code is open source, almost anything you do that changes the behavior of the php sessions will be secure enough.

The only exception to that would be really popular sites that will attract the attention of hackers.

There is some very good documentation on this topic available:

• http://phpsec.org/projects/guide/4.html
• PHP Session Security
• http://www.squarefree.com/securitytips/web-developers.html#CSRF

What are the risks in storing data in session?

User grom has a great answer here that mentions ways to help secure your session in PHP:
https://stackoverflow.com/a/7488/3874219

I'd like to start off by saying that PHP, especially 5.x.x versions, have come a long way in security; however, there are still many potential things that can happen to your session data, as it is constantly passed between your server and the client. Let's tackle your 4 points individually:

'Should the user now travel from mysite.com, to devious-site.com, is
there any way that someone can get the data from "basic_variable",
just by knowing that the variable is called that?'

Inherently, no. Your variables and variable names are stored on your server, and because the code is processed into an HTML view before being sent to the client, your PHP code never reaches the client. Data stored in variables that are otherwise not passed to the client are safe on your server, granted someone doesn't gain access to your server or in some manner compromises your server's security. If your data in the given variable is stored in a session or cookie that is transferred over the wire/network to the client, it has the potential of being intercepted. This traffic is unencrypted by default, unless you have implemented OpenSSH via an SSL certificate or similar encryption scheme.

'Is there any way that the current user can see a print out of the
$_SERVER variable and actually see all the contents stored in it?'

If you 'echo' it, or otherwise program your PHP to expose the data stored in it. Again, if the variable is ever put somewhere where it is sent to the client and not processed into HTML or otherwise disposed of before an HTTP response is sent, it is at risk.

'I read somewhere that data in the session or in cookies should be
"encrypted". In the above example, I'm fairly sure the data is being
stored in the session, and that this session is secure. Is this the
case, or is it only secure if HTTPS is enabled?'

Yes, HTTPS must be enabled, and you must have an SSL certificate to encrypt the data, otherwise everything in your unencrypted HTTP requests/response are subject to sniffing, cross-site scripting attacks, domain forging, redirection attacks, and the list goes on. SSL definitely helps prevent much of this.

'Drupal stores some info in cookies, if you choose to use cookies as
apposed to "session", how does that affect the above?'

Cookies are stored on a user's machine. The data in the cookies can be encrypted or hashed by your server so that it is safely stored clientside, but anything is possible. If a potential hacker forges your domain, they gain access to the cookies and everything in it. If the cookie links to an active session, they have just spoofed their identity and gained access to your site with the victim's session. Poof. Identity theft, malicious editing of user content, etc. Drupal definitely has been around long enough to have mechanisms in place to help prevent this; however, I am not a Drupal expert.

Hopefully that sheds some light. Best practices IMO, do not store sensitive data in the session! If you are storing identifying information in your cookies, make sure you have some type of implementation to prevent cross-site forging, e.g. in ASP.NET MVC I utilize an Anti-Forgery token that is offered in the framework. You want a way to insure the person claiming to be who they are via cookie has another way to verify the request with said cookie originated FROM YOUR SITE/DOMAIN, and not another one.

PHP Session Security

There are a couple of things to do in order to keep your session secure:

1. Use SSL when authenticating users or performing sensitive operations.
2. Regenerate the session id whenever the security level changes (such as logging in). You can even regenerate the session id every request if you wish.
3. Have sessions time out
4. Don't use register globals
5. Store authentication details on the server. That is, don't send details such as username in the cookie.
6. Check the $_SERVER['HTTP_USER_AGENT']. This adds a small barrier to session hijacking. You can also check the IP address. But this causes problems for users that have changing IP address due to load balancing on multiple internet connections etc (which is the case in our environment here).
7. Lock down access to the sessions on the file system or use custom session handling
8. For sensitive operations consider requiring logged in users to provide their authenication details again

Is it a bad idea to prevent php sessions from expiring?

One example is that it may pose a security risk. If someone is using a public computer and doesn't explicitly logout, then anyone else can presumably access that session. Sessions also consume storage space.

Whether or not these issues should concern you depends on your application.

is it dangerous to store $_POST in $_SESSION?

It's no more dangerous than using $_POST, although if you want the same effect as the original then you should drop the array_values and just assign $_POST to it.

Personally, I'd define a list of expected keys to store, and use them like this:

$allowed_keys = ["first_name","last_name", /* ... */ ];
$_SESSION['info'] = array_intersect_key($_POST,array_flip($allowed_keys));

But really that's just to prevent someone spamming large amounts of POST data and naively storing it in a session file.

---

Related Topics