It is not unusual for Web servers to mishandle unanticipated user input. They fail to adequately address incorrect input and frequently provide verbose error messages that can provide valuable information to an attacker. For example, if a user incorrectly entered her user name information, the system might respond with an error message such as We were unable to find an account for this user name, click here to enroll. If the user inputs an incorrect password, the system might respond with an error message such as You have entered an incorrect password, you can reset it by clicking here.
Attackers can use overly informative error messages to either launch a denial-of-service attack or attempt to engage a brute-force attack against the password entry. A more appropriate error message is one similar to: There has been a user error; please provide the correct input. Auditors must be mindful that authorized user logons should never be the same as the user names used by the organization's e-mail naming conventions. From an attacker's point of view, the e-mail user naming convention being the same as the user name logon is having half the problem solved for a successful attack.
Some Web sites permit an unlimited number of failed sign-on attempts without being locked out. The vulnerability in this flawed practice is that user accounts can be compromised via brute-force attacks targeting the Web site's password entry.
Brute-force attacks are either manually or automatically performed where alphabetical and numerical combinations are tried as data entries to gain entry. From a preventive control stance, the sign-in policy should be that the user is locked out for a specified time after three failed sign-on attempts.
Experience Note Remember, even this policy is not without a threat potential in that an attacker can target the sign-on with incorrect data entry and lock out a legitimate user when she attempts entry. Having a viable and acceptable user reactivation policy is an important aspect of this preventive control.
There is a useful password-guessing tool to be found at www.tlsecurity.net/windows/cracker/webcracker.htm. This tool will automatically brute-force passwords in HTTP basic authentication and form-based authentication. Auditors should attempt to gain entry through brute-force methods as a means of testing entry security.
Another method that may have some success in defeating brute-force entry tools is to avoid direct linking to the sign-on function. For example, Web pages found behind the sign-on function should have a referrer field where the originating Web page of the user is checked against the allowed Web page URL, uniform resource locator.
Another method defeating some attacks is the error message, "inactivity timeout." This action causes the user's session to be terminated after a predefined period of inactivity. Auditors may test and verify this procedure by opening a Web page session in a sensitive area such as an E-commerce site where financial or personal information is collected. The server should terminate the session after predetermined period of user inactivity. This step prevents someone from hijacking the user's session.
More Unexpected User Input
There are a variety of ways that user input can be different from what was anticipated by the Web page developers. The size of the input can be too large, or too small. The input's content can be inappropriate in that alternate characters or executable scripts may be used causing the server to execute the input. Developers should incorporate user input screening in their programming routines. These are the types of input that should be filtered:
Experience Note User input must always be screened with all improper input denied.
Overflow Vulnerabilities
Improperly validated user input to the Content-Type header can cause a buffer overflow condition. As a result of nonvalidated user input, excessive data copied onto the data stack can overwrite critical parts of the stack frame such as the calling function's return address, potentially permitting remote code execution with root privileges on the Web server. It is important for auditors to determine if user input is checked for correctness and any input other than the expected input merely returns an error message.
Additionally, it is important that not only user-supplied input is screened and verified, but everything coming from the user's browser to the Web server should be filtered. Users can put executable code within the URL address and without proper filtering, it is possible that user input may be executed by the server.
