Mitigating the WASC Web Security Threat Classification with Apache: Part 2 | WebReference

Mitigating the WASC Web Security Threat Classification with Apache: Part 2


[next]

Mitigating the WASC Web Security Threat Classification with Apache: Part 2

By Ryan C. Barnett

Authorization

The Authorization section covers attacks that target a web site's method of determining if a user, service, or application has the necessary permissions to perform a requested action. For example, many web sites should only allow certain users to access specific content or functionality. Other times, a user's access to different resources might be restricted. Using various techniques, an attacker can fool a web site into increasing their privileges to protected areas.

Credential/Session Prediction

Credential/Session Prediction is a method of hijacking or impersonating a web site user. Deducing or guessing the unique value that identifies a particular session or user accomplishes the attack. Also known as Session Hijacking, the consequences could allow attackers the ability to issue web site requests with the compromised user's privileges.

Many web sites are designed to authenticate and track a user when communication is first established. To do this, users must prove their identity to the web site, typically by supplying a username/password (credentials) combination. Rather than passing these confidential credentials back and forth with each transaction, web sites will generate a unique "session ID" to identify the user session as authenticated. Subsequent communication between the user and the web site is tagged with the session ID as "proof" of the authenticated session. If an attacker is able to predict or guess the session ID of another user, fraudulent activity is possible.

Credential/Session Prediction Example

Many web sites attempt to generate session IDs using proprietary algorithms. These custom methodologies might generate session IDs by simply incrementing static numbers. Or there could be more complex procedures such as factoring in time and other computer-specific variables.

The session ID is then stored in a cookie, hidden form-field, or URL. If an attacker can determine the algorithm used to generate the session ID, an attack can be mounted as follows:

  1. Attacker connects to the web application acquiring the current session ID.
  2. Attacker calculates or Brute Forces the next session ID.
  3. Attacker switches the current value in the cookie/hidden form-field/URL and assumes the identity of the next user.

Apache Countermeasures for Credential/Session Prediction Attacks

There are several protective measures that should be taken to ensure adequate protection of session IDs.

  1. Make sure to use SSL to prevent network sniffing of valid credentials.
  2. Add both the "secure" and "httponly" tokens to all SessionID cookies. These two cookie options will help to secure the credentials by forcing the user's browser to only send this sensitive data over an SSL tunnel and also prevent scripts from accessing this data. The best solution for implementing this is to have the application developers update the code to include this parameter when generating/sending cookies to clients. It is possible, however, to have Apache add this token into the outbound cookie if you utilize Mod_Perl. You could implement a perl handler that can hook into the output filter of Apache with code such as this:

  3. Also with Mod_Perl, you can implement the Apache::TicketAccess module that was highlighted in the book Writing Apache Modules with Perl and C by Lincoln Stein and Doug MacEachern. This module was designed to have the client authenticate once, and then it issued a hashed "ticket"that is checked on subsequent requests. The hash is generated based on the following data: the user's name, IP address, an expiration date, and a cryptographic signature. This system provides increased security due to its use of the cryptographic signature and use of the client's IP address for validation. Due to the popularity of proxy servers these days, you could also update the IP address token to only check the Class C range of the data instead of the full address or you could substitute the X_FORWARDED_FOR client header that is added by many proxies.

Beyond Apache mitigations, session IDs should meet the following criteria:

  1. Session IDs are random. Methods used to create secure session credentials should rely on cryptographically secure algorithms.
  2. Session IDs are large enough to thwart Brute Force attacks.
  3. Session IDs will expire after a certain length of time. (1–2 days).
  4. Session IDs are invalidated by both the client and server during log-out.

By following these guidelines, the risk to session ID guessing can be eliminated or minimized. Other ways to strengthen defenses against session prediction are as follows:

  • Require users to re-authenticate before performing critical web site operations.
  • Tying the session credential to the user's specific IP addresses or partial IP range. Note: This may not be practical, particularly when Network Address Translation is in use.
  • It is generally best to use the session IDs generated by the JSP or ASP engine you are using. These engines have typically been scrutinized for security weaknesses, and they are not impervious to attacks; they do provide random, large session IDs. This is done in Java by using the Session object to maintain state, as shown here:
References

[next]

URL: