Chapter 3: Managing Sessions - Hacking the Code ASP.NET Web Application Security [Electronic resources] نسخه متنی

Chapter 3: Managing Sessions

Introduction

For many Web sites, the user experience depends on the continuity of the user session. Since HTTP is a connectionless protocol, it is usually up to the Web developer to maintain some form of session persistence. When users browse through a Web site, they usually access multiple pages with different content on each page. Initially they visit one page, browse the contents of that page, then visit another page and continue until they are finished using that Web site. At that point they either close their browser or keep the browser open and continue on to a different Web site. To the user, it appears as one continuous session with the Web site they visit. But behind the scenes, the process is very different.

For each page visit, the browser makes several requests of the server for those elements required to render the page in the browser window. After retrieving those elements, the client closes the connection with the server. When retrieving the next page, the browser repeats the process, but the server has no idea that this request is connected to the previous request.

For that reason, the server needs to issue some kind of unique token that the browser can present with each visit to know which sessions are related. A token is an identifying string that is unique to each session. Using these session tokens, the server can treat a series of disconnected requests as if they were one continuous connection.

A server can assign two basic types of tokens:

Session tokens

Authentication tokens

Session Tokens

Session tokens create continuity between HTTP requests. A session token’s life usually begins with the first request a client makes to a server and ends either with the client closing the browser or after a specified timeout period. Session tokens are most often maintained through cookies, either as session cookies or persistent cookies, and are often automatically handled by the server application. The purpose of a session token is to track the entire interaction between client and server to provide the appearance of a seamless connection with the server. Session tokens apply to all requests, including anonymous requests.

Web developers use session tokens to maintain user preferences, track session variables, connect multiple forms, and maintain lists such as items in a shopping cart. Session tokens usually take the form of cookies because they provide an easy method to store information about a client.

Session tokens should be secure, but security is normally not critical for basic session management.

Authentication Tokens

Once a user authenticates to the server, rather than asking for credentials with each request, the server issues an authentication token that the user can submit with each request to prove his or her identity. The authentication token uniquely identifies an authenticated user. It is important to note that the authentication token is almost as sensitive as the user’s actual credentials except that the authentication token has a limited life span.

It is important to distinguish between session and authentication tokens. By keeping them separate, you can better optimize the settings of each and limit exposure to some types of attacks. For example, you can use the built-in ASP.NET state management features for session tokens and use more advanced techniques for authentication tokens.

In order to remain secure, a token must have certain properties. A token must:

Uniquely identify a client to the server, but not to anyone else

Not be usable by the client outside the scope of the application

Not be usable by anyone else

This chapter teaches you how to secure both session and authentication tokens in an ASP.NET application.

Understanding the Threats

The primary threats against token schemes that we address in this chapter are:

Token hijacking Being able to access another user’s token and potentially gain access to that user’s account.

Account hopping Manipulating an existing token to gain access to another user’s account.

Session fixation Providing another user with a known fixed token to authenticate and then gaining access to that user’s session.

Token prediction Guessing or predicting a valid session token because the token scheme uses a sequential or predictable pattern.

Token brute-force attacks Discovering a valid session token by submitting all possible combinations within the token’s key space.

Token keep-alive The process of periodically sending Web requests to keep a session token from expiring; often used with session fixation attacks.

Token manipulation Modifying a token on the URL or in a cookie to gain unauthorized access to an application.

Cross-site scripting An attack that involves injecting HTML or script commands into a trusted application with the purpose of hijacking a user’s cookie, session token, or account credentials.

Information leakage Improper token mechanisms may leak information about users or user configurations.

Phishing A form of man-in-the-middle attack in which the attacker lures a legitimate user to enter a password through a fake e-mail or Web form designed to look like that of a legitimate Web site.

The trouble with token schemes is that it is very difficult to design one that perfectly assures you that the token is from a legitimate user login and not an attacker. For example, a user might have a valid token, but it could be coming from a hacker who somehow discovered the token. You can determine if the token is coming from the same IP address to which you issued the token, but it might not actually be coming from the user’s computer, because that IP address could be a firewall or shared proxy server. Even if you do determine that the request is coming from the user’s computer, it might not be coming from the user’s login session. And even if you do determine that, it might not be coming from the user’s browser but instead from a Trojan, a virus, or a worm. And if you determine that it is coming from the user’s browser, the user might not have intended to send it but was the victim of a phishing or cross-site scripting attack. Finally, you don’t know if it is even the real user at the other end; it could be a coworker who knows the user’s credentials or who is using the browser session of a user who is out to lunch.

It is entirely possible with our current technology to create a mechanism that almost completely deals with these issues, but then new issues arise of compatibility, user acceptance, deployment, user training, developer training, and infrastructure support. Consequently, most Web applications end up with vulnerable token schemes saved as cleartext cookies sent over an unsecured connection. This chapter demonstrates how to get the most out of cookie security.