Securing PHP Sessions

[R8kit]

Hey everyone,

 

I am new to PHP and I want to learn how to secure a PHP session properly.

 

I wrote a few lines, but I don't know if it's secure enough.

 

<?php
session_start();

if (isset($_SESSION['exists'])) {
    if ($agent != $_SERVER['HTTP_USER_AGENT']) {
        session_unset();
        session_destroy();
        session_regenerate_id(True);
}
}
else {
    $_SESSION['exists']=1;
    $agent=$_SERVER['HTTP_USER_AGENT'];
    session_regenerate_id();
}
?>

 

Can anybody help me correct or improve my code?

 

Thanks in advance.

[voip03]

your method is fine.

it's secure enough? no

 

This article for you.

http://www.phpfreaks.com/forums/index.php?topic=343457.msg1620477#msg1620477

[ManiacDan]

In your first block, $agent comes from nowhere.  Are you meaning to store $agent in the session somewhere?

 

session_unset() takes an argument, you've provided none.  Regardless, session_unset is deprecated and should not be used.

 

session_regenerate_id serves no purpose for either of these actions.

 

More correct code:

 

<?php
session_start();

if ( isset($_SESSION['agent']) && $_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT'] ) {
  foreach ( array_keys($_SESSION) as $key ) {
    unset($_SESSION[$key]);
  }
}
else {
    $_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT'];
}
?>

 

As for the SO article posted by voip:

 

Use SSL when authenticating users or performing sensitive operations.

Good advice, but SSL certs are expensive.

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.

I think regenerating the session id is unnecessary, and will break if you have non-locking sessions using a custom handler (which currently you don't, but still)

Have sessions time out

Sessions time out already.

Don't use register globals

Good advice, register_globals is bad and wrong and evil

Store authentication details on the server. That is, don't send details such as username in the cookie.

More good advice, cookies are for data that's relatively useless, or things you need to get to in javascript

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).

Also good advice, you can add an IP check to my code easily

Lock down access to the sessions on the file system or use custom session handling

This isn't all that important, if someone has access to the filesystem you have bigger problems than your sessions.

For sensitive operations consider requiring logged in users to provide their authenication details again

Not really a "session" security tip but a general one.  If they're doing something really really important or dangerous (like closing their account), make them type their password again just in case.

 

And, for good measure, the SP one too:

1. Shared web servers

Very good thought, and hadn't crossed my mind before.  I haven't used a shared host in almost a decade.  If you're on a shared host, nothing sensitive can go in the session unless you encrypt it (which would require a custom handler).

2. XSS exploits (and session hijacking)

Using SSL is the only true way to avoid hijacking, but the user-agent and IP check works ok.  A constantly rotating session ID using regenerate_id mitigates this somewhat because either the attacker or the legitimate user will be knocked off your site after the other makes a request.

3. Session IDs in URL (and hijacking)

Don't pass session IDs in URLs, it's deprecated for a reason.

4. Session Fixation (pre-hijacking)

An interesting scenario, but rare.  Regenerate the ID when they log in seems like a good idea, but I haven't found it to be necessary.

5. Sniffing Packets (use SSL [HTTPS])

SSL is expensive, but yes it would solve this problem.

6. Cookies are not for session data

As discussed before, cookies are for worthless data that you don't care who sees. 

 

-Dan

[voip03]

You need to use a combination of numeric and alphabet characters for session value.

 

Validating the session

Validate the first and second numeric characters or middle or last characters

 

When you validate the user accessibility, you should at least develop two validation methods.

 

[Adam]

Validate the first and second numeric characters or middle or last characters

 

Compare the first and second numeric characters to... what?

 

When you validate the user accessibility, you should at least develop two validation methods.

 

Why two? Why not just develop one secure method?

[R8kit]

Thanks for the replies.

 

In your first block, $agent comes from nowhere.  Are you meaning to store $agent in the session somewhere?

 

It's a little bit difficult for me to explain because my English is not 100%

 

I thought if the session variable: [ if (isset($_SESSION['exists'])) ] is not set, the else "lines" would be executed. And

in the else statement I assigned $_SERVER['HTTP_USER_AGENT'] to $agent, and stored a value in the session, so I thought that when you refresh the web page the session will exist and the [ if (isset($_SESSION['exists'])) ] condition will be true and the lines below them will be executed and check if the same HTTP_USER_AGENT is being used.

 

In other words I thought that I already assigned a value to $agent in the else condition and that it would stay in memory somewhere so I can compare it to the current HTTP_USER_AGENT being used, and if it did not match destroy the current id session and generate another one.

 

But I think I understand what you mean, it indeed came out of nowhere. I thought it didn't matter because the condition will not be true

anyway and jump to else and execute the lines there and store the $agent variable. I thought the next time the code executes[Refresh], the condition would be true and the HTTP_USER_AGENT compared.

 

I hope you understand what I am trying to say.

 

[Adam]

The whole point of sessions in PHP is to retain data between requests. PHP is stateless, meaning the variables you define only exist for that request. At the end of the request, PHP destroys everything (except for the session, which is stored in a file) and then starts from scratch on the next.

[ManiacDan]

You need to use a combination of numeric and alphabet characters for session value.

 

Validating the session

Validate the first and second numeric characters or middle or last characters

 

When you validate the user accessibility, you should at least develop two validation methods.

This makes no sense at all. 

 

R8kit, as Adam posted above, you're not understanding the way PHP works.  PHP, as he said, is "stateless."  That means that each refresh of a PHP page is a completely new execution of that page.  No variables or values are retained unless you specifically save them into the session or a database.  When you execute your page for the first time, your ELSE will be executed and the user_agent will be saved to the session.  The next time you execute your page, the IF will be executed but $agent will be empty because this is the first time that code has run.

 

-Dan

[voip03]

Validate the first and second numeric characters or middle or last characters

 

Compare the first and second numeric characters to... what?

 

When you validate the user accessibility, you should at least develop two validation methods.

 

Why two? Why not just develop one secure method?

 

I would really like to know one secure method.Please show me one secure method?