Stateless Versus Stateful Applications

Stateless Versus Stateful Applications

In the preceding section, we tracked Alice's session through the eWebMail application and examined how the application kept track of where she was at all times. However, can we say that the application was a truly stateful application? Every time an HTTP request was sent, the application learned of the user identity and the state from the cookie. The application then proceeded to act on the request and generate an HTML reply. Figure 13-13 shows how the application is invoked every time an HTTP request arrives.

Figure 13-13. Application flow chart for eWebMail

Every HTTP request coming to the application follows the same path. Thus the application isn't a truly stateful application. The term truly stateful refers to an application that keeps track of user sessions and states independently. In Web server terms, it implies that session tracking is performed on the server side.

Here the entire burden of session tracking is handed over to the client or the browser. Cookies are an easy way of passing information to the browser so that, in subsequent requests, the Web server will receive the same information back. Tracking sessions on the client side make for easy application programming. However, developers tend to forget the golden rule of Web application security: Any information coming from outside the boundaries of the Web server can be tampered with or tainted. That's exactly what happened in the Alice Bob Charles attack. Bob tampered with the cookie containing the session information, which caused the application to hand over Alice's data to Bob. Figure 13-14 summarizes the session hijacking attack performed by Bob.

Figure 13-14. Bob's interaction with eWebMail

Cookie Control, Using Netscape on a Unix Platform

The adage "Necessity is the mother of invention" couldn't better explain what one of the authors of this book came up with when he was looking for a solution to perform cookie filtering on Linux with Netscape. There is no equivalent of Cookie Pal for Linux. As a result, users rarely depend on permanent cookies in their day-to-day computing. Some users store their user credentials on cookies so that they don't have to log onto their favorite Web-based services every time they use them. Using cookies in this way isn't good computing practice in general. The author's solution for filtering cookies on Linux was to remove the Netscape cookies.txt file from the ~/.netscape directory and instead create a symbolic link, cookies.txt, to /dev/null.

Whenever Netscape is used for a browsing session, it holds all the cookies in its memory. If it receives a permanent cookie, it is written on the disk onto cookies.txt. In this case, the permanent cookie ends up in /dev/null! When the browser is closed, the memory is released and all the cookies are destroyed. A new browser session always begins without any cookies. This solution works much better than turning off cookies in the browser preferences. At times, applications require that cookies be turned on for proper functioning.

Browsers such as Opera provide excellent cookie control. Opera includes a feature that erases all cookies whenever Opera exits, which ends up being the same thing as symbolically linking cookies.txt to /dev/null.