Web Application Security: SQL Injection & XSS

I worked through a web exploitation workflow in a deliberately vulnerable Cyber Range: identifying HTTP services, testing authentication, extracting database content, and demonstrating reflected and stored cross-site scripting. The aim was to understand how each vulnerability works, verify its impact, and explain the defenses that address it. These were guided lab scenarios with supplied targets and example payloads.

All testing was scoped to the lab network 10.0.56.0/24. I used the ToolBox host at 10.0.56.6 for Nmap, Hydra, sqlmap, and an HTTP listener. Athos provided a password-guessing exercise, Porthos exposed SQL injection, and Aramis provided the XSS scenarios.

The reflected-XSS heading in my original report lists a different address; the screenshots show Aramis at 10.0.56.9. This write-up follows the captured evidence.

I began with host discovery, then scanned individual hosts for services and versions. On Athos, browser developer tools showed that the login form sent a POST request with username and password parameters and returned “Invalid credentials” on failure. I used those details to configure Hydra’s HTTP form module with the rockyou.txt dictionary. Hydra found a valid password, and logging in returned the first lab flag.

nmap -sn -n 10.0.56.0/24
nmap -sV -sC -n 10.0.56.4

Enlarge

Enlarge

On Porthos, my notes record a database error after submitting a single quote in the username field. Using the supplied query structure, I tested a payload that closed the username string and commented out the password comparison. The application granted access as admin without a valid password.

Enlarge

Inside the application, developer tools showed that document searches used GET /admin with a q parameter. An always-true condition returned all documents. A UNION test with three NULL values established a compatible result shape; I then used information_schema to enumerate the database structure and extract the flags table.

Enlarge

I repeated the database enumeration and table extraction with sqlmap. The manual result explained how the query could be manipulated; the automated result reproduced the flag extraction from porthos_db.flags.

sqlmap -u "http://10.0.56.4/admin?q=Log" --dbs
sqlmap -u "http://10.0.56.4/admin?q=Log" -D porthos_db --tables
sqlmap -u "http://10.0.56.4/admin?q=Log" -D porthos_db -T flags --dump

Enlarge

Aramis reflected its query parameter into the search page. A heading tag rendered as HTML, and a script displaying “Hello” produced a browser alert. This established that input could execute as JavaScript in the application’s page context.

Enlarge

I started an HTTP listener on ToolBox and used the lab payload to send document.cookie to it. After the simulated user Alice followed the crafted link sent through the lab chat, the listener received her cookie. Setting the browser’s auth cookie to that value gave me access as Alice and exposed the reflected-XSS flag.

Enlarge

As Alice, I tested the comment field. The alert payload executed immediately and remained active after a reload, showing that the application stored and rendered the script. I then stored the cookie-capture payload and submitted the affected comments URL through the report feature.

Enlarge

The lab administrator’s visit triggered a request to ToolBox containing a flag cookie. Decoding its Base64 value revealed the final flag. This demonstrated execution in the administrator’s browser; the recorded outcome was recovery of that flag, not a separately verified administrator login.

Enlarge

The five flag outcomes belong to deliberately vulnerable applications. They demonstrate the techniques in this environment; they do not establish that the same payloads would work against a hardened application.

My report proposed rate limiting, progressive delays, temporary lockouts, and stronger authentication for password guessing. For SQL injection, the primary fix is parameterized queries, supported by least-privilege database permissions and error handling that avoids exposing database details.

For XSS, I identified context-aware output encoding, safe rendering of user content, and sanitization where HTML must be allowed. A restrictive Content Security Policy provides another layer. HttpOnly prevents JavaScript from reading an authentication cookie, while Secure restricts its transport to HTTPS; neither replaces fixing the injection point. These were proposed countermeasures, not changes I implemented and retested.

Inspecting the actual HTTP request was central to each step: the form parameters and failure message shaped the password test, and the search parameter exposed the database query surface. Working through SQL extraction manually before using sqlmap made the automated results easier to interpret. Comparing reflected and stored XSS showed how persistence changes the trigger: one needed a crafted link, while the other ran when a visitor opened stored content.