Module 2 Lab SQL_Injection_Lab Explainer
Module 2 Lab SQL_Injection_Lab Explainer
1. Objective
To understand and demonstrate SQL Injection vulnerability using DVWA on a local system.
"In this lab, you're going to learn about one of the most common and dangerous web
vulnerabilities known as SQL Injection using a purposely insecure application called DVWA
– Damn Vulnerable Web Application. The goal is to understand how malicious users can
manipulate a website's input fields to send unexpected SQL commands to the server’s
database. For instance, let’s say a website asks for your user ID and sends something like
SELECT * FROM users WHERE id='1' to the database. If the input isn't properly checked, an
attacker could enter something like ' OR '1'='1 instead of a valid ID, which changes the
query to SELECT * FROM users WHERE id='' OR '1'='1'. This condition is always true, and it
can return all users' data instead of just one. Your task in this lab is to set up DVWA on your
own system using tools like XAMPP, experiment with such queries, and see firsthand how
easy it is to break into vulnerable systems—so you can learn how to protect them."
2. Tools Required
• XAMPP (Apache, MySQL, PHP)
• DVWA (Damn Vulnerable Web Application)
• Web Browser
• SQLMap (optional)
"To perform this lab successfully, we rely on a set of essential tools, each serving a unique
role in simulating a real-world environment. First, we have XAMPP, which is a software
package that bundles Apache (a web server), MySQL (a database management system), and
PHP (a scripting language)—everything we need to host and run dynamic web applications
locally on our machines without needing internet access. Next, we use DVWA, short for
Damn Vulnerable Web Application. This is a deliberately insecure PHP-based application
that is designed for practicing and learning about web vulnerabilities like SQL Injection in a
safe and legal environment. To interact with DVWA, we use a web browser—this is our
interface to submit input, view results, and simulate how a real user might interact with a
website. Finally, there's SQLMap, which is optional but incredibly powerful. It's an
automated tool designed to detect and exploit SQL injection flaws quickly. While DVWA
helps us understand the vulnerability manually, SQLMap shows how attackers use
automation to exploit such weaknesses on a larger scale. Together, these tools give us a
complete ecosystem to explore, understand, and defend against SQL injection attacks in a
controlled, educational setup."
3. Theory
Theory Explanation - SQL Injection and DVWA
SQL Injection (SQLi) is one of the most dangerous web application vulnerabilities that
occurs when an attacker can manipulate the SQL queries made by an application to its
database. SQL, which stands for Structured Query Language, is the standard language used
to interact with databases. When web applications accept user input—whether it’s from a
login form, search bar, or any other user input field—they often use this input in SQL
queries to retrieve or store information in the database. If the application doesn't properly
sanitize this input, malicious users can inject their own SQL code into these queries to
manipulate the database.
Imagine a real-world analogy: think of a restaurant where you order food by telling the
waiter your preferences, such as "I'd like a vegetarian pizza." If the waiter doesn’t check
your order carefully and simply repeats what you say to the chef, someone could walk up
and tell the waiter, “Give me all pizzas on the menu, and charge the customer a huge price.”
Now, instead of receiving just a pizza, the chef ends up giving them the entire menu, and the
customer is charged way more than expected. This is similar to SQL Injection—by
tampering with the request, the attacker gets more than they bargained for, and it can lead
to dangerous consequences, such as unauthorized access to sensitive data or even complete
control of the database.
Let's break this down with a real-world example using an application like a website’s login
form:
Normal Query: When you log into a website, the application might generate a SQL query
like:
This query is checking if there’s a user named "john" with the password "12345".
' OR '1'='1
Since '1'='1' is always true, the query returns data for all users, allowing the attacker to
bypass the login mechanism entirely. This is a simple example of a SQL Injection attack.
Data Breaches: SQL Injection can allow attackers to access sensitive information in the
database, such as usernames, passwords, personal details, and more.
Database Manipulation: It can also allow attackers to modify the database—deleting
records, inserting malicious data, or changing critical information.
Complete System Compromise: In severe cases, SQL Injection can enable an attacker to
execute arbitrary code on the server, potentially taking full control of the web application
and the underlying system.
To understand SQL Injection better, we are using DVWA, which is a deliberately insecure
web application designed for testing and learning about web vulnerabilities. DVWA is a
PHP/MySQL application that mimics a real-world scenario where you interact with a
vulnerable web app, just like you would on the internet. The difference is, here, it is meant
to be exploited and used for educational purposes.
Why DVWA? DVWA provides various levels of security, ranging from "low" to "high." It is
designed to help you practice finding and exploiting vulnerabilities in a controlled, legal,
and safe environment. In our lab, we will use DVWA to simulate SQL Injection attacks and
observe how attackers can manipulate the input fields on the web application to gain
unauthorized access to the database.
Real-World Example with DVWA: Let's say you are given access to a page in DVWA that asks
you for a user ID to view user details. A normal SQL query to fetch details might look like:
Now, if the input is not sanitized, an attacker can manipulate it to inject SQL code:
1' OR '1'='1
Instead of retrieving details of just one user, the query would return details of all users
because '1'='1' is always true.
In this case, the attacker bypasses the authentication mechanism or gains unauthorized
access to all the users’ data stored in the database, which is exactly what we’ll demonstrate
in this lab.
SQL Injection is one of the most widely known and common attacks. Despite security
advancements, many websites still fall victim to this vulnerability due to improper input
handling. Real-world examples of SQL Injection attacks have led to major data breaches in
companies, affecting millions of users. For instance, attackers may use SQLi to:
Steal users' personal data from databases.
In this lab, by demonstrating SQL Injection in a controlled setting, we aim to show both the
ease with which these attacks can occur and the critical importance of securing web
applications by preventing SQL Injection. Once we understand how SQLi works, we’ll learn
defensive techniques such as prepared statements, input validation, and other security best
practices to mitigate this vulnerability.
4. Setup Steps
1. Install XAMPP and start Apache and MySQL services
Steps to Implement:
2. Install the package and follow the on-screen instructions to complete the installation.
Click on the Start button next to Apache to run the web server.
Click on the Start button next to MySQL to run the database server.
Expected Output:
Both services should now show a "Running" status in the XAMPP control panel. You should
also see green-colored indicators next to Apache and MySQL, which confirm that both the
web and database servers are working properly.
Apache serves the web pages (including DVWA), and MySQL provides the database
functionality for storing and retrieving data. This is the foundation for running DVWA
locally.
---
2. Download DVWA from GitHub and place it in C:\xampp\htdocs\dvwa\
DVWA is a vulnerable web application designed specifically to practice and learn about web
security vulnerabilities, including SQL Injection. We need to download and place it in the
correct directory so that XAMPP can serve the application via Apache.
Steps to Implement:
3. Move the extracted folder (named DVWA) to the htdocs directory inside your XAMPP
installation directory. For example, if you installed XAMPP on the C drive, the path will be
C:\xampp\htdocs\dvwa\.
Expected Output:
After moving the folder, the path to DVWA should be C:\xampp\htdocs\dvwa\ and the
contents should include various files like index.php, config.inc.php, etc.
The htdocs directory in XAMPP is where Apache looks for web applications. By placing
DVWA in this folder, you are essentially making it available for access through a local web
server.
---
$_DVWA['db_user'] = 'root';
$_DVWA['db_password'] = '';
DVWA needs to connect to the MySQL database to function correctly. This configuration
step tells DVWA how to connect to the MySQL database on your local system by using the
username root and an empty password (as default in XAMPP).
Steps to Implement:
3. Look for the lines that define the database user and password, and modify them as
follows:
$_DVWA['db_user'] = 'root';
$_DVWA['db_password'] = '';
Expected Output:
No immediate visual output, but these changes ensure that DVWA will be able to connect to
your local MySQL database using the default XAMPP configuration.
This step configures the database connection for DVWA. XAMPP uses root as the default
username and an empty password for MySQL, and configuring DVWA to match these
settings ensures the application can successfully interact with the database.
---
allow_url_include allows the inclusion of remote files in your PHP code, which is necessary
for some DVWA features.
display_errors ensures that any errors are shown on the webpage, which is useful for
debugging and learning how attacks work.
Steps to Implement:
1. Open the XAMPP Control Panel, click on Config next to Apache, and select PHP (php.ini).
2. Once the php.ini file opens, search for the following lines and change their values:
allow_url_include = On
display_errors = On
Expected Output:
These changes will allow you to see error messages and enable certain features that may be
required for the SQL Injection attack later in the lab.
---
After making changes to the configuration files, it's important to restart the Apache service
so the changes take effect. Visiting http://localhost/dvwa will load the DVWA application in
your web browser.
Steps to Implement:
1. In the XAMPP Control Panel, click Stop and then Start next to Apache to restart it.
Expected Output:
You should see the DVWA homepage, which includes a login form where you can enter your
credentials. This confirms that DVWA is properly installed and running.
This step ensures that Apache is serving the DVWA application correctly. If you can't see the
DVWA login page, it indicates that there might be a configuration issue.
---
By logging in with the default credentials (admin and password), you access the DVWA
interface. Clicking "Create/Reset Database" initializes the database and sets up the
necessary tables for the application to function correctly.
Steps to Implement:
Username: admin
Password: password
2. After logging in, you will be directed to a page with a button labeled 'Create/Reset
Database'. Click it.
Expected Output:
DVWA will create the required database and tables. Once complete, it will show a success
message indicating that the database has been created or reset.
This step ensures that DVWA has all the necessary database tables set up before you begin
the lab, so the application can store and retrieve data during the SQL Injection
demonstration.
---
DVWA allows you to set different security levels. By setting it to Low, you make the
application vulnerable to attacks like SQL Injection, which is essential for the lab.
Steps to Implement:
1. After resetting the database, navigate to the DVWA Security tab in the DVWA interface.
Expected Output:
Once set to Low, the web application will be more vulnerable, allowing you to perform SQL
Injection attacks.
Setting the security level to Low ensures that the application is insecure enough for the SQL
Injection vulnerability to be exploited, simulating a real-world, poorly secured website.
---
By following these steps, you have successfully set up DVWA in your local environment to
practice SQL Injection. In the next part of the lab, we will start using the vulnerable inputs in
DVWA to test and exploit SQL Injection. This step-by-step process ensures you understand
both the setup and the vulnerabilities you're going to exploit.
Steps to Implement:
Username: admin
Password: password
3. In the menu on the left, look for and click on the SQL Injection option. This will bring you
to the SQL Injection page where we will begin interacting with the application.
Expected Outcome:
You should now be on the page where SQL Injection testing is performed. The page will
likely have a form asking for user input (e.g., an ID or name), and this is where we will start
testing for vulnerabilities.
Navigating to the correct tab in DVWA is crucial because this is the part of the application
designed specifically for practicing SQL Injection. By testing the inputs on this page, we can
begin exploiting the vulnerabilities of the application.
---
The purpose of entering normal input (1) is to understand how the application behaves
when it receives a valid, non-malicious input. This helps establish a baseline for the
application’s expected behavior before attempting to exploit the vulnerability.
Steps to Implement:
1. On the SQL Injection page, you will see an input field, typically asking for a user ID or
similar data.
Expected Outcome:
Upon submitting 1, you should see the details of the user whose ID is 1 (e.g., name, email,
etc.). This indicates that the application is querying the database for user information based
on the ID.
Entering normal input shows how the application is supposed to work when the user
provides valid data. This behavior helps us understand what the application is doing behind
the scenes, allowing us to test for vulnerabilities by manipulating the input.
---
SQL Injection occurs when user input is not properly sanitized, allowing an attacker to
manipulate SQL queries. By entering a malicious SQL statement like 1' OR '1'='1, we are
testing whether the application can be tricked into revealing more data than intended, thus
confirming the existence of a vulnerability.
Steps to Implement:
1. In the input field, replace the value 1 with the injection string:
1' OR '1'='1
This input works because '1'='1' is always true, so the SQL query will return all records,
bypassing the intended query constraints.
Expected Outcome:
Instead of seeing just the user with ID 1, the application will display the details of all users
in the database, as the injected SQL bypasses the usual filtering by ID. This confirms the
presence of a SQL Injection vulnerability.
By using the OR '1'='1' condition, we exploit a flaw where the application does not sanitize
user input properly. This step demonstrates the power of SQL Injection attacks and
confirms the vulnerability. The application is now displaying unintended data, showing the
potential security risks.
---
4. Try: 1' UNION SELECT user, password FROM users -- → Dumps credentials
Why are we doing this?
The UNION SELECT clause is used in SQL Injection attacks to combine the results of
multiple SELECT queries. In this step, we attempt to use the UNION operator to dump
sensitive information (like usernames and passwords) from the database. The -- marks the
beginning of a comment in SQL, effectively ignoring the rest of the query.
Steps to Implement:
1. In the input field, replace the value 1 with the following SQL injection:
user, password selects the user and password columns from the users table.
-- comments out the rest of the query (which would be the original SQL logic of the
application).
Expected Outcome:
The application should now display the usernames and passwords (or any other data stored
in the users table) of all users in the database. This shows how an attacker can use SQL
Injection to access sensitive information such as passwords.
This step demonstrates how an attacker can use UNION SELECT to extract data from other
tables in the database. It highlights the danger of SQL Injection vulnerabilities, as attackers
can retrieve sensitive user credentials or other confidential information from the database
without authorization.
---
SQLMap is an automated tool designed to detect and exploit SQL Injection vulnerabilities. In
this step, we use SQLMap to automate the process of extracting details from the database,
making the attack more efficient.
Steps to Implement:
1. Download SQLMap from the official website: SQLMap Official.
3. Run SQLMap by providing it with the URL of the vulnerable page, like so:
4. SQLMap will attempt to detect the vulnerability and automatically exploit it, listing the
databases and other details.
Expected Outcome:
SQLMap will provide a list of databases, tables, and other information, including user
credentials if the database is vulnerable. It will show something like this:
available databases:
* dvwa
* information_schema
SQLMap can automate extraction of even more sensitive information, such as passwords.
SQLMap is a powerful tool for automating SQL Injection exploitation, which demonstrates
the real-world impact of SQL Injection vulnerabilities. It helps security professionals
understand how attackers might use automated tools to exploit weaknesses in web
applications. By running this tool, you can see just how easy it is for an attacker to extract
sensitive data from a vulnerable application.
---
Conclusion
Each of these steps helps to demonstrate the SQL Injection vulnerability in DVWA and
highlights the severity of such vulnerabilities in real-world web applications. By starting
with basic injections and progressing to more advanced attacks using tools like SQLMap,
you can see how attackers exploit poorly secured web applications to access sensitive
information. These exercises are essential for understanding the importance of input
validation and database security in modern web development.
6. Observations
In this lab, the SQL Injection attack was successful, as we exploited the vulnerability in the
DVWA application by injecting malicious SQL queries into user input fields. This allowed us
to bypass the normal query structure and retrieve sensitive data from the database.
Specifically, we were able to extract usernames and hashed passwords from the users table,
which highlighted the application's lack of input sanitization. This exercise demonstrates
how insecure input handling can lead to data breaches, where attackers can manipulate
input to execute arbitrary queries, gaining unauthorized access to confidential information,
such as user credentials, and potentially compromising the security of the entire system.
7. Screenshots
[Paste your screenshots of setup, injection input/output, and SQLMap (if used)]
8. Conclusion
This lab demonstrates how dangerous SQL Injection can be if user inputs are not properly
sanitized. It highlights the need for prepared statements, validation, and secure coding
practices.
9. References
• https://github.com/digininja/DVWA
• https://portswigger.net/web-security/sql-injection
• https://owasp.org/www-project-top-ten/