Vulnerable Mapping of Tokens to Sessions
Various common vulnerabilities in session management mechanisms arise because of weaknesses in the way the application maps the creation and processing of session tokens to individual users’ sessions themselves.
The simplest weakness is to allow multiple valid tokens to be concurrently assigned to the same user account. In virtually every application, there is no legitimate reason why any user should have more than one session active at any given time. Of course, it is fairly frequent for a user to abandon an active session and start a new one — for example, because they have closed a browser window or have moved to a different computer. But if a user appears to be using two different sessions simultaneously, this usually indicates that a security compromise has occurred: either the user has disclosed their credentials to another party or an attacker has obtained their credentials through some other means. In both cases, permitting concurrent sessions is undesirable because it allows users to persist in undesirable practices without inconvenience and because it allows an attacker to use captured credentials without risk of detection.
A related but distinct weakness is for applications to use “static” tokens. These look like session tokens and may initially appear to function like them, but in fact they are no such thing. In these applications, each user is assigned a token, and this same token is reissued to the user every time he logs in. The application always accepts the token as valid regardless of whether the user has recently logged in and been issued with it. Applications like this really involve a misunderstanding of the whole concept of what a session is, and the benefits that it provides for managing and controlling access to the application. Sometimes, applications operate like this as a means of implementing poorly designed “remember me” functionality, and the static token is accordingly stored in a persistent cookie. Sometimes the tokens them selves are vulnerable to prediction attacks, making the vulnerability far more serious because rather than compromising the sessions of currently logged-in users, a successful attack will compromise, for all time, the accounts of all registered users.
Other kinds of strange application behavior are also occasionally observed that demonstrate a fundamental defect in the relationship between tokens and sessions. One example is where a meaningful token is constructed based upon a username and a random component. For example, consider the token:
dXNlcj1kYWY7cjE9MTMwOTQxODEyMTM0NTkwMTI=
which Base64-decodes to:
user=daf;r1=13094181213459012
After extensive analysis of the r1 component, we may conclude that this cannot be predicted based on a sample of values. However, if the application’s session processing logic is awry, it may be that an attacker simply needs to submit any valid value as r1 and any valid value as user , in order to access a session under the security context of the specified user. This is essentially an access control vulnerability, because decisions about access are being made on the basis of user-supplied data outside of the session . It arises because the application effectively uses session tokens to signify that the requester has established some kind of valid session with the application; however, the user context in which that session is processed is not an integral property of the session itself but is determined per-request through some other means. In this case, that means can be directly controlled by the requester.
Vulnerable Session Termination
Proper termination of sessions is important for two reasons. First, keeping the lifespan of a session as short as is necessary reduces the window of opportunity within which an attacker may capture, guess, or misuse a valid session token. Second, it provides users with a means of invalidating an existing session when they no longer require it, thereby enabling them to reduce this window further and to take some responsibility for securing their session in a shared computing environment. The main weaknesses in session termination functions involve failures to meet these two key objectives.
Some applications do not enforce effective session expiration. Once created, a session may remain valid for many days after the last request is received, before it is eventually cleaned up by the server. If tokens are vulnerable to some kind of sequencing flaw that is particularly difficult to exploit (for example, 100,000 guesses for each valid token identified), an attacker may still be able to capture the tokens of every user who has accessed the application in the recent past.
Some applications do not provide effective logout functionality:
■ In some cases, a logout function is simply not implemented. Users have no means of causing the application to invalidate their session.
■ In some cases, the logout function does not actually cause the server to invalidate the session. The server removes the token from the user’s browser (for example, by issuing a Set-Cookie instruction to blank the token). However, if the user continues to submit the token, then it is still accepted by the server.
■ In the worst cases, when a user clicks Logout, this fact is not communicated to the server at all, and so the server performs no action whatsoever. Rather, a client-side script is executed that blanks the user’s cookie, meaning that subsequent requests return the user to the login page. An attacker who gains access to this cookie could use the session as if the user had never logged out.
Client Exposure to Token Hijacking
There are various ways in which an attacker can target other users of the application in an attempt to capture or misuse the victim’s session token:
■ An obvious payload for cross-site scripting attacks is to query the user’s cookies to obtain their session token, which can then be transmitted to an arbitrary server controlled by the attacker.
■ Various other attacks against users can be used to hijack the user’s session in different ways. These include session fixation vulnerabilities, where an attacker feeds a known session token to a user, waits for them to log in, and then hijacks their session; as well as cross-site request forgery attacks, in which an attacker makes a crafted request to an application from a web site that he controls, and exploits the fact that the user’s browser automatically submits her current cookie with this request.
NEXT is..Liberal Cookie Scope.,.,.,..,.,,.,.,.
