0% found this document useful (0 votes)
7 views

Module 2 Lab SQL_Injection_Lab Explainer

The document outlines a lab report focused on demonstrating SQL Injection vulnerabilities using the Damn Vulnerable Web Application (DVWA) on a local system. It details the setup process, including the installation of XAMPP and DVWA, configuration steps, and the theory behind SQL Injection attacks. The lab aims to educate users on exploiting these vulnerabilities in a controlled environment and emphasizes the importance of securing web applications against such attacks.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

Module 2 Lab SQL_Injection_Lab Explainer

The document outlines a lab report focused on demonstrating SQL Injection vulnerabilities using the Damn Vulnerable Web Application (DVWA) on a local system. It details the setup process, including the installation of XAMPP and DVWA, configuration steps, and the theory behind SQL Injection attacks. The lab aims to educate users on exploiting these vulnerabilities in a controlled environment and emphasizes the importance of securing web applications against such attacks.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

SQL Injection Lab Report using DVWA

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.

How SQL Injection Works:

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:

SELECT * FROM users WHERE username='john' AND password='12345';

This query is checking if there’s a user named "john" with the password "12345".

Malicious Injection: An attacker could input something malicious, such as:

' OR '1'='1

This turns the query into:

SELECT * FROM users WHERE username='' OR '1'='1' AND password='';

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.

Why is SQL Injection Dangerous?

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.

Introducing DVWA (Damn Vulnerable Web Application)

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:

SELECT name, email FROM users WHERE user_id = [user input];

Now, if the input is not sanitized, an attacker can manipulate it to inject SQL code:

1' OR '1'='1

This would change the query to:

SELECT name, email FROM users WHERE user_id = 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.

Why SQL Injection is Relevant Today?

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.

Perform administrative actions, such as deleting or modifying critical information.

Escalate their privileges and take over a website or web server.

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

Why are we doing this?

XAMPP is an easy-to-install Apache distribution containing Apache (web server), MySQL


(database), and PHP (scripting language). This tool allows you to host and run web
applications locally on your computer without needing to rely on an external server.

Steps to Implement:

1. Download XAMPP from the official website: XAMPP Download.

2. Install the package and follow the on-screen instructions to complete the installation.

How to Start Apache and MySQL:

After installation, open the XAMPP Control Panel.

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.

Why is this step important?

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\

Why are we doing this?

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:

1. Download DVWA from its GitHub repository: DVWA GitHub.

2. Extract the contents of the downloaded ZIP file.

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.

Why is this step important?

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.

---

3. Configure DVWA's config.inc.php file with:

$_DVWA['db_user'] = 'root';

$_DVWA['db_password'] = '';

Why are we doing this?

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:

1. Navigate to the C:\xampp\htdocs\dvwa\config folder and find the config.inc.php file.


2. Open the file in a text editor (such as Notepad++).

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.

Why is this step important?

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.

---

4. Enable 'allow_url_include = On' and 'display_errors = On' in php.ini

Why are we doing this?

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

3. Save the changes and close the php.ini file.

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.

Why is this step important?


Enabling allow_url_include and display_errors ensures that certain DVWA functions work as
intended and gives you visibility into the internal errors that might occur during
exploitation, which aids in learning and troubleshooting.

---

5. Restart Apache and visit http://localhost/dvwa in your browser

Why are we doing this?

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.

2. Open your web browser and visit http://localhost/dvwa.

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.

Why is this step important?

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.

---

6. Login (default: admin/password) and click 'Create/Reset Database'

Why are we doing this?

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:

1. On the DVWA homepage, enter the default login credentials:

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.

Why is this step important?

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.

---

7. Set Security level to 'Low' in DVWA Security tab

Why are we doing this?

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.

2. Select Low for the security level.

Expected Output:

Once set to Low, the web application will be more vulnerable, allowing you to perform SQL
Injection attacks.

Why is this step important?

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.

5. Performing SQL Injection


1. Navigate to 'SQL Injection' tab in DVWA

Why are we doing this?


The SQL Injection tab in DVWA is where you can test and exploit the SQL injection
vulnerability in a controlled environment. By navigating to this tab, you are ready to begin
interacting with the application, testing its inputs, and identifying potential vulnerabilities.

Steps to Implement:

1. Login to DVWA using the default credentials:

Username: admin

Password: password

2. Once logged in, you will be redirected to the DVWA homepage.

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.

Why is this step important?

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.

---

2. Enter normal input: 1 → User details are shown

Why are we doing this?

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.

2. In the input field, enter the number 1 (without quotes).

3. Click the Submit button.

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.

Why is this step important?

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.

---

3. Enter injection: 1' OR '1'='1 → Displays all users (vulnerability confirmed)

Why are we doing this?

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.

2. Click Submit to send the input.

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.

Why is this step important?

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:

1' UNION SELECT user, password FROM users --

Here’s what this does:

1' ends the current query.

UNION SELECT allows combining the results of a second query.

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).

2. Click Submit to execute the injection.

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.

Why is this step important?

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.

---

5. Optional: Use SQLMap to automate extraction of database details

Why are we doing this?

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.

2. Open a Command Prompt (or terminal on Linux/Mac).

3. Run SQLMap by providing it with the URL of the vulnerable page, like so:

sqlmap -u "http://localhost/dvwa/vulnerabilities/sqli/?id=1" --dbs

-u specifies the URL of the vulnerable page.

--dbs tells SQLMap to list the databases in the backend.

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.

Why is this step important?

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/

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy