Work with Session without cookies to prevent session theft

Question

Work with Session without cookies to prevent session theft

Asked 9 years, 8 months ago

Viewed 5,413 times

31

When the session is started, it creates a cookie with PHPSESSID, making the ID public. Knowing that to prevent session hijacking it is best to hide the session ID from other users, then PHPSESSID becomes a starting point for an attack. One can resort to session.name and session.hash_function, but still a cookie with an ID is easy to find.

For example, if I create a session['nome'] = Fulano de tal for a user named So-and-so, theoretically, only he will have access to Session. The problem is that if Johnny alter the PHPSESSID with the value of So-and-so, he will have access to the created Sesssions. Cookie PHPSESSID are susceptible to misuse by others, or even an infected machine.

I’m trying to make use of séssions without the creation of cookies, tried session.use_cookies = 0 but all accesses generate a new ID and the sessions that were saved are lost.

I would really like to use Sesssions 100% out of customer reach. I thought to set session.use_cookies = 0 not to make use of cookies per session, and to use session_save_path, to manage user sessions, to implement more checks.

Is there any way in PHP to work with sessions without the need for cookie creation?
Taking into account that the cookie is allocated to the customer, it would be his - and only him - the responsibility to not allow it to be public, that is, someone on a public machine should log out, or the user using a personal computer should keep it free of infections that can track their Ids. This issue was based on facebook, where I entered another account changing cookies. It was my other old Facebook account, no fear.

1

Have you considered comparing the remote IP and user agent, and in case of inconsistency, destroy the Session?

– Jader A. Wagner

2014/10/13 at 10:30
1

+1 Very good question.

– Jorge B.

2014/10/13 at 10:32
@Jader, but if I store it in a cookie it can be cloned, and if you store it in Session you can compare it to the 'stolen'. Or did I get it wrong?

– Papa Charlie

2014/10/13 at 10:33
You save the IP and the user agent in Session, and compare it to the $_SERVER variables in the next request...

– Jader A. Wagner

2014/10/13 at 10:36
2

@Jader, very interesting, $_SERVER has some unreliable variables. The IP itself is not 100%. user agent might even serve as a SALT.

– Papa Charlie

2014/10/13 at 10:39
Certainly, but it’s better than nothing... Using various checks together can be quite safe... And in a general context of your question it seems to me that you are confusing kidnapping Session with hijacking a cookie containing login and password, and in this case a new logged in Sesssion is created...

– Jader A. Wagner

2014/10/13 at 10:42
Changing the PHPSESSID cookie immediately allows access to sessions. I can do more background checks within the system, but wanted to know a way to create sessions without the need for cookie to manage ID.

– Papa Charlie

2014/10/13 at 10:44
The cookie only serves to hide the Session id from the URL... Changing the cookie would be the same as changing it directly from the URL...

– Jader A. Wagner

2014/10/13 at 10:46
Yes, and this is the recommendation not to use ID as a parameter in the URL. And to use a cookie for this for me is to exchange 6 for half a dozen :)

– Papa Charlie

2014/10/13 at 10:48
Please understand that if you do not pass Session id as a cookie, you will be required to go through the URL... Then a check on each request if it is still the same client is mandatory in any case...

– Jader A. Wagner

2014/10/13 at 10:50
2

Related: http://answall.com/questions/26610/howto function a-sess%C3%A3o-in-web browsers? Rq=1, http://answall.com/questions/33740/preven%C3%A7%C3%A3o-Session-Hijacking? Rq=1 (duplicate?)

– bfavaretto

2014/10/13 at 11:12
I don’t think it’s duplicate, my intention was a way to work with Session without cookie, without delving into Hijacking. Session theft was a way to show the cookie ID - which you would like to avoid.

– Papa Charlie

2014/10/13 at 11:17
@Papacharlie the session control in Php comes with the identifier that the browser stores... That’s the process. Let the server side control the session and all its variables. Hijacking, for me the best defense is SSL. Read my answer in the link that bfavaretto puts.

– chambelix

2014/10/13 at 14:22
@chambelix. I intended to take care of the session robberies juxtaposing taking the session basis without cookie. So I wanted to know if it was possible for PHP to give this "force". Apparently it will be under the same nail - I will scan all the answers. Even so, thank you.

– Papa Charlie

2014/10/13 at 20:30
@Papacharlie Look... if it helps you... I just developed for an identity system.. Multi-server scalable session control... Content persistent in database and volatile in memcached. I force SSL but do not fail to implement verifications http_User_agent among others. I did not dispense with a token system, renewing the id at certain points of the service. In conclusion at the same nail. Compliments

– chambelix

2014/10/14 at 08:08
@chambelix, legal. Will make available somewhere?

– Papa Charlie

2014/10/14 at 19:43
1

@Papacharlie is a job I was hired to do... But I am available if you need some help with some guidance with your code in a solution because despite the implementation monitoring is a constant... So we must always have our knowledge updated... Regards

– chambelix

2014/10/15 at 07:50

Show 12 more comments

2 answers

14

Is there any way in PHP to work with sessions without the need for cookie creation?

Yes, it is possible to work without allocating your session id to a cookie. However, because HTTP is stateless (each request is independent of the other), this id must be passed on somehow, and this second way would be via the URL.

Extracted from the php documentation:

A visitor accessing your web site gets a unique identifier, the so-called session id. This is saved in a cookie on the side of the user or propagated via URL.

This configuration is possible from the session.cookie_httponly

Taking into account that the cookie is allocated to the customer, it would be of it - and only of it - the responsibility not to allow it to be public, that is, someone on a public machine should log out, or the user using a personal computer should keep it free from infections that can track your Ids. This issue was based on facebook, where I entered another account changing cookies. It was my other old facebook account, no fears.

Basically yes. What you can do to minimize this risk of Session hijacking is to take some actions on the server side to disable unauthorized use of this cookie.

Some actions like regenerating session id with session_regenerate_id or request a new authentication make cookie hijacking simply unfeasible.

Some articles (in English) that may help you implement your application’s security

Preventing Session Hijacking when using PHP

Stopping Session Hijacking

Cookie Theft/Session Hijacking

1

Here are two answers that can complement your answer: http://answall.com/questions/3571/qual-o-jeito-de-fazer-um-sistema-de-login-em-senha-com-php/3604#3604 e http://answall.com/questions/33664/rememberingUsu%C3%A1rio-com-seguran%C3%A7a/33684#33684

– KaduAmaral

2014/10/13 at 11:22
It is strange that Sesssions are recommended for sensitive data, and depend on the cookie to manage the ID. PHP could use the mechanism to identify the session in the cookie and/or path using session_save_path.

– Papa Charlie

2014/10/13 at 11:28
1

@Papacharlie believes that this behavior is more connected to the nature of HTTP in not allowing the state to be stored between requests. No . net we have the same behaviour php, storing the session id in cookies.

– gmsantos

2014/10/13 at 11:40

Browser other questions tagged php security-guard session cookies

You are not signed in. Login or sign up in order to post.

by mgibsonbr • **80,631** points · Answer 1 · 2014-10-13T17:59:12+00:00

It seems to me that you are seeking something impossible. Before answering your question, let me ask another similar question:

When you register on a website you create a username and password. Knowing that to prevent account theft it is best not to share your password with other users, then the field password becomes a starting point for an attack. If Alice creates a password, theoretically only she will have access to your account, the problem is if Bob logs in with username and password of Alice. Passwords are susceptible to misuse of third parties, or even an infected machine (keylogger, for example).

Is there any way to manage user accounts without the need to use passwords?

Put this way, it is evident (I hope!) that there is not much to do... The application is expected to use passwords correctly (use SSL, do not send them by GET, clean them after use), expected from browser manipulate them correctly (do not save them to file, hide the characters typed in a field password) and the computer/device is expected to be infection-free (no keylogger, does not intercept the password in the browser even before it is encrypted, etc). And of course, the user is expected not to share his password with third parties.

These risks will always be present when using passwords. You you can even choose not to use them, but then you would have to bear the costs not to do so (e.g.: use a hardware module to authenticate users - which can be stolen - use a HOTP/TOTP code generator - idem - use a digital certificate on the client side - Ibidem) - the main one being the inconvenience to users. This option should be based on a cost-benefit analysis, not on a quest to eliminate risks at any cost (why not require users to physically move to your company to use your system, in their view?).

A cookie - especially one that is HttpOnly (i.e. inaccessible via Javascript) plus of course Secure (is only transmitted via HTTPS) - it is the most secure and convenient way that a common web application has to re-use the user (i.e. knowing that the Y request was sent by the same user who previously sent you the X request - this containing your username and password). One can of course vary a little the tradeoff cited, for example:

Placing a secret token (i.e. the session ID) in the URL itself, such as pointed out in the reply of the gmsantos. The disadvantages are:
1. The URL can be cached, increasing the exposure of this ID;
2. If the user opens the site in another tab, it will not necessarily be authenticated (if it entered directly, without following a link containing that ID).
Keeping the session ID in memory only; this would require a "single-page" application where all communication with the server is done via Ajax, and the session ID is in a Javascript variable - sent along with the POST parameters for each request. Disadvantages:
1. All communication would have to take place via POST, to prevent the ID from ending up in the URL as in the case above;
2. The use would be restricted to a single tab of the browser, unless it implemented communication between different tabs (complicated, and still brings additional risks);
3. Decreases the risk of ID ending up on file, but makes it more susceptible to XSS.
Storing the session ID on SessionStorage; similar to the two above cases (because this ID would still have to be sent back to the server in some way), and still has the risk of data ending up in file anyway (if the browser crashes, then another user could "restore the session" - already starting authenticated as the original user).
Re-using the user on each request! So you don’t need a session ID (not even a session!), just require the user to enter their password again, and again, and again...

etc. One can think of other ways, but in my view none of them would be significantly different from the use of cookies, because:

If the machine is infected, it’s gone! Nothing less than a hardware module will protect you in this case, and yet limited to a few scenarios;
If the solution involves file-saved data, any root user can access it (just as a root user can steal the cookie jar browser);
A "honest" browser honors the same origin policy (i.e. no other source - scheme, domain and port - can access these cookies), does not improperly expose a cookie HttpOnly to Javascript, or send a cookie improperly Secure without the proper protection. A "rogue browser" (say, a user making direct access via Curl for example) on the other hand could make misuse of all data regardless of how it is stored.

In conclusion, my position is that working without cookies is not the best way to ensure the security of your application. Instead, try to narrow down the "window of opportunity" for session hijacking (via session_regenerate_id, as already suggested, and/or invalidating the session after X minutes of inactivity) and may increase the requirement to perform critical actions in the system (e.g.: to exchange password, ask for the original password again, even if the sitting is valid). Take appropriate care, but don’t worry too much about the risks inherent in the use of cookies - these would be the same everywhere except for the safest (and expensive) solutions.