We covered OWASP ASVS 3.1, 3.2, and 3.3 in our previous post. I will continue where we left off, beginning this week’s post with ASVS 3.4.
ASVS 3.4 Requirement:
Verify that sessions timeout after an administratively-configurable maximum time period regardless of activity (an absolute timeout). I am not sure that this is a security requirement for most applications, but the intent here is to make a user re-authenticate after a certain period of time regardless of activity.
ASVS 3.4 Solution:
Review my first post for a similar concept. You would need to create a session variable that is initialized at each login with something like this:
$_SESSION['Login_Time'] = time();
Then, you need to compare the current time with the initial login time. This could be validated in a header file.
The steps in PHP are:
- Check to see if the session variable used to track activity has been set. If not, destroy any session data and redirect to the login page.
- Check to see if the current time minus the time recorded for the initial login is greater than 86,400 seconds (24 hours). If the timer has been exceeded, then destroy any session data and redirect to the login page.
The following code can be placed in a header file that is included by every page:
// Check to see if the session variable used to track the login time has been set, // if not then destroy all session data and redirect to the login page. If it has // been set, compare current time minus the last activity time, and if it is // greater than 86,400 seconds (24 hours), then destroy session data and // redirect to the login page. if (!isset($_SESSION['Login_Time']) || ((time() - $_SESSION['Login_Time']) > 86400)) { 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"] ); } header('Location: login.php'); die(); }
This could be AJAX-ified similar to what we did last week.
ASVS 3.5 Requirement:
Verify that all pages that require authentication to access them have logout links.
ASVS 3.5 Solution:
Another easy fix requiring little code; add a link to the logout page on each page for which the user must be authenticated. This enables users to easily logout of their session and thus destroys associated session data.
ASVS 3.6 Requirement:
Verify that the session id is never disclosed other than in cookie headers; particularly in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.
ASVS 3.6 Solution:
This requirement reduces the likeliness that an attacker can gain access to session ID’s. Part of this requirement can be satisfied with the right PHP configuration. Configure your php.ini file with the following settings:
// PHP will use cookies for maintaining session state session.use_cookies = 1 // PHP will only use cookies to store session ID's on the client side session.use_only_cookies = 1 // Disable PHP's support for URL based sessions session.use_trans_sid = 0
If you must include a session ID in form data for some reason, use the HTTP POST method, so that it will not be logged on the server side (GET requests are logged).
ASVS 3.7 & 3.8 Requirements:
Verify that the session id is changed on login.
Verify that the session id is changed on reauthentication.
ASVS 3.7 & 3.8 Solution:
This requirement helps prevent session fixation attacks. If an attacker were to trick a user into visiting the application and the session ID is part of the URL, then changing the session ID upon login will prevent a successful session fixation attack. Add the following snippet of source after the code on your login page in which a user’s authentication is validated:
// Generate a new session ID and assign it to the current session session_regenerate_id(true);
ASVS 3.9 Requirement:
Verify that the session id is changed or cleared on logout.
ASVS 3.9 Solution:
Add the code above for ASVS 3.7 and 3.8 to the logout page:
session_regenerate_id(true);
This code could come before the redirect to the login page found in our previous post for ASVS 3.2.
Next week we should finish up ASVS section 3.x. We will then cover the authentication requirements in ASVS section 2.x to wrap up our discussions on OWASP A3 – Broken Authentication and Session Management.
Leave a Reply