I took last week off due to the holiday and what not. So this week we will pick back up where we left off, and hopefully continue adding a post a week. Two weeks ago we stopped at ASVS 3.9, this week we will start with ASVS 3.10 and finish up ASVS section 3.

ASVS 3.10 Requirement:

Verify that only session ids generated by the application framework are recognized as valid by the application.

ASVS 3.10 Solution:

Utilize the session functionality built within PHP; this should prevent an attacker from using a session ID that was not generated by PHP. To prevent an attacker from guessing a valid session ID, use the strong session security features of PHP. Use a strong hash function such as sha512 with this php.ini configuration:

    session.hash_function = 'sha512'

 
Use the widest range of bits when representing the binary session ID in a readable form:

    session.hash_bits_per_character = 6

 
Use a strong source of randomness to create the session ID:

    session.entropy_file = /dev/urandom

 

Read more about these options here. Learn how to identify the hashing algorithms available for your platform here.

For additional security, you can prevent session fixation attacks (using a previously valid session ID and setting it for a victim via a phishing attack or something similar) with a number of countermeasures.

1. First, make sure that sessions are only transmitted in cookies, and never by URLs by reviewing the ASVS 3.6 solution in our last post.
2. Next, make sure that session IDs are changed after authentication and destroyed after logout. The solution for this is found in our last post covering ASVS 3.7, 3.8, and 3.9.
3. Finally, do not rely on the fact that a session exists by only calling session_start(). Make sure that valid session values have been set (these should be set with $_SESSION[‘user’] = variable in your authentication code):

    // Validate that the user and pass session variables have been set.
    // If not, the session is not valid and should be destroyed, and the
    // user should be redirected to the login page.
    if (!isset($_SESSION['user']) || !isset($_SESSION['pass'])) {
        session_destroy();
        $_SESSION = array();

        if (ini_get("session.use_cookies")) {
            $params = session_get_cookie_params();
            setcookie(session_name(), '', time() - 42000,
                $params["path"], $params["domain"],
                $params["secure"], $params["httponly"]
            );
        }

        session_regenerate_id(true);
        header('Location: login.php');
        die();
    }

 
ASVS 3.11 Requirement:

Verify that authenticated session tokens are sufficiently long and random to withstand attacks that are typical of the threats in the deployed environment.

ASVS 3.11 Solution:

See the information above that describes how to configure PHP to use a strong algorithm and source of randomness.

ASVS 3.12 Requirement:

Verify that cookies which contain authenticated session tokens/ids have their domain and path set to an appropriately restrictive value for that site.

ASVS 3.12 Solution:

This will limit where the cookie can be utilized. Cookie paths can be set globally in php.ini with the following directives:

    // Set the cookie path
    session.cookie_path = /path/that/cookie/applies
    // Set the domain path
    session.cookie_domain = www.mysite.com

 
This can also be set at the application level with a call to session_set_cookie_params():

    // Set the lifetime of the cookie to 15 minutes, set the path to 
    // /securesite/admin, set the domain to www.mysite.com, then 
    // set the secure and httponly flags (discussed later).
    session_set_cookie_params(
        900,
        '/securesite/admin',
        'www.mysite.com',
        true,
        true
    );

 
ASVS 3.13 Requirement:

Verify that all code implementing or using session management controls is not affected by any malicious code.

ASVS 3.13 Solution:

Scan your code for viruses, or any malicious backdoors. Perform manual and automated code reviews.

Bonus!:

Two other requirements are found in the OWASP ASVS that I believe are relevant to protecting sessions. These are found in V11 – HTTP Security Verification Requirements. The specific requirements are ASVS 11.4 and 11.5.

ASVS 11.4 & 11.5 Requirement:

Verify that the HTTPOnly flag is used on all cookies that do not specifically require access from JavaScript.

Verify that the secure flag is used on all cookies that contain sensitive data, including the session cookie.

ASVS 11.4 & 11.5 Solution:

These values help protect sensitive cookie data. The HTTPOnly flag prevents the cookie from being accessed by client side code (such as JavaScript), if the client browser supports the flag. This mechanism helps protect the cookie in the event that a cross-site scripting (XSS) flaw exists in the application. The secure flag prevents the cookie from being sent over a clear-text (non-encrypted) HTTP connection.

These flags can be set in the php.ini file globally:

    // Set the httponly flag
    session.cookie_httponly = true
    // Set the secure flag
    session.cookie_secure = true

 
Alternatively, this can be set in the application code with a call to session_set_cookie_params() as seen in the solution to ASVS 3.12.

Next week we will begin covering authentication controls that most applications should implement.