Apache Security - Ivan Ristic [141]
Some dial-up users (for example, those coming through AOL) can have a different IP address on each HTTP request, as their providers route their original requests through a cluster of transparent HTTP proxies.
Finally, some users do not want their IP addresses to be known. They configure their clients to use so-called open proxies and route HTTP requests through them. It is even possible to chain many proxies together and route requests through all of them at once.
Even in the case of a computer with a permanent real (routable) IP address, many users could be using the same workstation. User tracking via an IP address would, therefore, view all these users as a single user.
Something had to be done to identify users. With stateful protocols, you at least know the address of the client throughout the session. To solve the problem for stateless protocols, people at Netscape invented cookies. Perhaps Netscape engineers thought about fortune cookies when they thought of the name. Here is how they work:
Upon first visit (first HTTP request), the site stores information identifying a session into a cookie and sends the cookie to the browser.
The browser does not usually care about the content of a cookie (there are some exceptions as we shall see later), but it will send the cookie back to the site with every subsequent HTTP request.
The site, upon receiving the cookie, retrieves the information out of it and uses it for its operations.
There are two types of cookies:
Session cookies
Session cookies are sent from the server without an expiry date. Because of that they will only last as long as the browser application is open (the cookies are stored in memory). As soon as the browser closes (the whole browser application, not just the window that was used to access the site), the cookie disappears. Session cookies are used to simulate per-session persistence and create an illusion of a session. This is described in detail later in this chapter.
Persistent cookies
Persistent cookies are stored on disk and loaded every time the browser starts. These cookies have an expiry date and exist until the date is reached. They are used to store long-lived information about the user. For example, low-risk applications can use such cookies to recognize existing users and automatically log them in.
Cookies are transported using HTTP headers. Web servers send cookies in a Set-Cookie header. Clients return them in a Cookie header. Newer versions of the standard introduce the names Set-Cookie2 and Cookie2.
Clients normally send cookies back only to the servers where they originated, or servers that share the same domain name (and are thus assumed to be part of the same network).
To avoid DoS attacks by rogue web servers against browsers, some limits are imposed by the cookie specification (for example, the maximum length is limited and so is the total number of cookies).
Further information on cookies is available from:
"Persistent Client State: HTTP Cookies" (the original Netscape cookie proposal) (http://home.netscape.com/newsref/std/cookie_spec.html)
RFC 2965, "HTTP State Management Mechanism" (IETF definition of Cookie2 and Set-Cookie2 header fields) (http://www.ietf.org/rfc/rfc2965.txt)
RFC 2964, "Use of HTTP State Management" (http://www.ietf.org/rfc/2964.txt)
Session Management Concepts
Session management is closely related to authentication, but while session management is generally needed for authentication, the relationship is not mandatory the other way around: sessions exist even when the user is not authenticated. But the concept is similar:
When a client comes to the application for the first time (or, more precisely, without having session information associated with it), a new session is created.
The application creates what is known as a session token (or session ID) and sends it back to the client.
If the client includes the session token with every subsequent request then the application can use its contents to match the request to the session.