Labs / ethical hacking

Web Application Testing Basics: Identifying SQLi and XSS

intermediate A purpose-built vulnerable web app (e.g. DVWA or similar) running locally in your own isolated lab — never a real site web-securitysql-injectionxss

Scenario

Authorization note: this lab must only be run against a purpose-built vulnerable web application (such as DVWA — Damn Vulnerable Web Application, published specifically for this kind of training) running locally in your own lab — never against a real or third-party website. Your goal is to manually confirm the two vulnerability classes from Web Application Security Basics, using the framework from SQL Injection Fundamentals and Cross-Site Scripting Basics.

What you need

  • A purpose-built vulnerable web app deployed locally (e.g. as a Docker container or VM on your isolated lab network), set to its lowest security level for this first pass.
  • A browser with developer tools available.

Step 1 — Baseline: use the login form normally

Log in with the practice app’s documented test credentials and confirm normal functionality works before testing anything.

Step 2 — Test the classic SQL injection pattern

On the app’s SQLi practice page, enter the conceptual test input from SQL Injection Fundamentals into the vulnerable field, for example:

' OR '1'='1

Observe whether the application’s behaviour changes in a way that suggests the input altered the underlying query logic (for example, returning unexpected results instead of an error or “no match”).

Step 3 — Test for reflected XSS

On the app’s XSS practice page, submit a harmless test string designed only to prove execution, such as:

<script>alert('test')</script>

If a popup appears, this confirms the input was rendered as executable code instead of literal text — proving the vulnerability without doing anything beyond a harmless proof-of-concept.

Step 4 — Compare against the app’s “high security” setting

Most purpose-built vulnerable apps let you raise the security level. Repeat Steps 2–3 at the highest setting and observe both attempts fail — this is a direct, hands-on illustration of parameterized queries (for SQLi) and output encoding (for XSS) actually working.

Step 5 — Write both findings properly

For each vulnerability, write a short finding using the structure from Penetration Test Reporting: impact, evidence (screenshot of Steps 2 and 3), and remediation (parameterized queries for SQLi, output encoding for XSS).

Break it

Try the same SQLi test string with different quote characters or capitalization and observe how fragile input-filtering-only defenses can be compared to true parameterization — a good, concrete point to bring up in an interview.

Reference

  • AddySec original content — written for the Ethical Hacking track, building on SQL Injection Fundamentals, Cross-Site Scripting Basics and Web Application Security Basics.