Testing for Brute Force (OWASP-AT-004)

Brief Summary
Brute-forcing consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem's statement. In web application testing, the problem we are going to face with the most is very often connected with the need of having a valid user account to access the inner part of the application. Therefore we are going to check different types of authentication schema and the effectiveness of different brute-force attacks.

Description of the Issue
A great majority of web applications provide a way for users to authenticate themselves. By having knowledge of user's identity it's possible to create protected areas or more generally, to have the application behave differently upon the logon of different users. Actually there are several methods for a user to authenticate to a system like certificates, biometric devices, OTP (One Time Password) tokens, but in web application we usually find a combination of user ID and password. Therefore it's possible to carry out an attack to retrieve a valid user account and password, by trying to enumerate many (ex. dictionary attack) or the whole space of possible candidates.

After a successful bruteforce attack, a malicious user could have access to:


 * Confidential information / data;
 * Private sections of a web application, could disclose confidential documents, user's profile data, financial status, bank details, user's relationships, etc..
 * Administration panels;
 * These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc..


 * Availability of further attack vectors;
 * Inner sections of a web application could hide dangerous vulnerabilities and contain advanced functionalities not available to public users.

Black Box testing and example
= Authentication Methods =

Unless an entity decides to apply a sophisticated web authentication, the two most commonly see methods are as follows:


 * HTTP Authentication;
 * Basic Access Authentication
 * Digest Access Authentication
 * HTML Form-based Authentication;

The following sections provide some good information on identifying the authentication mechanism employed during a blackbox test.

HTTP authentication

There are two native HTTP access authentication schemes available to an organisation – Basic and Digest.

Basic Access Authentication

Basic Access Authentication assumes the client will identify themselves with a login name ("owasp") and password ("password"). When the client browser initially accesses a site using this scheme, the web server will reply with a 401 response containing a “WWW-Authenticate” tag containing a value of “Basic” and the name of the protected realm (e.g. WWW-Authenticate: Basic realm="wwwProtectedSite”). The client browser will then prompt the user for their login name and password for that realm. The client browser then responds to the web server with an “Authorization” tag, containing the value “Basic” and the base64-encoded concatenation of the login name, a colon, and the password (e.g. Authorization: Basic b3dhc3A6cGFzc3dvcmQ=). Unfortunately, the authentication reply can be easily decrypted should an attacker sniff the transmission.

Request and Response Test:

HTTP/1.1 401 Authorization Required Date: Sat, 04 Nov 2006 12:52:40 GMT WWW-Authenticate: Basic realm="User Realm" Content-Length: 401 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1

1. Client sends standard HTTP request for resource: GET /members/docs/file.pdf HTTP/1.1 Host: target

2. The web server states that the requested resource is located in a protected directory.

3. Server Sends Response with HTTP 401 Authorization Required: HTTP/1.1 401 Authorization Required Date: Sat, 04 Nov 2006 12:52:40 GMT WWW-Authenticate: Basic realm="User Realm" Content-Length: 401 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1

4. Browser displays challenge pop-up for username and password data entry.

5. Client Resubmits HTTP Request with credentials included:

GET /members/docs/file.pdf HTTP/1.1 Host: target Authorization: Basic b3dhc3A6cGFzc3dvcmQ= 6. Server compares client information to its credentials list.

7. If the credentials are valid the server sends the requested content. If authorization fails the server resends HTTP status code 401 in the response header. If the user clicks Cancel the browser will likely display an error message.

The string QWRtaW46Zm9vYmFy== symply base64 decodes as follows: Base64 Decoded : owasp:password

Digest Access Authentication

Digest Access Authentication expands upon the security of Basic Access Authentication by using a one-way cryptographic hashing algorithm (MD5) to encrypt authentication data and, secondly, adding a single use (connection unique) “nonce” value set by the web server. This value is used by the client browser in the calculation of a hashed password response. While the password is obscured by the use of the cryptographic hashing and the use of the nonce value precludes the threat of a replay attack, the login name is submitted in clear text.

However, while both HTTP access authentication schemes may appear suitable for commercial use over the Internet, particularly when used over an SSL encrypted session, many organisations have chosen to utilise custom HTML and application level authentication procedures in order to provide a more sophisticated authentication procedure. Chiefly amongst these are:


 * Requirements for users to more fully identify themselves uniquely, beyond simple user name and password fields.
 * To provide a robust defence against brute force type attacks.
 * To better handle the client-server sessions, particularly their cancellation and expiry.
 * To overcome the nuances of a distributed, load-balanced site architecture, and client-side caching or proxy services.

Gray Box testing and example
Testing for Topic X vulnerabilities: ... Result Expected: ...