The fourth post of the series is about session management tests. As we mentioned before, HTTP is a stateless protocol. That means, 2 requests, sent from the same client, have no any relation. But today, the websites are mostly interactive and status information, that is, the information that is required for ‘the user to be recognized during HTTP requests’ is of vital importance.

Because the HTTP protocol does not contain such information by its design, software engineers have developed their own methods to provide session management. The most important and most widely used of these methods is that a unique session information generated by the server is sent to each client individually and the clients introduce themselves to the website using this unique information in following HTTP requests.

While session management had to be implemented by developers in the past, most of the tasks are now handled by application servers. And so, the developers have been saved from such an important and difficult responsibility. Bu still developers have to manage ‘some important tasks of session management’ such as starting and ending the session. Mistakes done in the session management allow us perform some attacks.

Checklist for Session Management Tests

1. Session Fixation – Renewing session token after login.
   1. If the user has a session token before she logged in to the application, the token must be renewed after login. Otherwise, we can talk about session management flaws.
      • If the session information is transported in URL, session fixation attack can be realized, for example, sending phishing email contains the URL which has the session token.
      • If the session information is transported in POST requests, we may enforce the victim to login with our session token using CSRF attack.
2. Contents of Cookies

   Set-Cookie: SESSIONID=iojew984389hui78g; path=/appl/portal; secure; HttpOnly

   1. The cookie must contain the “HttpOnly” option. This option prevents browsers from accessing cookie information using JavaScript code.
   2. If the application is served over SSL, “secure” option should be used.
   3. The “Path” parameter should point the protected area. If this path is called directly, the internet browser will send the cookie information.
3. Session Expiration
   1. Check if there is a timeout mechanism
   2. Application must have logout method.
   3. Check if the user logouts when the browser is closed without logging out.
   4. The session should be terminated when an unexpected error occurs.
4. CSRF – Cross Site Request Forgery
   CSRF can be summarized as a victim visiting a site created by an attacker and attacker performing an action on behalf of the victim by sending an arbitrary GET or POST request through the victim’s browser.
   To test the application for CSRF

    

   1. Build an html page containing the HTTP request referencing the target URL;
   2. Make sure that the valid user is logged on the application;
   3. Induce the victim into following the link pointing to the URL to be tested (impersonate the victim, or use social engineering);
   4. Observe the result, i.e. check if the web server executed the request.