Brute Force in DVWA
Introduction
This post explores the brute-force vulnerability in the Damn Vulnerable Web Application (DVWA). The objective of the attack is to gain unauthorised access to the application by discovering valid login credentials through repeated login attempts.
Brute-force attacks can be carried out in several different ways. One common approach is a dictionary attack, where authentication attempts are made using lists of commonly used passwords. Another method is credential stuffing, which involves reusing username and password combinations obtained from previously leaked credential databases. A third technique, known as password spraying, tests a small set of common passwords across many accounts in order to reduce the risk of triggering account lockout mechanisms.
In this lab environment, a dictionary-based brute-force attack was performed using wordlists containing common usernames and passwords.
The analysis is carried out across three DVWA security levels: low, medium, and high, each introducing progressively stronger security controls.
A screencast demonstrating the attack process can be viewed below:
https://www.youtube.com/watch?v=Eu-UWxVegRY&t=19s
Attack Overview
| Parameter | Description |
|---|---|
| Target application | DVWA |
| Vulnerability class | Brute-force authentication |
| CWE | CWE-307 |
| OWASP Top 10 | A07:2025 - Authentication Failures |
| Attack vector | Web application login form |
| Security levels tested | Low, Medium, High |
| Tools used | Burp Suite, browser developer tools, Python script |
| Impact | Successful credential discovery (admin / password) |
Lab Environment
| Component | Configuration |
|---|---|
| Virtualization platform | Oracle VirtualBox |
| Attacker system | Kali Linux |
| Target system | Ubuntu Server 24.04 LTS |
| Application stack | Apache2, PHP 8.3.x, MariaDB |
| Vulnerable application | Damn Vulnerable Web Application (DVWA) |
| Network configuration | Host-only isolated network |
Vulnerability description
Low security level
At the low security level, the login page contains two input fields for a username and password, along with a login button.
An analysis of the source code shows that the application performs a direct authentication check against the database without implementing any protective mechanisms. In particular, the application lacks:
Rate limiting, which would restrict how many login attempts can be made within a certain period of time
Account lockout mechanisms, which temporarily disable an account after repeated failed login attempts
CAPTCHA verification, designed to distinguish human users from automated scripts
Authentication throttling, which slows down repeated login attempts and makes brute-force-attacks less effective
Because none of these protections are in place, an attacker can automate authentication attempts and systematically test a large number of username and password combinations until valid credentials are discovered.
As a result, the application is highly vulnerable to brute-force attacks.
Figure 1: DVWA login page containing the username and password authentication fields targeted in the brute-force attack.
Medium security level
At the medium security level, the authentication process remains largely unchanged. However, a basic mitigation mechanism has been introduced.
An analysis of the source code shows that the application implements a sleep(2) function that is triggered whenever authentication fails.
This causes the server to pause for two seconds before returning a response to each failed login attempt. While this mechanism does not prevent brute-force attacks, it significantly slows down automated login attempts.
For example, the delay limits the speed of authentication attempts to approximately:
2 seconds per attempt
approximately 30 attempts per minute
approximately 1800 attempts per hour
Although this delay increases the time required to perform a brute-force attack, it does not eliminate the vulnerability. An attacker can still automate the process and eventually discover valid credentials, given enough time.
High security level
At the high security level, an additional security control has been implemented in the form of a CSRF token (user_token).
The login form contains a hidden input field that includes a unique token value, which must be submitted together with the username and password parameters during authentication.
An analysis of the application behaviour shows that the token is regenerated every time the login page is refreshed. This mechanism is intended to ensure that authentication requests originate from the legitimate application interface.
Although this protection is designed to prevent cross-site request forgery (CSRF) attacks, it does not fully mitigate brute-force attacks. If an attacker is able to automate the retrieval of the token before each request, the authentication process can still be repeated with different username and password combinations.
As a result, brute-force attacks remain possible, although the attack becomes more complex to automate.
Attack Methodology
In this section, the attack methodology is mapped to the Cyber Kill Chain model.
Reconnaissance
The DVWA login page contains two input fields for a username and password. When invalid credentials are submitted, the application returns an authentication failure message. In contrast, valid credentials grant access to the application.
To understand how authentication requests are processed, Burp Suite was used to intercept and inspect the HTTP traffic generated by the login form.
Using Proxy → HTTP history, the authentication request was identified and analysed. The captured request contained the following parameters:
usernamepasswordLogin
In addition to these parameters, the request also included session-related cookies, such as:
PHPSESSIDsecurity level
Testing with invalid credentials revealed that failed authentication attempts consistently return responses containing the message “incorrect”.
Successful authentication responses differ both in content and in Content-Length, making it possible to distinguish valid login attempts during automated attacks.
This behavioural difference is particularly useful when configuring automated attack tools, as it allows the attacker to identify successful authentication attempts by analysing the server response.
Figure 2: Authentication request intercepted in Burp Suite Proxy showing the username and password parameters.
Weaponization
Using the information gathered during the reconnaissance phase, a brute-force attack was prepared using Burp Suite Intruder.
The captured login request was sent from Proxy → HTTP history to Intruder. In the Positions tab, all automatically generated payload markers were removed, and new markers were placed around the username and password parameters.
The attack type was configured as Cluster Bomb, which allows Intruder to test all possible combinations of usernames and passwords from two separate payload lists. The Cluster Bomb attack type is particularly useful when testing multiple username and password combinations simultaneously, as it generates every possible pairing from the provided wordlists.
Two wordlists were used:
a list of common usernames
a list of commonly used passwords
These lists were obtained from standard password dictionaries included in Kali Linux.
Figure 3: Payload positions configured in Burp Suite Intruder for the username and password parameters.
Delivery
The attack was delivered using Burp Suite Intruder.
After configuring the payload positions and loading the username and password wordlists, Intruder generated authentication requests for every possible combination of the provided credentials.
The same attack configuration was also used for the medium security level. However, due to the sleep(2) delay implemented in the application code, the server pauses for two seconds before responding to each failed authentication attempt.
This delay significantly slows down the brute-force attack by limiting the number of authentication attempts that can be performed within a given time period. However, it does not prevent the attack entirely, as automated tools can still continue sending requests over an extended period of time.
Figure 4: Username wordlists loaded into Burp Suite Intruder for automated authentication attempts.
Figure 5: Password wordlists loaded into Burp Suite Intruder for automated authentication attempts.
Exploitation
After launching the attack, Burp Suite Intruder began sending authentication requests using the supplied username and password combinations.
Most responses contained the keyword “incorrect”, indicating failed authentication attempts. These responses also shared similar Content-Length values.
However, one response differed from the others:
the response did not contain the keyword “incorrect”
the Content-Length was noticeably larger
These differences indicated that a successful authentication attempt had occurred.
To verify this finding, the identified username and password combination were manually tested on the DVWA login page. This confirmed that valid credentials had been successfully discovered.
Figure 6: Burp Suite Intruder results showing response length differences used to identify successful authentication attempts.
Figure 7: Successful authentication to the DVWA application using the discovered administrator credentials.
Automating the attack at the high security level
At the High security level, DVWA introduces an additional protection mechanism in the form of an anti-CSRF token (user_token). This token is included as a hidden parameter in the authentication request and must be submitted together with each login attempt.
Each time the relevant DVWA page is loaded, the application generates a new token value that is stored in the user's session. The server validates this token before processing the authentication logic. This mechanism is intended to ensure that requests originate from the legitimate application interface and to prevent cross-site request forgery (CSRF) attacks.
Because the CSRF token changes dynamically and is bound to the current session, previously captured authentication requests cannot simply be replayed during automated attacks. Tools such as Burp Suite Intruder normally rely on replaying a single request multiple times, which fails in this scenario because each request must contain a fresh token value.
In this lab environment, the attack was therefore automated with a Python script that handled both session management and dynamic token retrieval programmatically.
Session handling
The browser developer tools (Figure 8) display the active DVWA session cookie (PHPSESSID) and the configured security level (security=high). The attack script reuses this authenticated session in order to access the brute force module and retrieve valid CSRF tokens.
During testing, the Burp Suite Community Edition used in this lab environment did not fully support the automated session handling required to retrieve a new token before each request. As a result, the attack methodology was adapted by implementing a Python script capable of dynamically retrieving the token and performing authentication attempts programmatically.
Figure 8: DVWA session cookie visible in the browser developer tools, showing the active session (PHPSESSID) and configured security level (security=high).
Token extraction
To retrieve a valid CSRF token, the script sends a request to the DVWA brute-force page and extracts the user_token value from the returned HTML response. This is handled through dedicated helper functions rather than a single inline request, making the implementation easier to read and reuse.
A simplified version of this logic is shown below:
def get_brute_token(session):
response = get_page(session, BRUTE_URL)
token = extract_token(response.text)
if not token:
raise RuntimeError("Failed to extract CSRF token from brute-force page.")
return token
The extract_token() function uses regular expressions to identify the hidden user_token field in the HTML response. This process is repeated before every authentication attempt to ensure that a fresh token is always used.
Automated attack process
For each password candidate in the wordlist, the script performs the following steps:
request the brute-force page
extract a fresh CSRF token
submit a login attempt using the extracted token
analyse the server response for a success indicator
The authentication request is generated by combining the username, password candidate, login parameter, and the freshly extracted token:
def attempt_login(session, username, password, token):
params = {
"username": username,
"password": password,
"Login": "Login",
"user_token": token,
}
response = session.get(BRUTE_URL, params=params, timeout=TIMEOUT, allow_redirects=True)
response.raise_for_status()
return response
If the response contains the expected success string, the script stops and reports the discovered password.
By dynamically retrieving a new token before each request, the script replicates the behaviour of a legitimate client. This allows the brute-force attack to proceed despite the presence of CSRF protection.
Output verification
To make the automation process easier to verify, the final version of the script also includes a verbose mode. In this mode, the script prints the masked CSRF token used for each request, the HTTP status code, the response length, and the position of the success indicator in the returned HTML.
This made it possible to confirm that:
a new CSRF token was retrieved before each attempt
the same authenticated session was reused throughout the attack
the response changed when valid credentials were submitted
the success condition was detected by matching the known string
Welcome to the password protected area
This output was especially useful for validating the attack logic during testing and for demonstrating the behaviour in a reproducible way.
Discovered credentials
The attack ultimately succeeded in identifying valid administrator credentials:
Username: admin
Password: password
Figure 9 shows the terminal output produced by the Python script during the successful brute-force attempt.
Figure 9: Terminal output from the Python script showing the discovered password during the brute-force attack.
Source code analysis
The relevant section of the DVWA application source code confirms this behaviour:
<?php
if( isset( $_GET[ 'Login' ] ) ) {
// Check Anti-CSRF token
checkToken( \(_REQUEST[ 'user_token' ], \)_SESSION[ 'session_token' ], 'index.php' );
...
// Generate Anti-CSRF token
generateSessionToken();
?>
The server validates the submitted token against the session token and then immediately generates a new token after each request. As a result, previously captured tokens cannot be reused.
Full implementation
https://github.com/HexEmma/dvwa-bruteforce-csrf
Impact analysis (CIA)
The brute-force attack primarily affects confidentiality, as it allows attackers to gain unauthorised access to user accounts by discovering valid login credentials. In this experiment, the attack successfully identified valid credentials for the administrator account.
Once authenticated, an attacker could access restricted areas of the application and view sensitive information that is not intended for unauthenticated users.
The attack may also impact integrity, since an attacker who gains access to an account could modify application data, change configuration settings, or perform administrative actions depending on the privileges associated with the compromised account.
Although this attack focuses on credential discovery, availability could also be affected if a large number of automated authentication attempts are performed within a short period of time. Continuous brute-force attempts may consume server resources and negatively impact application performance.
The severity of this vulnerability varies depending on the configured DVWA security level. At the low security level, the absence of brute-force protections allows attackers to perform unlimited authentication attempts. At the medium security level, the implemented sleep(2) delay slows down automated attacks but does not prevent them. At the high security level, the presence of a CSRF token increases the complexity of automated attacks but does not eliminate the underlying vulnerability.
Severity Assessment (CVSS v3.1)
| Metric | Value |
|---|---|
| Base Score | 8.1 (High) |
| Attack Vector | Network |
| Attack Complexity | Low |
| Privileges Required | None |
| User Interaction | None |
| Scope | Unchanged |
| Confidentiality Impact | High |
| Integrity Impact | Low |
| Availability Impact | Low |
Mitigation strategies
Instead of allowing unlimited authentication attempts, the application should implement rate limiting to restrict the number of login attempts within a given time period. This significantly reduces the feasibility of automated brute-force attacks.
Another effective mitigation is the use of account lockout mechanisms, where a user account is temporarily disabled after a predefined number of failed login attempts. This prevents attackers from continuously testing password combinations against the same account.
Additional protections may include CAPTCHA challenges, which help distinguish legitimate users from automated attack tools and make large-scale brute-force attacks more difficult.
Strong password policies should also be enforced to ensure that user passwords are sufficiently complex and resistant to guessing attacks.
Finally, implementing multi-factor authentication (MFA) would significantly strengthen security, as access would require an additional authentication factor even if a password were compromised.
Although DVWA introduces a CSRF token (user_token) at the high security level, this mechanism primarily protects against cross-site request forgery attacks rather than brute-force attacks. As demonstrated in this experiment, automated credential guessing remains possible when the token retrieval process can be scripted.
Secure Implementation Example
The Impossible security level in DVWA demonstrates a more secure implementation of authentication handling by combining multiple defensive mechanisms against brute-force attacks.
In this version, the application introduces several important protections, including CSRF token validation, tracking of failed login attempts, temporary account lockout, and randomized delays between authentication attempts.
A simplified excerpt of the relevant logic is shown below:
// Check Anti-CSRF token
checkToken(\(_REQUEST['user_token'], \)_SESSION['session_token'], 'index.php');
// Lockout condition
if( $row['failed_login'] >= 3 ) {
\(timeout = strtotime(\)row['last_login']) + (15 * 60);
if( time() < $timeout ) {
$account_locked = true;
}
}
// Delay on failed login
sleep(rand(2,4));
In this implementation, the application tracks failed login attempts and temporarily locks the account after a certain number of unsuccessful tries. This prevents attackers from making unlimited login attempts.
To further slow down attacks, each failed login introduces a random delay of a few seconds. This makes automated brute-force attacks significantly less efficient.
The application also requires a valid CSRF token (user_token) for each request. While this is mainly intended to prevent CSRF attacks, it also makes brute-force attacks harder to automate.
After a successful login, the failed attempt counter is reset, and the login timestamp is updated. This ensures that the lockout mechanism works correctly.
Overall, this approach combines several security measures to reduce the effectiveness of brute-force attacks. However, the use of MD5 for password hashing is outdated and insecure. A more secure implementation would use modern hashing algorithms such as bcrypt or Argon2, along with additional protections like rate limiting and multi-factor authentication.
