Mitigating the WASC Web Security Threat Classification with Apache / Page 3
[previous] [next]
Mitigating the WASC Web Security Threat Classification with Apache
Authentication
The Authentication section covers attacks that target a web site's method of validating the identity of a user, service, or application. Authentication is performed using at least one of three mechanisms: "something you have," "something you know," or "something you are." This section will discuss the attacks used to circumvent or exploit the authentication process of a web site.
Brute Force
A Brute Force attack is an automated process of trial and error used to guess a person's username, password, credit-card number, or cryptographic key.
Many systems will allow the use of weak passwords or cryptographic keys, and users will often choose easy-to-guess passwords, possibly found in a dictionary. Given this scenario, an attacker would cycle though the dictionary word by word, generating thousands or potentially millions of incorrect guesses searching for the valid password. When a guessed password allows access to the system, the Brute Force attack has been successful and the attacker is able access the account.
The same trial-and-error technique is also applicable to guessing encryption keys. When a web site uses a weak or small key size, it's possible for an attacker to guess a correct key by testing all possible keys.
Essentially, there are two types of Brute Force attacks: normal Brute Force and reverse Brute Force. A normal Brute Force attack uses a single username against many passwords. A reverse Brute Force attack uses many usernames against one password. In systems with millions of user accounts, the odds of multiple users having the same password dramatically increase. While Brute Force techniques are highly popular and often successful, they can take hours, weeks, or years to complete.
Brute Force ExampleApache Countermeasures for Brute Force AttacksUsername = Jon
Passwords = smith, michael-jordan, [pet names], [birthdays], [car names],
Usernames = Jon, Dan, Ed, Sara, Barbara, .....
Password = 12345678
There are a few different approaches that we can take to mitigate the effectiveness of Brute Force attacks against authentication used by our Apache server. We need to break down the different factors that influence the effectiveness of a Brute Force attack.
Weak Passwords
The bane of most every multi-user system's security is the fact that users will invariably choose weak passwords, as they are easier to remember. In order to help prevent a successful Brute Force attack, you must enforce a strong password policy. All passwords should have the following characteristics:
|
Unfortunately, Apache does not have a direct means to enforce this type of password complexity with its default password management tools: htpasswd and htdigest.In order to gain more robust password security capabilities, you should implement one of the many third-party authentication modules available for Apache at the Apache Module Registry site. A module such as Mod_SecurID
can implement a strong two-factor authentication component to help thwart Brute Force attacks. With two-factor authentication, the user supplies something they know (such as a password or PIN) and then they utilize something they have (in this case, a hardware device that generates a new random number string every 60 seconds). In order to gain access to a two-factor authentication system, the attacker would need to have physical access to the RSA SecurID FOB hardware token.
Suppress Verbose Error Messages
When an invalid username/password combination is submitted, do not inform the user which piece of information (either the username or password) was invalid. This may lend an attacker the ability to determine which accounts on the system exist. We will discuss this concept further in Chapter 8 when we are securing the Buggy Bank application, as it has this same vulnerability. We can leverage the output filtering capabilities of Apache 2.0 to alter/remove this type of information from web pages that are generated by an authentication program.
Creating Authentication Failure Awareness
When Apache is being used as a reverse proxy front-end for an application that is authenticating users, it is difficult for Apache to be "aware" that an authentication failure has actually taken place. This is a result of the nature of the different authentication transactions. The easiest authentication mechanisms for Apache to recognize are when Basic or Digest Authentication is being utilized. With these two mechanisms, the client submits an additional Authorization client header containing their credentials. If the credentials are incorrect, a 401 Unauthorized status code is generated. If you configured Apache to utilize CGI script for this status code, then you can potentially be alerted when a client fails authentication. We will discuss the concepts and techniques of using custom 401 and 403 CGI error scripts to monitor and track failed requests in a later chapter.
When a form-based authentication mechanism is used, it becomes a bit trickier to identify login failures, as the HTTP response status code is no longer an indicator of the success or failure of the login attempt. As long as Apache is able to successfully serve the desired page, it will generate a 200 OK status code. The authentication failure information will therefore have to be identified by different means. Here are two possibilities:
» Error message in html. As mentioned in the previous section on suppressing specific error messages, attackers will try and inspect the returned error messages, looking for any signs of information disclosure. You should work with your web developers to make sure that they update their error messages to contain benign information that will not be useful to the attacker. Although this information may not be leveraged by the attacker, it will be useful to Apache for identifying authentication failures. Let's say, for instance, that your authentication failure web page contains the following text: "Sorry, you did not supply the correct username or password." With this information, we can create a Mod_Security
filter to identify this data in the output stream returned to the client. Here is an example filter:
This new filter will identify the failure message being served to the client and trigger a 401 status code.
[previous] [next]
URL: