Since cookies come in the form of simple text files, they are a target-rich environment for intruders. Try these fixes to keep your Apache servers out of harm's way.
Cookies are one of those features of client-server interaction that you never think of unless they aren’t working. And when you sit pondering their positive attributes, you often don’t think beyond the fact that they let you passively log on to your favorite Web sites.
But if you’re in charge of an Apache-hosted dynamic Web site, you’ve got a lid on your cookie jar that an intruder can lift via session hijacking and cross-site scripting, among other techniques. Cookies are subject to analysis by hackers reading HTTP packets with an eavesdropper. Since Apache isn't immune to this intrusion, here is what can you do to secure your server against cookie theft.
The basic cookie recipe
Cookies exist to store state information in a client-server interaction implemented by a protocol (HTTP) which is otherwise stateless. A client browser stays in sync with a server based on information stored in the cookie—information from past HTTP interactions between that same client and server. If you’re not up on cookies, be aware that there are two basic types: per-session cookies and persistent cookies. A per-session cookie is a temporary cookie held in browser memory that lives only until the browser session ends. A persistent cookie is stored permanently on the client machine and is available for future sessions.
When Apache talks to a client, the server sends a header called Set-Cookie. The client replies with a header of its own, simply Cookie. You can control the attributes of your cookies, and the features of client-server exchange, by modifying the header. These attributes include the name and value of the cookie, an expiration date for the cookie, its valid Uniform Resource Identifier request path, the domain for which the cookie is valid, and a secure channel switch.
Standard cookie security
Because a cookie is just a chunk of text read by a browser, for obvious reasons it is vulnerable from the outset. A chunk of text is presumed to contain only data, rather than executable code. An attacking server, then, could conceivably embed executable script in a cookie that could be executed on the browser of the client, enabling a security breach in the direction of clients. But before looking at cookie weaknesses, let’s assess their strengths.
- Validation - When your Apache server sees an inbound cookie, it will check the cookie out to validate the incoming request. There are typically three items checked to establish the request’s validity: the cookie domain, path, and expiration date. If these do not pass inspection, the server can reject the incoming request.
- Browser configuration - On the browser side, users can configure for the disabling of cookies, for saving them, and for notification that a cookie session is active. Depending on the browser, a number of configurable subfeatures are available: disabling cookies altogether or only for selective Web sites; cookie management; enabling/disabling permanent cookie storage; and cookie maximum lifetime. Why are these useful security features? From the browser’s standpoint, they allow the client-side user to limit access to workstations and client-side resources by disabling attacks based on cookie data.
Serious cookie threats
Below are some threats common to cookies and their corresponding solution for protecting your network.
The simplest abuse of the cookie is obvious. It’s a simple text file, and the information contained in that header—domain, path, and expiration date—can obviously be manipulated to set up an illicit session between the target server and an unwelcome client.
Cookies can be proofed against manipulation through editing with the appendage of a Message Authentication Code (MAC). This code is a hash on the cookie content, and the server can know by decoding it on the other side whether the content of the cookie has been tampered with. Two common hash routines are MD5 and HMAC.
Spoofing with cookies
If the path and domain are not stored as parameters in a cookie by a Web application, then any server in a given domain can exchange the same cookie with a client. Therefore, one server can get a cookie meant for another by spoofing the DNS, drawing in a client, and establishing an illicit browser session. With this cookie, a hacker can then impersonate the user agent. This situation is a danger when multiple sites are hosted on a common server.
Always set the domain and path in the cookies parameters. Also, be sure to set a MAC code on your cookies (see above); it is also useful to embed machine-specific IDs so that a physical server may be matched to the domain and path.
Encrypt the contents of the header using encryption agreed upon between server administration and the clients. Or, more simply, you may encrypt server-browser exchanges with the SSL security switch in the cookie header. This feature, the SECURE attribute, allows you to limit the cookies' use to a secure channel (such as SSL). To enable this feature, set SECURE to TRUE. You can go a step further by installing an SSL certificate on your Apache server. Then your cookie exchanges will be SSL-encrypted.
Since cookies are often used to authenticate a user (this is how you can automatically log in to your favorite Web sites as a client), this authentication information is vulnerable to eavesdropping and later exploitation.
Authentication tokens can be substituted for the user ID and password in a stored cookie. If these are session-ID-based and can only be decrypted by the server, then stealing them does a hacker no good.
The security problems above may be addressed fairly simply in typical server configuration. More sophisticated cookie-based attacks are possible through the use of session hijacking and cross-site scripting. These will be addressed in a follow-up article. Finally, Apache servers can also put cookies to work proactively, employing client browser community tracking and management via cookies. This useful practice will also be addressed in a future article.