Reliability and Security of Sessions

Question

I’ve been reading a little bit about security with sessions (both in ASP.NET and in PHP), and I read in some places that sessions, especially in PHP, can be easily stolen (even more easily if the system is being used in local network).

Since it’s common practice (correct me if I’m wrong) to set user access to the session, when they log in to the system, how can I make this access more secure? Is session encryption valid? It’s good security practice to keep diverse data in session?

Answer 1

To session (PHP standard) is based on the following way:

• The client has an identifier based on cookies (or URL parameter).
• The server has a file in the temporary folder, this file has "the contents" of the session.

I’ll also tell you how to mitigate this, if applicable.

First understand that your server generates a cookie containing a session identifier (*default the cookie name is PHPSESSID) and all subsequent requests within the website will send such identifier.

---

Common vulnerabilities:

Packet Sniffing/MITM:

An "attacker" will do a MITM (man-in-the-Middle) to get this cookie, it can use DNS Spoofing (DNS Poisoning...), Proxy Attacks, ARP Spoofing...

The goal is the same, in MITM is to get the user session by directly intercepting the connection and "decrypting" the connection, if necessary and possible. MITM is a type of Sniffing.

How to fix the problem:

• Use only TLS 1.2 (and 1.3) in all communications (do not use Sslv2!).

• Use only cookies and never pass this value by any other means.

• Use the HPKP (HTTP Public Key Pinning) header so your browser will only trust your SSL certificate.

• Use the cookies with the flags of Secure.

• Use the cookies just where you need, static files pass to a sub-domain (css.site.com).

• Be careful: keep the private key of the SSL certificate in a safe place.

Client-side Attacks:

You know the famous XSS? So it can also compromise your website, causing an attacker to create malicious Javascript that captures browser cookies, this is the "most common" case of XSS attacks.

The basic idea is to obtain on the client side the information of the cookie, you cannot in fact protect the user from all threats, for example if the user is infected with malware, is using a malicious extension, or is using a modified browser "maliciously".

_{More and more complex cases allow the attacker to make the famous side-attack, see more here, this COULD allow obtaining such session identifiers.}

Within your responsibility you can:

• Use the cookie with the attribute of HttpOnly and SameSite, to prevent the reading of cookie in the case of XSS and that the cookie be passed to another website.

• Use the attribute domain of cookie for your domain only (not including subdomains!).

• Use the header of X-XSS-Protection and Content-Security-Policy to prevent a code injected by XSS from communicating with another server.

• Use the attribute of Integrity, in HTML, to check whether the <script> dynamically loaded was not changed by malicious code.

• Be careful with: internal redirects to external link and Filter all data received from users, to avoid XSS and do not open links using _blank.

Predictable Token:

This is more rare, unless do some gambiarra. This is mainly by using a bad random generator, example /dev/random or CSPRNG that comes from a "userspace Csprngs" instead of the Kernel, such as using Openssl, with your MD5 and bugs on Debian Linux, as occurred with application Android that generated Bitcoin wallets based on Userspace... Particularly do not opt for Userspace.

The apex of predictability would be:

• Generate identifiers sequential as "1,2,3,4...", this allows knowing which is the next identifier, thus facilitating access in other accounts.

• Generate identifiers based on the email/user itself.

To fix this generate random identifiers, CSPRNG:

• Utilize /dev/urandom (PHP 7.1 standard+).
• Use long strings (at least 32 Bytes) to make difficult kick one-session.

---

General:

Final considerations, if prioritizing safety also consider:

• Generate a new session (session_regenerate_id) for the same user already connected from time to time (e.g. 5 in 5 minutes).
• Limit session usage to only one specific IP (harm: unstable connections will "dislodge" at any time).
• Limit session usage to just one browser and geolocation.
• Limit the duration of a session to a few minutes of inactivity.

If you really want security above all else, consider:

• Using websockets instead of cookies.

As an additional:

• Require the use of 2FA (e.g. TOTP) for confirmation actions that may compromise the integrity of the account (e.g. TOTP. delete account, change password, change email, delete post...).

---

Just to remind did not mention problems that your server may have in exposing the content of sessions, I have only indicated problems that may expose the session identifier. For example, if you are sharing the same server (the machine) with other people, that is, several virtual machines, all will use the same RAM and CPU cache, enabling side-Channel attacks. In other cases if your server has been hacked in any way, you can read the contents of the session files, usually located at tmp. Also if using the exec() or file() based on user input (and not treated correctly) can make the attacker get the session files (and their identifiers).

Answer 2

You do not have an authentication solution that does not use cookies. PHP Session is a cookie in the browser that is stored on PHPSESSID. Then PHP creates a data structure matching the session value with the data you saved in it. A Session hijack is when you copy the value of PHPSESSID from one browser to another.

Only, to steal Septssion, they usually use an attack man in the Middle, where they capture the browser request before proceeding to your server and therefore the cookie comes along. The only solution to solve this, is using HTTPS in communication with the server, which keeps the request encrypted.

It wouldn’t do you any good to encrypt Session, because it’s there on the same server, but it’s also important not to store sensitive data (passwords, personal information) for security.