Cookies, which have become essential features of Web site-browser interaction, are fundamentally simple. But they offer opportunities for surprisingly sophisticated attacks by intruders intent on breaching your Apache server’s security. Here’s how it’s done, and what you can do to prevent such attacks.

Cookie roles
To briefly recap, the role of the cookie in server-client interactions is simple: It’s a clear-text transmission of transaction state information stored on the client machine to create a static state record for an otherwise stateless transaction (HTTP being a stateless protocol). Since the cookie stores the session domain and path, the information in the cookie can be manipulated by an intruder to gain unauthorized access. It may also be used in the other direction, to smuggle malevolent executable code into client browsers.

Using the cookie to hijack a browser session
This breach is very bold. It exploits the SID (session ID), often embedded in the cookie. It has the advantage of being a transparent violation from the server’s point of view.

Here’s how it works. It is very common in Web applications to embed the SID within a cookie when the session is initiated. Why? Because the alternative is rewriting the URL, and that presents a minor security concern in itself: The URL is visible, so the rewritten version will display the SID. Often this is trivial, but why display the session ID openly when it’s not necessary? On the other hand, clear-text cookies are just as openly visible to the right pair of eyes—say, an eavesdropper. Once a malicious party has the SID, it becomes possible to copy the cookie, initiate contact with the server, and hijack the legitimate user’s session.

This form of intrusion has its limitations. Obviously, a hijacked session is time-constrained, requiring the attacking party to do their dirty work while the session is active. When the original user logs off and terminates the session, the hijacker is likewise terminated. Of course, depending on the intruder’s intent, this can be more than enough time. What can be done? There are several simple tricks that can defeat this hijacking scheme.

  • Reduce session time-out to the bare minimum. Consider that if a session has been hijacked, it can be terminated passively by a session time-out, meaning that the hijacker would have to start from scratch—whereas the original user would simply log in again. Trim session idle time down to the bone. Is it set for 30 minutes? An hour? Five minutes will do. If a session hijacker gets in, there won’t be time to do much harm.
  • If you’re going to embed the SID in the cookie, why not encrypt it first?
  • There are two kinds of cookie. One is the persistent cookie, or a cookie stored on the client machine’s hard drive (and therefore accessible to an intruder via the client machine’s network). But there is also the per-session cookie, which exists only for the duration of the session. Since it’s in the client machine’s memory, rather than hard storage, it is no longer easy to find and steal. So, when possible, use a per-session cookie.
  • Employ MAC codes with your cookies. This code is a value appended to the cookie, a hash value of the cookie’s contents. As long as this MAC value matches the cookie’s contents, the server knows the session is authentic. However, when an intruder steals a SID and embeds it in a false cookie, the cookie’s value will no longer match the hash value, and the server will know the cookie is false.

Cookies and XSS
Cross-scripting (XSS) is a widespread form of attack. It is increasingly common for Web sites to do dynamic interaction with clients, often permitting invalidated content to pass between client and user. When this happens, it’s open season on cookies—and a sophisticated intruder can steal the whole show.

How does it work? The intruder plants an alternate URL in an embedded link to a Web site on the server to be breached. When a legitimate user clicks on that link, the intruder redirects the user to another site (the intruder’s) and the session cookie passes from the original server to the intruder’s server. Zap—at a stroke, the user’s session has been hijacked and the attacker can redirect the user to the original server, none the wiser.

The question that now arises is how the intruder manages to plant a false URL in a Web site’s code if it didn’t have access to that Web site’s server to begin with. The answer is that it isn’t necessary. The user is tricked into establishing a session! The technique is nefarious, and in our current era of constant e-mail and Web-surfing, we never think twice! You’ll find these hidden redirects in messages with links that have encoded URLs, hiding the redirect. And the user encounters these links not on the Web site of the server being hacked, but in the place they’d least suspect: e-mail!

Think about it: We’ve all received e-mail messages with embedded links that will take us to a Web site, or to some source that gives us a follow-up to whatever news the e-mail is passing along. When a user clicks on such a link, he or she activates a machine’s browser and the masked URL sends the user to the site (establishing a cookie), then bounces the session to the intruder (dropping the cookie off in the process), whereupon it is bounced back to the original server.

How do you defend against such a sophisticated trick? This one requires attention at the application level, and an upgrade might be in order.

  • Apache 1.3.2 (and later versions) can be configured to defend against URL substitution. Upgrade!
  • Filter the metacharacters in a dynamic Web site data exchange. XSS attacks succeed because applications are sloppy about validating and filtering data exchanged in a dynamic session. Filter the metacharacters, and the alternate URL is thwarted.
  • Finally, look into the possibility of encoding all dynamic content for dynamic Web sites on your Apache server. Yes, it is cumbersome, but if you do so, you’ll be free of any cross-scripting security breaches.

Managing the session
Server security is about more than catching and stopping intruders. A secure server is one that knows its clients and follows their activities. Apache allows for cookie-based client tracking and session management. Techniques you can use along these lines will be discussed in an upcoming article.