Attacking Session Management
The session management mechanism is a fundamental security component in the majority of web applications. It is what enables the application to uniquely identify a given user across a number of different requests, and to handle the data that it accumulates about the state of that user’s interaction with the application. Where an application implements login functionality, session management is of particular importance, as it is what enables the application
to persist its assurance of any given user’s identity beyond the request in which they supply their credentials.
Because of the key role played by session management mechanisms, they are a prime target for malicious attacks against the application. If an attacker can break an application’s session management, then she can effectively bypass its authentication controls and masquerade as other application users without knowing their credentials. If an attacker compromises an administrative user in this way, then the attacker can own the entire application.
commonly be found in session management functions. In the most vulnerable cases, an attacker simply needs to increment the value of a token issued to them by the application in order to switch their context to that of a different user. In this situation, the application is wide open for anyone to access all areas. At the other end of the spectrum, an attacker may have to work extremely hard, deciphering several layers of obfuscation and devising a sophisticated automated attack, before finding a chink in the application’s armor.
The Need for State
The HTTP protocol is essentially stateless. It is based on a simple request response model, in which each pair of messages represents an independent transaction. The protocol itself contains no mechanism for linking together the series of requests made by one particular user and distinguishing these from all of the other requests received by the web server. In the early days of the Web, there was no need for any such mechanism: web sites were used to publish static HTML pages for anyone to view. Today, things are very different. The majority of web “sites” are in fact web applications. They allow you to register and log in. They let you buy and sell goods. They remember your preferences next time you visit. They deliver rich, multimedia experiences with content created dynamically based on what you click and type. In order to implement any of this functionality, web applications need to use the concept of a session.
The majority of web “sites” are in fact web applications. They allow you to register and log in. They let you buy and sell goods. They remember your preferences next time you visit. They deliver rich, multimedia experiences with content created dynamically based on what you click and type. In order to implement any of this functionality, web applications need to use the concept of a session.
The most obvious use of sessions is in applications that support logging in. After entering your username and password, you can go ahead and use the application as the user whose credentials you have entered, until such time as you log out or the session expires due to inactivity. Users do not want to have to reenter their password on every single page of the application. Hence, after authenticating the user once, the application creates a session for them, and treats all requests belonging to that session as coming from that user.
Applications that do not have a login function also typically need to use sessions. Many sites selling merchandise do not require customers to create accounts. However, they allow users to browse the catalog, add items to a shopping basket, provide delivery details, and make payment. In this scenario, there is no need to authenticate the identity of the user: for the majority of their visit, the application does not know or care who the user is. But, in order to do business with them, it needs to know which series of requests it receives has originated from the same user.
The simplest and still most common means of implementing sessions is to issue each user with a unique session token or identifier. On each subsequent request to the application, the user resubmits this token, enabling the application to determine which sequence of earlier requests the current request relates to.
In most cases, applications use HTTP cookies as the transmission mechanism for passing these session tokens between server and client. The server’s first response to a new client contains an HTTP header like the following:
Set-Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55
and subsequent requests from the client contain the header:
Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55
There are various categories of attack to which this standard session management mechanism is inherently vulnerable. An attacker’s primary objective in targeting the mechanism is to somehow hijack the session of a legitimate user and thereby masquerade as them. If the user has been authenticated to the application, the attacker may be able to access private data belonging to the user or carry out unauthorized actions on that person’s behalf. If the user is unauthenticated, the attacker may still be able to view sensitive information submitted by the user during her session.
The vulnerabilities that exist in session management mechanisms largely fall into two categories:
■ Weaknesses in the generation of session tokens.
■ Weaknesses in the handling of session tokens throughout their lifecycle.
Alternatives to Sessions
Not every web application employs sessions, and some security-critical applications containing authentication mechanisms and complex functionality opt to use other techniques for managing state. There are two possible alternatives that you are likely to encounter:
■ HTTP authentication — Applications using the various HTTP-based authentication technologies (basic, digest, NTLM, etc.) sometimes avoid the need to use sessions. With HTTP authentication, the client component interacts with the authentication mechanism directly via the browser, using HTTP headers, and not via application-specific code contained within any individual page. Once a user has entered his credentials into a browser dialog, the browser effectively resubmits these credentials (or reperforms any required handshake) with every subsequent request to the same server. This is the equivalent to an application that uses HTML forms-based authentication and places a login form on every application page, requiring users to reauthenticate themselves with every action they perform. Hence, when HTTP-based authentication is used, it is possible for an application to re-identify the user across multiple requests without using sessions. However, HTTP authentication is rarely used on Internet-based applications of any complexity, and the other very versatile benefits that fully fledged session mechanisms offer mean that virtually all web applications do in fact employ them.
■ Sessionless state mechanisms — Some applications do not issue session tokens in order to manage the state of a user’s interaction with the application but rather transmit all data required to manage that state via the client, usually in a cookie or a hidden form field. In effect, this mechanism uses sessionless state in a similar way to the ASP.NET ViewState. In order for this type of mechanism to be secure, the data transmitted via the client must be properly protected. This usually involves constructing a binary blob containing all of the state information, and encrypting or signing this using a recognized algorithm. Sufficient context must be included within the data to prevent an attacker from collecting a state object at one location within the application and submitting it to another location to cause some undesirable behavior. The application may also include an expiration time within the object’s data, to perform the equivalent of session timeouts.
NEXT is..Weaknesses in Session Token Generation.,.,.,,.,….,,,.,.
