The nature of the cookie poisoning risk

Cookie poisoning is a technique known mainly for achieving impersonation and breach of privacy through manipulation of session cookies that maintain the identity of the client (or end user). By forging these cookies, an attacker can impersonate a valid client, and thus gain information and perform actions on behalf of the victim. The ability to forge such session cookies (or more generally, session tokens) stems from the fact that the tokens are not generated in a secure way.

The Sisyphean task of in-house session maintenance

In Web application programming, session management is complex and awkward. The programmer needs to worry about many aspects of session management which can defocus him/her from the main goal: implementing the business logic that makes the site unique and profitable.

Specific issues:

• Session creation and identification: How can you ensure that, when a new session is needed, it is indeed created? The programmer must identify that a client has a need for a session, create the session and assign the client a session.

• Concurrency issues: When two clients access the site simultaneously, each requiring a new session, it is necessary to make sure that the session creation process will still function correctly.

• Session termination and timeout: What triggers a session termination? How are the resources of the terminated session recycled? What happens if the client tries to access the site when the termination process is taking place? What happens when a client tries to access a site with a stale session?

• Session data storage, multiple servers, fail-over. Where is the session data stored. On disk? In RAM? What is the performance penalty? What happens in a multiserver site if a client accesses a first server (and establishes a session with it) and then is directed (by a load balancer) to a second server? What happens to the client session data in case the original server crashes?

Security-wise, the following points are important to consider:

• It should never be possible for one client to be able to predict the token another client received, or is in the process of receiving, or will receive. This is obviously a must-have to prevent impersonation attacks and, consequently, breach of privacy.

• Furthermore, it is desirable that clients will not be able to predict the next tokens that they will get when accessing the site. This is useful in minimizing the damage of stealing the token while it travels (in the clear) to and fro, as well as while it is stored on the clients' computers.

• Any token should have a reasonable expiration period -- again, to minimize the damage of it being stolen.

As you can tell, it is not very easy to fulfill all of these requirements, especially if the session mechanism is developed ad-hoc. The more intricate security requirements are definitely something that developers, especially ones not versed in security, may easily miss.

There are many examples of insufficient security in tokens. These were demonstrated in the work of the MIT Laboratory for Computer Science (see Dos and Don'ts of Client Authentication on the Web by Kevin Fu, Emil Sit, Kendra Smith, and Nick Feamster). Thus, we see that it is difficult to produce a good session management solution, let alone a secure session management solution. This is one of the reasons why application servers are so popular.

Application servers and engines: a solution and a problem

An Application Server (or Application Engine) is a software program designed to make the life of the application developer easy. It usually offers the programmer the ease of writing HTML pages with directives for the server embedded in them, instructing the server to perform various tasks. Most application servers provide the programmer an environment that takes care of the session automatically, relieving the programmer from all the worries mentioned in the above section.

Examples of application servers:

• Microsoft® ASP .NET, which runs on top of IIS
• Macromedia
• ColdFusion
• Apache Tomcat
• Apache JServ
• PHP
• BEA WebLogic
• IBM® WebSphere® Application Server.

The Internet Cookie Report page of the Security Space Web site offers some frequency analysis through associating the cookie names with the server that issues them. This is biased, of course, because some servers and sites use tokens in form parameters rather than in cookies.

The upside of application engines is the fact that they completely relieve the programmer from worrying about session management. All functionality aspects of session management are taken care of, usually in a much better way than an in-house programmer could achieve.

The downside of application engines is the fact that they seem to relieve the programmer from worrying about the security of the token. Yet we can show that the harsh reality is far from that. In fact, some very popular application engines do not provide secure tokens. As a result, the programmer gets a false sense of security.

My associates and I examined the tokens generated by two popular application servers. In both cases, we were able to demonstrate that the token is not as random as it seems and that it is possible (in one case, with ease) to predict the values of the token for the next sessions (of a different client).

Example 1. Beating a time-based token

The target of this attack is a very popular commercial application engine. The product uses two cookies to identify a session. The pair formed by the two cookies identifies the session. The first cookie is merely a counter, incremented once per new session. It probably ensures that no two pairs are ever identical. The second cookie is the token cookie, apparently intended to secure the pair by being "unpredictable." Given that it is very easy to predict the first cookie, we focus here on the second cookie, which we'll denote as TOKEN.

At first glance, TOKEN seems to be a sequence of random 8-decimal digits. The entropy (amount of randomness) here is 108 = 226.57, which may be considered sufficient considering that it is not feasible to try such amounts of requests (100 million) against a site without triggering some kind of alarm and human attention. But a closer look reveals that, in fact, TOKEN obeys the following equation:

Let us denote by t the GMT time, in seconds, 
because 01/01/1970 00:00, as set on the application server. 



Let us denote by m the milliseconds portion of the tick counter on the application server.



Then: TOKEN= ( 31415821 * (t + m) + 1 ) mod 100000000

It is interesting to note that t can be extracted from the HTTP Date header that the server sends back to the client, together with the first time that the cookies are set. This means that the TOKEN cookie is quite predictable. In fact, if one knows a range of time T </- t < T+ΔT (in seconds) in which a cookie was generated, one can infer that TOKEN has one of ΔT+1000 values, which is a rather short list of values. Testing a bit more than a thousand values against the server may take few minutes, in which the victim session is likely to remain active. This is the outline of an attack algorithm:

Obtain a first pair (id1, TOKEN1). Record t1 – 

the server time (from the Date HTTP header) 

Wait ΔT seconds. 

Get a second pair (id22, TOKEN2). 

Record t2 – the server time (from the Date HTTP header) 

if (id2 > id1 +1) 

begin // we have a victim session interjected here. for (x= t1 ; x < t2+1000 ; x++) // 
which is ΔT+1000 iterations begin 

Try the pair (id1 +1, ( 31415821 * x + 1 ) mod 100000000) end end 

In fact, it is possible to improve this algorithm in some cases by using the fact that, on some operating systems, the tick counter does not have millisecond granularity, but rather a coarser granularity of around 10 msec. This can be used to reduce the search space even more.

The attack described above enables the attacker to impersonate a victim, provided that such victim was assigned a cookie between the two samples the attacker made of the site cookies. Because attackers can repeat the algorithm as many times as they want, it is possible for an attacker to get these cookies for all clients, at a price of sampling the site (say, one request every minute) and, additionally, some 1060 requests per any new client discovered. Again, as hinted above, it is possible to sample at closer intervals (once per second) and exploit the granularity problem of the clock ticks, in which case it is probably possible to arrive at 100 requests per new client.

It is likely that if an attempt to impersonate a client is performed while the site is loaded with traffic, then the additional hundreds or thousands of requests would go unnoticed, at least momentarily.

Example 2. When Random() isn't random

In this example, we deal with a still-popular (yet a bit outdated) application engine. This engine generates a single cookie for each new session. This cookie (which we call ID here) comprises 3 mandatory fields (F1, F2, and F3) and one optional (server configuration dependent) field (F4, preceded by a dot), concatenated. The fields are as follows:

F1 = 6 characters (A-Z0-9) – PRNG (Pseudo Random Number Generator) data, 
represented in base 36 with leading zeros F2 = 3 characters (A-Z0-9) – 
server time (milliseconds), divided by 2000, 
mod 363 (=46656), represented in base 36 with leading zeros 
F3 = 3 characters (A-Z0-9) – session count in this 2 second time slice, 
represented in base 36 F4 = constant string (per server)

As you can see, F4 (if it exists) is constant, and hence trivially predictable. F2 is simply the server time (in seconds) divided by 2, modulo 46656, which is quite predictable, and F3 is not too obscure as well – as it is sequentially incremented in the 2 seconds time slice (always begins at one).

The only interesting field is therefore F1. Apparently, it holds enough entropy to secure the system, since it can assume 36⁶ values (=2^31.0). Yet again, what seems secure at first sight appears not so secure when performing a full analysis. Explanation on how and why F1 can be predicted is provided in Appendix A, since it is too long for inclusion here. The problem we exploited with F1 is the fact that it uses a PRNG (Pseudo Random Number Generator), which in itself is predictable. So knowing several values of F1 suffices to fully predict the PRNG, and hence future (and past) values of F1.

This is the outline of such an attack:

Preparation: 

Obtain three IDs, in the shortest time intervals possible. 

Extract the PRNG internal state (as explained in Appendix A). 

Interception Cycle Obtain an ID, and record the server time, t. 

For simplicity, assume t is even. 

Find the PRNG internal state that was used to generate this ID 
(as explained in the Appendix) 
Wait ΔT seconds (where ΔT is even) 
Obtain a new ID. 
Advance the PRNG, and record all internal states 
between the PRNG state of the old ID and the 
PRNG state that generated this ID (As explained in the Appendix). 
Let the list of internal values be L 
// ΔT/2 iterations: 
for (T=t; T<t+ΔT; T+=2) 
begin 
for each internal PRNG state L, i. 
begin 
Try an ID cookie consisting of: 

F1=generate from sample of PRNG at state i and i+1; 
F2=T; 
F3=1; // first session in this 2-second time period 
F4=F4 of any ID above; //constant per server 

end 
end 

As you can see, it is feasible, although not trivial, to predict some ID cookies. For feasibility, it is required that the time interval (ΔT) be short (with respect to the expected usage of the server), in order to minimize the length of L (the list of possible internal PRNG states). If these intervals are indeed very short (less than two seconds), it may be possible, with correct timing, to tell whether a new session was interjected at the current 2-second time slice, which makes the attack more effective (since it requires launching the additional requests only when it is known that a new victim session was indeed created). It should also be mentioned that to avoid losing synchronization (of the PRNG internal state) with the site, it is necessary to keep requesting a new ID from time to time to advance the attacker's PRNG internal state to the new value. It should be remembered that the PRNG is likely to be used for many purposes, not just the creation of sessions. This means that the site may use the PRNG intensively, thus causing a quick desynchronization (to counter this, it is necessary to resync at close time intervals, such as every few minutes). On the other hand, it may be possible to get a clearer glimpse of the internal PRNG state by inspecting other random values that may be used in the site. This may offer a shortcut, saving a lot of computation power.

It should be noted that when the attacker is in sync with the site, and if IDs are extracted frequently enough, it is possible to impersonate any client at the expense of sending few requests (it depends on the use of the PRNG).

What the involved vendors said

Vendor 1 acknowledged the weakness, and informed us that its customers should use SSL certificates for session management. Although this is, perhaps, a good idea for some customers (but definitely not for all customers, because moving to SSL and SSL certificates is definitely not trivial and sometimes not possible), the documentation for its product leads the reader to believe that the built-in session management is secure (they call it "the client security token" in their documentation for developers). Also, the vendor does not make this suggestion public.

Vendor 2 acknowledged the weakness, yet wrote us: "Session cookies are not a replacement for authentication tokens. A session cookie in conjunction with a random auth token or auth login validation is both reasonable mechanisms. This should be true in designing session based scripts -- even where the session tokens are 'trusted' today." Thus, they are putting the responsibility in the hands of the developers.

The two vendors, while technically acknowledging the problem, dismissed it as a non-security issue. That is, both vendors assume that their customers implement their own session security tokens rather than rely on the vendor tokens. The vendors, therefore, claim that their tokens are used (or should be used) solely to better differentiate between different users, not as a security measure. In the documentation, we did not find any warning against using the token as a secure session identifier. Furthermore, Vendor 1's documentation uses phrases that lead one to believe that this token is secure. In reality, of course, most sites use the tokens issued by vendors as secure session identifiers, oblivious to the fact that this is weak.

In a sense, the application developer is back to square one: Developers cannot trust the built-in session identification mechanism; therefore, they are forced to write their own mechanisms, with their best effort, to fulfill all of the requirements mentioned here previously and to avoid the delicate pitfalls of cryptography.

Conclusions

Session security too often falls between the cracks. Vendors don't do it right, don't care for it, or delegate the responsibility for it to the developers. In-house development is error-prone and requires a deep understanding of security. This article provided real-life examples for insecure tokens in commercial application engines, as well as in home-grown applications.

The solution is simple: the world of Web applications should consist of three components:

• The application (which is developed in house, and expresses the business logic, as well as the novelty and specialty of the company/site).

• The application environment (the application engine and Web server, which enable easy application development and focus on the application rather than on infrastructure).

• Web application security component, which takes care of the application security, again relieving the developers (and to some extent, the application engine developers too!) from having to worry about secure implementation of their application.

In the cases described here, a Web application firewall would have fortified the tokens generated by the application engines or by the in-house developed application, transparently (the developer does not even need to be aware of this). It would have ensured -- through using strong cryptography and security tested mechanisms -- that the tokens sent to the application were indeed genuine and not forged.

Back to top

Download

Information about download methods          Get Adobe® Reader®

Resources

Learn

• Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
  
  
• Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
  
  
• Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Additionally, some "Getting Started" courses are available free of charge.
  
  
• Subscribe to the Rational Edge newsletter for articles on the concepts behind effective software development.
  
  
• Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download trial versions of IBM Rational software.
  
  
• Download these IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• The nature of the cookie poisoning risk
• The Sisyphean task of in-house session maintenance
• Application servers and engines: a solution and a problem
• What the involved vendors said
• Conclusions
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational AppScan Standard Edition
• Buy: Rational AppScan Standard Edition

Dig deeper into Rational on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers