Issue type

PoC

Cross-site scripting

​alert(document.domain) or setInterval`alert\x28document.domain\x29` if you have to use backticks. [1] Using document.domain instead of alert(1) can help avoid reporting XSS bugs in sandbox domains.

Command execution

Depends of program rules:

• Read (Linux-based): cat /proc/1/maps

• Write (Linux-based): touch /root/your_username

• Execute (Linux-based): id

Code execution

This involves the manipulation of a web app such that server-side code (e.g. PHP) is executed.

• PHP: <?php echo 7*7; ?>

SQL injection

Zero impact

• MySQL and MSSQL: SELECT @@version

• Oracle: SELECT version FROM v$instance;

• Postgres SQL: SELECT version()

Unvalidated redirect

• Set the redirect endpoint to a known safe domain (e.g. google.com), or if looking to demonstrate potential impact, to your own website with an example login screen resembling the target's.

• If the target uses OAuth, you can try to leak the OAuth token to your server to maximise impact.

Information exposure

Investigate only with the IDs of your own test accounts — do not leverage the issue against other users' data — and describe your full reproduction process in the report.

Cross-site request forgery

When designing a real-world example, either hide the form (style="display:none;") and make it submit automatically, or design it so that it resembles a component from the target's page.

Server-side request forgery

The impact of a SSRF bug will vary — a non-exhaustive list of proof of concepts includes:

• reading local files

• obtaining cloud instance metadata

• making requests to internal services (e.g. Redis)

• accessing firewalled databases

Local file read

Make sure to only retrieve a harmless file. Check the program security policy as a specific file may be designated for testing.

XML external entity processing

Output random harmless data.

Sub-domain takeover

Claim the sub-domain discreetly and serve a harmless file on a hidden page. Do not serve content on the index page.