Session ID flaws


Home > Cyber Security Solutions > Various-Security-Offerings > Penetration Test > Specialized Pen Testing > Web Portals > Session ID flaws

In computer network security, session fixation attacks attempt to exploit the vulnerability of a system which allows one person to fixate (set) another person's session identifier (SID). Most session fixation attacks are web based, and most rely on session identifiers being accepted from URLs(query string) or POST data.
Valency Networks provides security by giving solution as:

  1. Do not accept session identifiers from Get/Post methods.
    Session identifiers in URL (query string, GET variables) or POST variables are not recommended as they simplify this attack – it is easy to make links or forms which set GET / POST variables.
    Additionally, session identifiers (SIDs) in query strings enable other risk and attack scenarios;
    Cookies are shared between tabs and popped up browser windows. If your system requires to be hit with the same domain (www.example.com?code=site1 and www.example.com?code=site2 ), cookies may conflict with one another between tabs.
  2.  Identity Confirmation
    This attack can be largely avoided by changing the session ID when users log in. If every "important" request requires the user to be authenticated with ("logged into") the site, an attacker would need to know the id of the victim's log-in session. When the victim visits the link with the fixed session id, however, they will need to log into their account in order to do anything "important" as themselves. At this point, their session id will change and the attacker will not be able to do anything "important".
    A similar technique can be used to solve the phishing problem. If the user protects their account with two passwords, then it can be solved to a great extent.
  3. Store session identifiers in HTTP cookies 
    The session identifier on most modern systems is stored by default in an HTTP cookie, which has a moderate level of security as long as the session system disregards GET/POST values. However, this solution is vulnerable to cross-site request forgery.
  4. Utilize SSL / TLS Session identifier
    When enabling HTTPS security, some systems allow applications to obtain the SSL / TLS session identifier. Use of the SSL/TLS session identifier is very secure, but many web development languages do not provide robust built-in functionality for this.
    SSL/TLS session identifiers may be suitable only for critical applications, such as those on large financial sites, due to the size of the systems. This issue, however, is rarely debated even in security forums.
  5. Regenerate SID on each request
    A countermeasure against session fixation is to generate a new session identifier (SID) on each request. If this is done, then even though an attacker may trick a user into accepting a known SID, the SID will be invalid when the attacker attempts to re-use the SID. Implementation of such a system is simple.
  6. Accept only server-generated SIDs
    One way to improve security is not to accept session identifiers that were not generated by the server.However, as noted above, this does not prevent all session fixation attacks.
  7. Logout Functions
    A logout function is useful as it allows users to indicate that a session should not allow further requests. Thus attacks can only be effective while a session is active. Note that the following code performs no Cross-site request forgery checks, potentially allowing an attacker to force users to log out of the web application.
  8. Time out old SIDs
    This defense is simple to implement and has the advantage of providing a measure of protection against unauthorized users accessing an authorized user's account by using a machine that may have been left unattended.
  9. Destroy Session if Referrer is suspicious
    When the user is logged into a site that is not likely to be linked to from outside that site (e.g., banking websites, or webmail), and the site is not the kind of site where users would remain logged in for any great length of time, the Referrer should be from that site. Any other Referrer should be considered suspicious. However, if the originating request is from a HTTPS page, then the referrer will be stripped, so you cannot depend on this security system.

We are a firm based in Pune, India providing IT infrastructure management and cyber security solutions.