Basic Web Session Impersonation

Basic Web Session Impersonation
Rohyt Belani 2004-04-14

Understanding the threat

In the 1960's, it required the brilliance of Frank Abagnale Jr. (of "Catch Me If You Can" fame) to deceptively build a bank balance of colossal magnitude. Today, all one needs is a prying teenager with access to the Internet - a hair raising reality!

Consider the following analogy:

Scenario One:
Simple Sam (a legitimate user) goes to the local bank (web server farm) to access his safety deposit box (database). He is served by the first available teller (web application), who takes him to the vault.

Scenario Two:
Evil Edward (a malicious user) goes to the same local bank office and enters through the front door as well (port 80) just like any other customer. Even though his intent is vile he does not break into the bank through the windows (other ports). Thus, to the security guards (firewall) at the front door he appears to be innocuous. He too is served by the next available teller (web application). However, he tricks the teller into believing (session management) that he is not Evil Edward but is Simple Sam and gains access to Sam's security deposit box.

Scenario two describes a successful impersonation attack that goes undetected by the security guards (firewall).

The proliferation of e-commerce and the anonymity provided by the Internet have shifted the focus of such attacks from the real world to cyber space. The consequences of such an impersonation attack against a web application (known as a cyber-impersonation attack) range from personal information disclosure and identity theft to financial fraud resulting in the embezzlement of funds. The lack of ability for conventional firewalls to recognize such attacks and their enormously derogatory impact on business make them of special interest to "black hats" and thus, of special concern for developers and web security administrators. In this article I will discuss common flaws in web application design that facilitate cyber-impersonation attacks and tested countermeasures to protect against them. However, in order to better understand cyber-impersonation attacks it is imperative to gain an adequate understanding of session management techniques (as will become clear through the rest of the article).

Session Management

Session management encompasses the techniques employed by web applications to transparently authorize a user for every HTTP request without having the user repeatedly login. The onus of session management must be borne by the application itself due to the stateless nature of the underlying HTTP protocol. Session management entails the application sending the client (in most cases, a web browser) a session token after successful authentication. In most cases, this token is passed via the Set-Cookie directive of HTTP and is stored on the client. The session token must then be sent by the client along with every HTTP request to the server to identify itself to the web-based application. The application can then determine whether the client is authorized to access the page being requested.

Session management mechanisms can be broadly classified into client-side and server-side mechanisms. This classification is based on the contents of the session token passed between the client and the application.

Client-side session management

In this form of session management, the session token contains the best part of the data necessary to perform user authorization. As the token and in effect a bulk of the authorization information is stored on the client, this technique of session management is often referred to as client-side session management and the token is commonly referred to as a cookie. It is the accurate manipulation of this cookie that may lead the application into believing that the user is someone else - a successful cyber impersonation attack. This concept can be understood more clearly from the following over-simplified example.

User (Simple) Sam after successful authentication to xyzbank.com receives the following set of cookies (only cookie names and values are shown):

admin=false;account=101

User (Evil) Edward after successful authentication to xyzbank.com receives the following set of cookies (only cookie names and values are shown):

admin=false;account=120

The role of each cookie is fairly evident. The admin cookie indicates to the application whether the user should be granted administrative rights. The account cookie probably specifies the actual account the particular user is allowed to access.

If Edward were trying to impersonate Sam, he would probably attempt to brute-force Sam's account cookie. This would entail trying all the possible values for that cookie which in this case presents a maximum of 1000 possibilities (namely, 000-999). Edward (or his script) would be successful on his 102nd attempt when the cookie presented by him to the application would be:

admin=false;account=101

The above is an example of an impersonation attack with horizontal privilege escalation (i.e. the attacker impersonated another user at the same privilege level).

Edward could have also attempted a vertical privilege escalation attack by modifying the value of the admin cookie to true. This may "trick" the application into believing the Edward is an administrator and granting him administrative access to the banking application. The opportunities for a user like Edward with vile intent are then limitless!

Server-side session management

The fundamental difference between this form of session management and client-side session management is that in this case the bulk of the authorization information is stored on a back-end database (server-side) and the session token passed between the client and the application acts as a mere index into that database. This type of session token is often referred to as a session id. Consider the following example.

User (Simple) Sam after successful authentication to xyzbank.com receives the following session id:

sessionid=1234

User (Evil) Edward after successful authentication to xyzbank.com receives the following session id:

sessionid=1235

These session ids can be thought of as a row number in the authorization database at the back-end that may be structured as follows:

Index	Username	Admin	Account Number
...	...	...	...
1232	Joe	Y	All
1233	Bob	N	087
1234	Sam	N	101
1235	Edward	N	120
1236	Tom	N	435
1237	Phil	N	991
...	...	...	...

If Edward's intent again is to impersonate Sam then he must successfully modify his session id to reflect that of Sam's which in this case involves changing his session id value from1235 to 1234. He may also be able to impersonate an administrative user Joe by guessing his session id (i.e. 1232).

Thus, simply storing the authorization data on the back-end does not safeguard the application against impersonation attacks.

Countermeasures

What design and implementation changes would have sufficiently mitigated these attacks?

The basic principles of securing an application against impersonation attacks are the same whether it employs client- or server-side session management. The following are some salient countermeasures.

Increasing the length of the value of the cookie or session id
For example, if the value of the account cookie consisted of say 32 characters rather than 3, it would take Edward a lot longer to successfully guess Sam's account number. To be precise, a maximum of (10³² -1) attempts as compared to (10³-1). The same applies to session ids.

Increased randomness in the value of the session token
With a larger potential namespace, the value of the cookie or session id should also be made more random. This may involve the induction of alphabets into the legitimate character set of the cookie or session id and making the values non-sequential and thus harder to guess.

Protecting the integrity of the session tokens
Appending a message authenticity code, like an MD5 sum of the original session token's value as sent out by the server, and checking it (for every request) at the server-side to verify that it has not been tampered with, may serve this purpose appropriately. Thus, even if a malicious user modifies a cookie or session id value, it will not pass the data integrity check at the server and be rejected. This ensures that the original session token sent to the user is the only one received by the application for every subsequent request.

Obfuscating the cookies
Obfuscating the entire cookie set can conceal the composition of the cookies from the user, making it harder if not impossible for a user like Edward to manipulate his cookies and accurately reflect the value of another valid set of cookies. This technique of obscuring the value is more pertinent to cookies as they contain actual authorization data unlike session ids.

Use of server-supplied session ids
A viable alternative to creating your own session ids is to use those provided by the application servers. Examples of such session ids are ASPSESSIONID and JSESSIONID. These session identifiers have been thoroughly tested and are known to comply with the basic principles of session id security discussed above.

Protecting the confidentiality of the session tokens
Apart from manipulating cookies and session ids, attackers may also attempt to sniff the tokens as they traverse the network. Such attacks can be thwarted through the use of appropriate encryption technologies. These include encrypting the entire communication channel using SSL or individually encrypting the session tokens using a tested algorithm.

It is important to remember, that one can never completely secure an application and must incorporate multiple layers of security in its design to protect against such attacks. These may include:

Forcing the expiration of sessions after a preset period of time. This ensures that an attacker does not gain unlimited unauthorized access to an application even if he manages to successfully guess, brute-force or sniff a valid session token.
Performing rigorous server-side input validation of every form of client input to prevent cross-site scripting attacks that may allow an attacker to steal valid session tokens.
Deploying application-level proxies to further enhance the security posture of the application and its underlying infrastructure.

Conclusion

We've seen some basic client-side and server-side session management approaches used by many web applications -- and how easy it is to cyber-impersonate another user when more sophisticated techniques are not used. If some of the websites you frequent make use of cookies that offer such information, you should be wary of providing any personal or financial information about yourself as the session could be easily hijacked.

It should go without saying that most financial institutions make use of significant countermeasures that make cyber-impersonation much more difficult. Some of the possible countermeasures have been discussed in the second half of this article.

More information on penetration testing for web applications, including session management and the use of cookies, can be found in the three part series on penetration testing for web applications, found in the Pen-Test archives on SecurityFocus.

About the author

View more articles by Rohyt Belani on SecurityFocus.

SecurityFocus accepts Infocus article submissions from members of the security community. Articles are published based on outstanding merit and level of technical detail. Full submission guidelines can be found at http://www.securityfocus.com/static/submissions.html.