Weaknesses in Session Token Handling
No matter how effective an application is at ensuring that the session tokens it generates do not contain any meaningful information and are not susceptible to analysis or prediction, its session mechanism will be wide open to attack if those tokens are not handled carefully after generation. For example, if tokens are disclosed to an attacker via some means, then the attacker can hijack user sessions even if predicting the tokens is impossible.
There are various ways in which an application’s unsafe handling of tokens can make it vulnerable to attack.
Disclosure of Tokens on the Network
This area of vulnerability arises when the session token is transmitted across the network in unencrypted form, enabling a suitably positioned eavesdropper to obtain the token and so masquerade as the legitimate user. Suitable positions for eavesdropping include the user’s local network, within the user’s IT department, within the user’s ISP, on the Internet backbone, within the application’s ISP, and within the IT department of the organization hosting the
application. In each case, this includes both authorized personnel of the relevant organization and any external attackers who have compromised the infrastructure concerned.
In the simplest case, where an application uses an unencrypted HTTP connection for communications, an attacker can capture all data transmitted between client and server, including login credentials, personal information, payment details, and so on. In this situation, an attack against the user’s session is often unnecessary because the attacker can already view privileged information and can log in using captured credentials to perform other malicious actions. However, there may still be instances where the user’s session is the primary target. For example, if the captured credentials are not sufficient to perform a second login (e.g., in a banking application, they may include a number displayed on a changing physical token, or specific digits from the user’s PIN), the attacker may need to hijack the eavesdropped session in order to perform arbitrary actions. Or if there is close auditing of logins, and notification to the user of each successful login, then an attacker may wish to avoid performing his own login in order to be as stealthy as possible.
In other cases, an application may use HTTPS to protect key client-server communications yet may still be vulnerable to interception of session tokens on the network. There are various ways in which this weakness may occur, many of which can arise specifically when HTTP cookies are used as the transmission mechanism for session tokens:
■ Some applications elect to use HTTPS to protect the user’s credentials during login but then revert to HTTP for the remainder of the user’s session. Many web mail applications behave in this way. In this situation, an eavesdropper cannot intercept the user’s credentials but may still capture the session token, as shown in Figure -1.
Figure -1: Capturing a session token transmitted over HTTP
■ Some applications use HTTP for preauthenticated areas of the site, such as the site’s front page, but switch to HTTPS from the login page onwards. However, in many cases the user is issued a session token at the first page visited, and this token is not modified when the user logs in. The user’s session, which is originally unauthenticated, is upgraded to an authenticated session after login. In this situation an eavesdropper can intercept a user’s token before login, wait for the user’s communications to switch to HTTPS, indicating that the user is logging in, and then attempt to access a protected page (such as My Account) using that token.
■ Even if the application issues a fresh token following successful login, and uses HTTPS from the login page onwards, the token for the user’s authenticated session may still be disclosed if the user revisits a preauthentication page, either by following links within the authenticated area, by using the Back button, or by typing the URL directly.
■ In a variation on the previous case, the application may attempt to switch to HTTPS when the user clicks the Login link; however, it may still accept a login over HTTP if the user modifies the URL accordingly. In this situation, a suitably positioned attacker can modify the pages returned in the preauthenticated areas of the site so that the Login link points to an HTTP page. Even if the application issues a fresh session token after successful login, the attacker may still intercept this token if he has successfully downgraded the user’s connection to HTTP.
■ Some applications use HTTP for all static content within the application, such as images, scripts, style sheets, and page templates. This behavior is often indicated by a warning alert within the user’s browser. an attacker can intercept the user’s session token when the user’s browser accesses a resource over HTTP, and use this token to access protected, non static areas of the site over HTTPS.
■ Even if an application uses HTTPS for every single page, including unauthenticated areas of the site and static content, there may still be circumstances in which users’ tokens are transmitted over HTTP. If an attacker can somehow induce a user to make a request over HTTP (either to the HTTP service on the same server if one is running or to http://server:443/ otherwise), then their token may be submitted. Means by which the attacker may attempt this include sending the user a URL in an email or instant message, placing auto-loading links into a web site the attacker controls, or using clickable banner ads.
NEXT is..Disclosure of Tokens in Logs.,.,,.,..,.,.
