HTTP Applications can create sessions to keep track of anonymous users after the very first HTTP Request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has Authenticated. This ensures the ability to identify the user on any subsequent HTTP Requests as well as being able to apply security access controls, authorized access to the user Private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.
Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest Authentication Method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, Smart Cards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet.
HTTP is a stateless protocol (RFC 2616 [5]), where each HTTP Request and HTTP Response pair is independent of other interactions. Therefore, in order to introduce the concept of a session, it is required to implement Session Management capabilities that link both the authentication and Access Control (or authorization) modules commonly available in web applications.
The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate Access Control is enforced by the application. The complexity of these three components (authentication, Session Management, and Access Control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to Impersonation a victim user in the web application. Attackers can perform two types of session hijacking attacks, Targeted Attack or Opportunistic Attack. In a Targeted Attack, the attacker’s goal is to Impersonation a specific (or privileged) web application victim user. For Opportunistic Attacks, the attacker’s goal is Impersonation (or get access as) any valid or legitimate user in the web application.