Web Server Offensive Security (Lab)

Configuring & Attacking the DVWA Web Server to Learn Web Vulnerabilities

Overview

During this lab, I virtualized Ubuntu for hosting the web application's server, and Kali Linux to run the IP in a browser. The specific exploits I experimented with where SQL Injection, Cross Site Scripting (XSS), Brute Force, and Server Side Request Forgery (SSRF). In this lab, I learned how to manage multiple virtual machine environments, how different web vulnerabilities function, how to configure a web application server, and the importance of web security. This paper is not to define the terms as I understand them, but rather outline my learning experience.

Previous Experience

I'm currently a Pscyhology B.S. major, so I have a good understanding of the biases, thinking and behavioral patterns that social engineer hackers exploit. I also have some experience with HackTheBox and TryHackMe, which platforms converge moreso around network hacking. I've read some PortSwigger articles, but I had never gotten into learning web vulnerabilities. So I decided to change that.

Web Vulnerabilities

Brute Force

The DVWA simply provides a log in text box to input a username and password. Experimenting, inputting random text, I was returned incorrect credentials warnings. I then thought to myself, perhaps there's a tool I can use. I'm familiar with John the Ripper, but that's for offline hash cracking. After some confusion and reading the official documentation, I realized I had slightly misconceived how the DVWA functioned. I thought I was trying to achieve a flag like HTB or THM. But I realized Brute Force isn't necessarily a coding limitation, it's a fundamental behavioral flaw embedded in how passwords work. Someone can literally try logging in over and over again, until it works. Seems primitive to someone in 2026, yet for something so simple we still haven't solved it.

SQL Injection

I was already familiar that SQL means Structured Query Language through my module learning. I knew SQL was a language designed to create and manage databases through queries. I was provided an input box saying "User ID." First, I began by inputting numbers. I noticed that these numbers stopped producing outputs after numbers 6+. I also noticed that it had no case handling for special charterers, returning an error 500. Another parellel I drew to enhance my concpetion, is that it's similar to prompt injection. The attacker is simply manipulating an AI (in this case the query language) to perform an unauthorized action by inputting code as data. I also learned about the different softwares that use SQL like PostgreSQL, SQLite, MariaDB, MySQL, and Microsoft SQL.

Cross Site Scripting (XSS)

While learning XSS I was suprised by how many versions it had. But after researching them, I realized they aren't as distinct as categorical isolation might make it initially feel. I also believed that because of the name, it had to do with multiple websites. But I was surprised to learn that some of them interact with a server. Reflective literally reflects an HTTP request from the victims browser off a server, Persistent saves to a server, and DOM happens entirely through the victims browser. I learned about the capabilities, such as the ability to deface a page, key log, perform actions as the victim, steal cookies and redirect the user. All XSS methods require user interaction to trigger the attack.

Server Side Request Forgery (SSRF)

SSRF is really interesting to me. it's important to clarify that though the DVWA didn't have a dedicated SSRF module, I still could conduct research. The first parallel I drew when understanding this exploit, was that it reminded me of XSS, is that you're manipulating the server in some sense. The main difference is that XSS stays client side, whereas SSRF is server side. Additionally, I decided to look up what else can occur, because independent I realized if someone has remote access to a server, that's an opportunity to begin analyzing the network, lateral movement, and ultimately moving from web exploitation to network exploitation. No user action is needed to cause an SSRF.

Additional

Before this, I had never configured a server to run on my computer. I also did not have Ubuntu configured as a virtual machine prior to this lab, only Kali Linux and FreeBSD. The primary operating system I used was Fedora Workstation on my ThinkPad T480.

To relate this to social engineering, it's interesting because XSS for example requires the user to perform an action. Attackers could leverage social engineering to explicitly design web pages in specific ways to produce those desired behavioral outputs.

Conclusion

By the end of this lab, I've enhanced my learning about server deployment and configuration, how servers relate to websites, and common web vulnerabilities. There's many more that I did not cover in this piece, but I plan to continue my education in web vulnerabilities. I hosted the The Damn Vulnerable Web Application server on an Ubuntu virtual machine, and ran the website on a Kali Linux virtual machine. I experimented with multiple different web vulnerabilities, taking notes and conducting addiional research as needed.