Asked  7 Months ago    Answers:  4   Viewed   32 times

I know this topic has been discussed a lot, but I have a few specific questions still not answered. For example:

// Prevents javascript XSS attacks aimed to steal the session ID
ini_set('session.cookie_httponly', 1);

// Adds entropy into the randomization of the session ID, as PHP's random number
// generator has some known flaws
ini_set('session.entropy_file', '/dev/urandom');

// Uses a strong hash
ini_set('session.hash_function', 'whirlpool');

// Session ID cannot be passed through URLs
ini_set('session.use_only_cookies', 1);

// Uses a secure connection (HTTPS) if possible
ini_set('session.cookie_secure', 1);


// If the user is already logged
if (isset($_SESSION['uid'])) {
    // If the IP or the navigator doesn't match with the one stored in the session
    // there's probably a session hijacking going on

    if ($_SESSION['ip'] !== getIp() || $_SESSION['user_agent_id'] !== getUserAgentId()) {
        // Then it destroys the session

        // Creates a new one
        session_regenerate_id(true); // Prevent's session fixation
        session_id(sha1(uniqid(microtime())); // Sets a random ID for the session
} else {
    session_regenerate_id(true); // Prevent's session fixation
    session_id(sha1(uniqid(microtime())); // Sets a random ID for the session
    // Set the default values for the session
    $_SESSION['ip'] = getIp(); // Saves the user's IP
    $_SESSION['user_agent_id'] = getUserAgentId(); // Saves the user's navigator

So, my questions are

  • do the ini_set's provide enough security?
  • is it okay to save the user's IP and navigator and then check it every time the page is loaded to detect a session hijack? Could this be problematic in any way?
  • is the use of session_regenerate_id() correct?
  • is the use of session_id() correct?



Your configuration is awesome. You definitely read up on how to lock down php sessions. However this line of code negates a lot of the protection provided by your php configuration: session_id(sha1(uniqid(microtime()));

This is a particularly awful method of generating a session id. Based on your configurations you are generating the session id from /dev/urandom which is a awesome entropy pool. This is going to be a lot more random than uniqid() which is already mostly a timestamp, adding another timestamp to this mix doesn't help at all. Remove this line of code, asap.

Checking the IP address is problematic, ip addresses change for legitimate reasons, such as if the user is behind a load balancer or TOR. The user agent check is pointless, it is like having a GET variable like ?is_hacker=False, if the attacker has the session id they probably have the user agent, and if they don't this value is really easy to brute force.

Wednesday, March 31, 2021
answered 7 Months ago

the php-memcached extension supports session locking

the memcache and memcached extensions look syntactically similar so it may not be too much of a headache to give it a try. (memcached has a stable version 2.1.0 released 2012-08-07).

if you are set on using memcache 2.2.7 you will most likely have to implement the lock yourself by setting some "session_is_locked" variable in your session and then releasing/unsetting it when the script is done writing to the session. Then you'd always need to check if that variable is set before continuing with any scripts which write to the session.

Wednesday, March 31, 2021
answered 7 Months ago

Read OWASP A3-Broken Authentication and Session Management. Also read about OWASP A5-CSRF, which is sometimes called "session riding".

You should use this code in a php header file:


This code prevents session fixation. It also helps protect against xss from access document.cookie which is one way that Session Hijacking can occur. Enforcing HTTPS only cookies is a good way of addressing OWASP A9-Insufficient Transport Layer Protection. This way of using HTTPS is sometimes called "secure cookies", which is a terrible name for it. Also STS is a very cool security feature, but not all browsers support it (yet).

Thursday, June 17, 2021
answered 5 Months ago

Check out this snippet from the Session Overview documentation:

System.Web.SessionState.HttpSessionState.SessionID values are sent in clear text, whether as a cookie or as part of the URL. A malicious user could get access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID value.

It seems to me that this means that there is no security baked into Session, so you probably shouldn't use Session as a security measure. Instead, I would recommend relying on ASP.NET security (authentication, authorization).

Here is an article from the Patterns & Practices group on general security recommendations for ASP.NET.

Thursday, August 12, 2021
The Coding Wombat
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :