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.
