Disclosure of Tokens in Logs
Aside from the clear-text transmission of session tokens in network communications, the most common place where tokens are simply disclosed to unauthorized view is in system logs of various kinds. Although it is a rarer occurrence, the consequences of this kind of disclosure are usually more serious because those logs may be viewed by a far wider range of potential attackers, and not just by someone who is suitably positioned to eavesdrop on the network.
Many applications provide functionality for administrators and other support personnel to monitor and control aspects of the application’s runtime state, including user sessions. For example, a helpdesk worker assisting a user who is having problems may ask for their username, locate their current session through a list or search function, and view relevant details about the session. Or an administrator may consult a log of recent sessions in the course of investigating a security breach. Often, this kind of monitoring and control functionality discloses the actual session token associated with each session. And often, the functionality is poorly protected, allowing unauthorized users to access the list of current session tokens, and thereby hijack the sessions of all application users.
The other main cause of session tokens appearing in system logs is where an application uses the URL query string as a mechanism for transmitting tokens, as opposed to using HTTP cookies or the body of POST requests. For example, googling for inurl:jsessionid identifies thousands of applications that transmit the Java platform session token (called jsessionid ) within the URL:
http://www.webjunction.org/do/Navigation;jsessionid=
F27ED2A6AAE4C6DA409A3044E79B8B48?category=327
When applications transmit their session tokens in this way, it is likely that their session tokens will appear in various system logs to which unauthorized parties may have access, for example:
■ Users’ browser logs.
■ Web server logs.
■ Logs of corporate or ISP proxy servers.
■ Logs of any reverse proxies employed within the application’s hosting environment.
■ The Referer logs of any servers that application users visit by following off-site links, as in Figure -1.
Figure -1: When session tokens appear in URLs, these will be transmitted
in the Referer header when users follow an off-site link or their browser
loads an off-site resource.
Some of these vulnerabilities will arise even if HTTPS is used throughout the application.
The final case just described presents an attacker with a highly effective means of capturing session tokens in some applications. For example, if a web mail application transmits session tokens within the URL, then an attacker can send emails to users of the application containing a link to a web server that he controls. If any user accesses the link (e.g., because they click on it, or because their browser loads images contained within HTML-formatted email), then the attacker will receive, in real time, the session token of the user. The attacker can run a simple script on his server to hijack the session of every token received and perform some malicious action, such as send spam email, harvest personal information, or change passwords.
NEXT is..Vulnerable Mapping of Tokens to Sessions.,.,.,,..,.,.,.
