How do cookie and session implement for preventing reuse elsewhere

Question

I have some scenarios:

• A cookie is generated on Chrome and will be used in Firefox in the same machine.
• A cookie is generated on Chrome and will be used in Chrome on a different machine.
• A cookie is generated on Chrome and will be used in Firefox on a different machine.

In above scenarios, can cookie be reused? If not, how to implement a session/cookie to prevent reuse in those scenarios?

In my opinion, I think a session-cookie is implemented by:

1. server stored a key-value pair so: key for identity user. and value for store user data, expired session time ...
2. client will store cookie, in that cookie contains key on server.

So above attacks can be prevented by value object stores something such as "browser type", "machine name" (getting ssh value by some way). Every time user requests something, server will get browser type, machine name, cookie and check all data for validity.

But what is the problem if attacker can fake the browser type, machine name? For example, using Firefox but sending Chrome-details as browser-agent instead.

Answer 1

You should think about threat models instead of coming up with solutions to fake problems.

What's the threat model here? That I copy my own session cookie to another computer? Not a real threat.

Worried about javascript stealing cookies? Use httponly cookies

Worried about malware stealing your cookies? Use a dedicated computer for sensitive network communications. You can get a Raspberry Pi Zero Wireless for $10

Answer 2

You can not validate the used Browser and Machine Name (dont know at all how to get it), because all of that is send by the client, so an attacker can send what he want.

The security relies only on the session id, a long, random and unique id generated on the server and stored in the cookie.

You should give all the different machines where the user logs on a new session Id and not reuse an existing one, because if the user logs out on one machine you delete only that session id on the server and the user is not logged out on all of the other machines.

The only way for an attacker is to steel the session id stored on the user machine, but that requires a big security hole on the machine.

Answer 3

I do not really understand your attacks. They are stated very vaguely. At risk of seeming pedantic, I would strongly suggest you avoid using the passive voice when describing behavior in a technical context.

Let me try to rewrite for you:

A cookie is generated on Chrome and will be used in Firefox in the same machine.

If you mean

"A legitimate user uses Chrome to access my site, which issues a session cookie. A malicious user copies the session cookie into the cookie store for Firefox, and accesses the site from there, thereby impersonating the legitimate user."

My answer to this: There is no mitigation in the world that will protect you from a malicious user with access to the legitimate user's machine.

If you mean

"A malicious user uses Chrome to access my site, which issues a session cookie. The malicious user copies the session cookie into the cookie store for Firefox, and accesses the site from there."

My answer to this: What does it matter if the malicious user is using Chrome or Firefox?

Anyway, please be specific about the threat you are assessing.

Also, be aware that all browsers maintain independent cookie stores, so there would have to be purposeful activity for session cookies to leak between them.

Answer 4

I thought each browser stores their own cookies. I have tested my lab's persistence using cookies with servers behind a load balancer so I don't face the scenarios you are facing. Getting a load balancer to front your servers seem like a wise choice, you can consider.

I have tried using different browsers on same client computer accessing the same site and I was load balanced to different web servers using cookie persistence. Unless I have used persistence based on source IP, every browser will go to the same web server.

Answer 5

PHP Cookies are very safe when your site uses HTTPS (the S is for Secured) with a sufficiently complex key in the SSL certificate. PHP instructs your browser's PHPSESSID cookie to contain the file name of the $_SESSION variable. Calling session_start(); loads the file directed to by the browser's PHPSESSID cookie into the $_SESSION variable. Nevertheless, it still is possible to impose an additional IP address validation by storing the user's IP address inside the session file. Observe.

<?php
session_start();

if (array_key_exists('V_CI', $_SESSION)) {
   // Validate that an existing session is still from the same PC
   if (
       $_SESSION['V_CI'] !== $_SERVER['HTTP_CLIENT_IP'] ||
       $_SESSION['V_XFF'] !== $_SERVER['HTTP_X_FORWARDED_FOR'] ||
       $_SESSION['V_XF'] !== $_SERVER['HTTP_X_FORWARDED'] ||
       $_SESSION['V_FF'] !== $_SERVER['HTTP_FORWARDED_FOR'] ||
       $_SESSION['V_F'] !== $_SERVER['HTTP_FORWARDED'] ||
       $_SESSION['V_RA'] !== $_SERVER['HTTP_REMOTE_ADDR'] ||
       $_SESSION['V_UA'] !== $_SERVER['HTTP_USER_AGENT']
   ) session_regenerate_id( false );
}
if (!array_key_exists('V_CI', $_SESSION)) {
    // we are filling a newly created key
    $_SESSION['V_CI'] = $_SERVER['HTTP_CLIENT_IP'];
    $_SESSION['V_XFF'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
    $_SESSION['V_XF'] = $_SERVER['HTTP_X_FORWARDED'];
    $_SESSION['V_FF'] = $_SERVER['HTTP_FORWARDED_FOR'];
    $_SESSION['V_F'] = $_SERVER['HTTP_FORWARDED'];
    $_SESSION['V_RA'] = $_SERVER['HTTP_REMOTE_ADDR'];
    $_SESSION['V_UA'] = $_SERVER['HTTP_USER_AGENT'];
}

I abbreviated all of the above session variables to conserve space on your hard disk. This will especially come in handy if you apply the above PHP code to every user that visits your website.

Obviously, the above code will not do diddly if someone gets direct access to your server computer because they could bypass whatever security measures you have in place. Aside from this problem, the code above does take security to the next level in whatever PHP script you drop the code into.

Notice that the code above also stores the user agent string. In my mind, the user agent string is far too easy to fake. Additionally, this user agent string will change when the user updates their browser. Additionally, user agent strings are usually very long, so they bloat the size of the session files. Thus, I suggest using the below code which does not compare the user agent string.

<?php
session_start();

if (array_key_exists('V_CI', $_SESSION)) {
   // Validate that an existing session is still from the same PC
   if (
       $_SESSION['V_CI'] !== $_SERVER['HTTP_CLIENT_IP'] ||
       $_SESSION['V_XFF'] !== $_SERVER['HTTP_X_FORWARDED_FOR'] ||
       $_SESSION['V_XF'] !== $_SERVER['HTTP_X_FORWARDED'] ||
       $_SESSION['V_FF'] !== $_SERVER['HTTP_FORWARDED_FOR'] ||
       $_SESSION['V_F'] !== $_SERVER['HTTP_FORWARDED'] ||
       $_SESSION['V_RA'] !== $_SERVER['HTTP_REMOTE_ADDR']
   ) session_regenerate_id( false );
}
if (!array_key_exists('V_CI', $_SESSION)) {
    // we are filling a newly created key
    $_SESSION['V_CI'] = $_SERVER['HTTP_CLIENT_IP'];
    $_SESSION['V_XFF'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
    $_SESSION['V_XF'] = $_SERVER['HTTP_X_FORWARDED'];
    $_SESSION['V_FF'] = $_SERVER['HTTP_FORWARDED_FOR'];
    $_SESSION['V_F'] = $_SERVER['HTTP_FORWARDED'];
    $_SESSION['V_RA'] = $_SERVER['HTTP_REMOTE_ADDR'];
}