Jump to content


Photo

Session Security


  • Please log in to reply
21 replies to this topic

#1 timothyarden

timothyarden

    Advanced Member

  • Members
  • PipPipPip
  • 149 posts

Posted 25 April 2014 - 07:36 AM

Is it safe to use a session to validate whether or not a user is an administrator or not? (https is being used if it makes any difference)
For example:

$Administrator = // Get true / false from mysql database ;
$_SESSION[ 'Administrator' ] = $Administrator;
 
// And later use this to validate access to sensitive parts of a web application
CheckAdmin( $_SESSION[ 'Administrator' ] );

Is this practice safe because the session is stored on the server and the client only has an identifier with which the server recognises that the session belongs to that client. If not could you explain why and how I could achieve what I am trying to do / fix any vulnerabilities that using a session to validate administrator access would have.

 

Thanks in advance!



#2 Jacques1

Jacques1

    Advanced Member

  • Members
  • PipPipPip
  • 754 posts

Posted 25 April 2014 - 11:24 AM

Hi,

 

it's true that users cannot edit the session data, but storing the user role in the session is still a very bad idea, because it leads to redundant data. You now have two places where you store the information: the database and the session. If they fall out of sync, you have a problem. For example, a user who is no longer supposed to be an admin may still have a session with the admin status set to true. Or the other way round: You've just granted a user admin access, but they still run around as normal users until they log out.

 

How did you even get to this idea? Is this some kind of micro-optimization thing? Simply grab the data from the database.



#3 Psycho

Psycho

    Advanced Member

  • Gurus
  • 10,752 posts
  • LocationCanada

Posted 25 April 2014 - 03:20 PM

I disagree. The whole point of session data is to store data that you will use repetitively throughout the user's session. If you need to know whether the user is an admin when loading many or all pages, then storing that information in the session is perfectly acceptable.

 

However, Jacques1 does bring up a valid point about the fact that session values do persist for the entire session (obviously). So, if a user is logged in as an admin and you change their status to not be an admin, then that user will still be considered to be an admin until their session terminates. But, that is a business decision. That would likely be a very rare occurrence. Is the need to immediately remove the admin access important enough to incur the overhead of doing an additional DB request on each page load? If it s a very security critical site I would say yes. Otherwise, I'd say no.

 

Also, there are other workarounds you could use. For example, you might rely upon the session value for most pages. But, there may be critically sensitive pages that you would want to always check the DB. This is no different than how most sites save your login status. I can browse most sites after I login and it is using a session status as I go from page to page. However, if I go to a page to modify my account information, I may be asked to again provide my credentials as an additional check.


Edited by Psycho, 25 April 2014 - 03:21 PM.

The quality of the responses received is directly proportional to the quality of the question asked.

I do not always test the code I provide, so there may be some syntax errors. In 99% of all cases I found the solution to your problem here: http://www.php.net

#4 davidannis

davidannis

    Freak Dr.

  • Members
  • PipPipPip
  • 588 posts
  • LocationOkemos, MI USA

Posted 25 April 2014 - 08:52 PM

I tend to agree with Psycho but if you are worried another compromise would be to set the session to expire after a reasonable length of time. http://stackoverflow...umber-of-minute



#5 timothyarden

timothyarden

    Advanced Member

  • Members
  • PipPipPip
  • 149 posts

Posted 25 April 2014 - 09:05 PM

Thankyou for your responses Jacques, Psycho and David

For the purposes of this project there will be very little, if any changes to administrators once the application is launched. Once a user is admin, there should be no need to change admin status as these people are all part of an organisation and we can trust each other. But I had planned to set whether the user was an admin in the session and validate this from the database each pageload.

 

it's true that users cannot edit the session data

So does this mean that sessions are 100% secure and can only be viewed and edited by the server scripts (unless the script displays them in some form)?

Also does the above depend at all as to whether you have a secure connection with ssl?



And thanks for that David, I'm leaning towards 15 minutes lockout.



#6 timothyarden

timothyarden

    Advanced Member

  • Members
  • PipPipPip
  • 149 posts

Posted 25 April 2014 - 09:38 PM

Also how do sessions use cookies and aren't they vulnerable through this?

#7 r3wt

r3wt

    Advanced Member

  • Members
  • PipPipPip
  • 44 posts

Posted 25 April 2014 - 09:40 PM

I agree with Jacques. get the info from the db, don't rely on the session for authentication.



#8 r3wt

r3wt

    Advanced Member

  • Members
  • PipPipPip
  • 44 posts

Posted 25 April 2014 - 09:41 PM

Also how do sessions use cookies and aren't they vulnerable through this?

 

I'm not sure if i'm allowed to post a link to the devshed forums, but here's a pretty authorative post on the subject from Jacques. This should give you a "crash course" look at the subject of sessions in php:

 

http://forums.devshe...ure-953373.html


Edited by r3wt, 25 April 2014 - 09:43 PM.


#9 Psycho

Psycho

    Advanced Member

  • Gurus
  • 10,752 posts
  • LocationCanada

Posted 25 April 2014 - 09:47 PM

But I had planned to set whether the user was an admin in the session and validate this from the database each pageload.

 

What? Why would you do that? That's a waste. If you already pulled that info from the DB and saved it in the session, then pulling it again on each page load is not necessary.

 

 

So does this mean that sessions are 100% secure and can only be viewed and edited by the server scripts (unless the script displays them in some form)?

Also does the above depend at all as to whether you have a secure connection with ssl?

 

Nothing is 100% secure, but for all intents and purposes session data can only be accessed on the server. An SSL connection is used to encrypt data between the client and the server. Since the session data is never passed between the client and the server SSL has no impact on this.

 

 

Also how do sessions use cookies and aren't they vulnerable through this?

The only thing stored in the session cookie is the session ID which is the unique identifier for the user's session. When the user accesses a page, the server uses that cookie to associate them with the appropriate session data. But, the data exists only on the server.


The quality of the responses received is directly proportional to the quality of the question asked.

I do not always test the code I provide, so there may be some syntax errors. In 99% of all cases I found the solution to your problem here: http://www.php.net

#10 timothyarden

timothyarden

    Advanced Member

  • Members
  • PipPipPip
  • 149 posts

Posted 25 April 2014 - 11:10 PM

Thankyou for the posts r3wt and Psycho

r3wt: Could you please expand on why you said: "don't rely on the session for authentication"? Is it for the same reason as further above where Jacques said if the data is updated it will not updated for that individual user until they log out?

Psycho:
Point 1 - Okay I won't check the database on each pageload - only for sensitive pages like mentioned earlier.
Point 2 - Thankyou for explaining why ssl doesn't matter for sessions. If it isn't 100% secure is there any way I can increase it's security / any guidelines I need to follow?
Point 3 - Could a hacker potentially copy a persons cookie and use it themselves - having the server see the cookies identifier and then grant access to the session data which is stored and modified on the server?

Thanks for everyones help so far!


EDIT:
This is already in my code and executed on every page load

function __construct( $SessionName = "developmentwebsite", $Secure = SECURE, $HTTPOnly = TRUE ){   // sec_session_start()
            if( ( ini_set( 'session.cookie_secure', 1 ) === FALSE ) || ( ini_set( 'session.cookie_httponly', 1 ) === FALSE ) || ( ini_set( 'session.use_only_cookies', 1 ) === FALSE ) ){   // Forces sessions to only use cookies.
                header( "Location: ../Error.php?error=Could not initiate a safe session (ini_set)" );
                exit();
            }
            
            $CookieParams = session_get_cookie_params();            
            session_set_cookie_params( $CookieParams[ "lifetime" ], $CookieParams[ "path" ], $CookieParams[ "domain" ], $Secure, $HTTPOnly );
                        
            if( !isset( $_SESSION ) ){
                session_name( $SessionName );
                session_start();            
            }
            
            session_regenerate_id();

            $_SESSION[ 'Expiration' ] = NULL; // This will be 15 minutes later and have validation in another part of the script
}

Edited by timothyarden, 25 April 2014 - 11:20 PM.


#11 timothyarden

timothyarden

    Advanced Member

  • Members
  • PipPipPip
  • 149 posts

Posted 26 April 2014 - 12:18 AM

Another question:

In my logout script I am doing this: unset($_SESSION)
 

But in the PHP manual it says
"Caution: Do NOT unset the whole $_SESSION with unset($_SESSION) as this will disable the registering of session variables through the $_SESSION superglobal."

It is currently having no problems and no errors so I don't understand what it means - could someone explain please? Thankyou


#12 timothyarden

timothyarden

    Advanced Member

  • Members
  • PipPipPip
  • 149 posts

Posted 26 April 2014 - 07:56 AM

bump



#13 davidannis

davidannis

    Freak Dr.

  • Members
  • PipPipPip
  • 588 posts
  • LocationOkemos, MI USA

Posted 26 April 2014 - 08:10 AM

I agree with Jacques. get the info from the db, don't rely on the session for authentication.

Whether you determine the status of the user from the db or not, you're going to use sessions to authenticate the user. The only other choices are to set a cookie on your own (and reinventing the wheel is error prone) or reauthenticating on every page. Assuming a hacker can take over a session that stores an admin's ID he'll be in as an admin whether you get admin status from the DB or from the $_SESSION array.



#14 davidannis

davidannis

    Freak Dr.

  • Members
  • PipPipPip
  • 588 posts
  • LocationOkemos, MI USA

Posted 26 April 2014 - 08:18 AM

Re: your points 2 and 3: The known issues with hijacking a session are discussed here. Unless you have a very sensitive app (financial transactions), I think the known issues can be pretty safely ignored.

 

In addition to unset you should technically kill the session cookie. An example is provided on the session_destroy manual page. I often don't bother in low security applications.



#15 r3wt

r3wt

    Advanced Member

  • Members
  • PipPipPip
  • 44 posts

Posted 26 April 2014 - 11:56 AM

Whether you determine the status of the user from the db or not, you're going to use sessions to authenticate the user. The only other choices are to set a cookie on your own (and reinventing the wheel is error prone) or reauthenticating on every page. Assuming a hacker can take over a session that stores an admin's ID he'll be in as an admin whether you get admin status from the DB or from the $_SESSION array.

the point was there is no reason to set an extra session for an admin, let alone rely on this for authentication.



#16 timothyarden

timothyarden

    Advanced Member

  • Members
  • PipPipPip
  • 149 posts

Posted 26 April 2014 - 10:23 PM

Okay thanks for explaining that (and the link) David, it helps a lot
I am already using session_destory() (I probably should have mentioned that sorry) I just dont understand why on php.net they say not to unset() the $_SESSION variable?

Thanks for that r3wt, I won't use a second session for admin's :)



#17 Jacques1

Jacques1

    Advanced Member

  • Members
  • PipPipPip
  • 754 posts

Posted 27 April 2014 - 01:08 PM

What the manual is saying is that you're not supposed to erase the $_SESSION variable itself, because PHP needs this for the session mechanism to work.

 

But you can and should overwrite the variable with an empty array during logout:

$_SESSION = array();

Otherwise, $_SESSION will still hold the old data while the script runs. This may confuse later parts of the code and make it assume the terminated session is still valid.

 

So logging out a user really consists of three different steps:

  • session_destroy() deletes the session file on the server
  • $_SESSION = array() clears all session data in the running script
  • asking the client to delete the session cookie

If you forget the latter, the client will keep sending you the old ID, and PHP will reuse that ID for the next session. This isn't necessarily a problem as long as you properly renegerate the ID in the login procedure. But it's still somewhat unclean.

 

I strongly disagree with the statement that you can ignore session security, and I find it sad that people still believe TLS/SSL is only for banks. How many more hacks do we need until everybody realizes that they, too, are affected by threats?

 

Without TLS, you have absolutely no way to tell who got your data, what server you're talking to and whether the page you received is authentic. Anybody who happens to be between you and the server may read, intercept or manipulate the communication. Do you really wanna use your admin account in this environment?

 

Yes, you may simply hope that everybody arounds you plays nice. But I don't think this is the right attutide for running a website.

 

The same is true for session security: If you don't take care of security, then attackers will exploit that as soon as they find it worthwhile. It's not always about big money. It could simply be a script kiddie trying to impress some friends. Or maybe somebody is angry at you.

 

Security is crucial, no matter if you're running a bank or a small homepage. Both are at risk.

 

And, really, there's simply no excuse for not securing your site. Getting a free TLS certificate from StartSSL, including it in Apache and updating the php.ini  is a matter of minutes and doesn't require any money or special knowledge.


Edited by Jacques1, 27 April 2014 - 01:09 PM.


#18 davidannis

davidannis

    Freak Dr.

  • Members
  • PipPipPip
  • 588 posts
  • LocationOkemos, MI USA

Posted 27 April 2014 - 03:08 PM

I strongly disagree with the statement that you can ignore session security, and I find it sad that people still believe TLS/SSL is only for banks. How many more hacks do we need until everybody realizes that they, too, are affected by threats?

 

I'm not saying that you should ignore session security if the result of the blown security is possible fraud or compromise of your website, but sessions can be used for all sorts of low security purposes. I think that I stated that ignoring the threat of a hijacked session was true only if you are coding a low security application. Perhaps I was unclear. As an example, one site that I am working on now is a teach yourself Japanese site. It keeps track of which questions a user has answered on a quiz in a session variable. Nobody will ever care enough to hack the sessions and if they do, the repercussion is a missed question or incorrect score on a quiz that the user is taking. For that kind of application I can't see why I would need to worry.



#19 Jacques1

Jacques1

    Advanced Member

  • Members
  • PipPipPip
  • 754 posts

Posted 27 April 2014 - 04:53 PM

Since the OP explicitly asked about admin sessions, I think we all agree that this does not fall into the category of low-security applications. If he had asked about a different situation, then, yes, this would be a different discussion.

 

My point is simply that things like using HTTPS and hardening the PHP sessions are relevant for everybody and should be the default until there are good reasons against them (like in your case). Personally, I don't like terms like “highly sensitive data” or “high-security website”, because it makes people think that their own data and their own website aren't important enough to be protected. But we actually need much better security on average websites.



#20 MstrGmrDLP

MstrGmrDLP

    Member

  • Members
  • PipPip
  • 10 posts

Posted 27 April 2014 - 11:15 PM

I use $_SESSION for my website. Just about everything a user needs is in a session. I haven't had any troubles yet. When they first sign in it sets the information. My opinion is it is safe to use.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Cheap Linux VPS from $5
SSD Storage, 30 day Guarantee
1 TB of BW, 100% Network Uptime

AlphaBit.com