CODEWITHSUNDEEP
phpsessiontoken
Woozle
Woozle

Reputation: 25

Session hijack resulting in token exposure

I'm trying to wrap my head around session hijacking and the use of tokens for CSRF protecting. I use this object method in each of my scripts to check whether a session variable is set or the token matches the session token.

public function admin_index(){

session_start();
if(!isset($_SESSION["user"]) || $_GET['token']!=$_SESSION['token']) {
    header("location: login/login_form.php");
    session_destroy();
    exit();
}

I'm new at this and my question is: If my session id is somehow hijacked will he be able to some how also read my variable $_SESSION['token'] in the short time span after session_start and the the session data is fetched and populate in $_SESSION or is it still safe on the server?

Are session variables generally safe even though a valid session has been obtained?

Never mind the $_GET['token'] instead of POST. I'm still working on it.

Thanks

EDIT:

What I'm asking is. If a token also helps me secure my sessions the way I'm using it. If every query, link or view in my script requires a valid token and an attacker only got a hold of my session_id the tokens would be another layer of protection cause he/she would need both the id AND the token to do anything in the script, right?

And the token is secure on the server even though an attacker has acquired my session_id?

Upvotes: 1

Views: 816

Answers (3)

Daniel West
Daniel West

Reputation: 1808

Session Hijacking and CSRF attacks are two completely different things and once someone has your access to your session they are 'you' and can access everything on your account.

A CSRF attack is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated

This is a social engineering and validation issue which using a token can obviously solve as it can be proved that the data was sent legitimately from your form. Using POST instead of GET will make this attack very difficult.

A Session Hijack on the other hand is where someone can use your session, become 'you' and use your account which will allow them to do whatever they please.

Once a malicious user has access to this session a CSRF attack is pretty much useless as it is not needed.

If you are worried about your session ids being hijacked then you can take some precautionary measures such as regenerating a users session id once they are elevated to a higher level of access. This can be done using the session_regenerate_id() PHP function. You can also check the User Agent of the browser to check if there are changes and if there are then you can simply ask the user to login and regenerate the id so it is then unknown to the attacker. Obviously there is always a chance that they will be the same user agent but it does limit the risk significantly. Encryption such as SSL/HTTPS are also an option that you may want to look at

For more information you should check out this link for some examples: http://phpsec.org/projects/guide/4.html. Hopefully this has solved your problem :)

Upvotes: 2

gview
gview

Reputation: 15411

Session variables are stored on the server. They can not be read. However, a session can be hijacked typically by an attacker getting access to the session id of another user, and can then use that session id to impersonate them (hijack) their session.

CSRF is an entirely different concern. CSRF exploits get users to inadvertantly perform operations in a manner similar to xss exploits: I might post a bogus img link where the src is actually a url that passes parameters to a script that your browser runs on your behalf. In that case the attacker is simply getting your browser to make a request you didn't intend it to. The CSRF protection should stop this, because the user does not know what the token is, so they can't embed it into the url.

Upvotes: 0

Robin Castlin
Robin Castlin

Reputation: 10996

Correct me if I'm wrong, but I'm quite sure you simply can't hijack $_SESSION values because these, unlike $_COOKIE is saved on the server and not in the webbrowser.

Therefor they can't change it either. They can close their webbrowser to remove it, but not edit it.

Upvotes: 0

Related Questions