Reflected

This is XSS where the attack is local to the client side but the xss request is reflected off of the server and the link generates the activity only for the target users browser only. But Reflected XSS can be used to then send or store data to another location by requesting this activity of the browser in the reflected payload.

Payloads will be seen in the HTTP request and can be detected if seen by a security rule.

Common places to try:

• GET/POST variables

• Cookie variables

• HTTP Headers

• Web App user input channels

Look for input to be displayed on site somewhere then input HTML tags <h1> and <plaintext> are good to start with. H1 will make a bold looking header font and plaintext left open will break the rest of the site to appear as plaintext. Then also try JS to see if either of them make it to the output.

<plaintext> may work to break the site but filtering may still be up on other tags like img and iframe.

Example Vulnerable Code:

Server PHP

<?php $name = @$_GET['name']; ?>
Welcome <?=$name?>

For reflected attacks you will likely be crafting a URL to send to another user. In that case their own client view within the browser is being exploited and you have access to everything they do. A reverse shell can be a good choice here. Check XXS for the rshell sample.

The links can be obfuscated to be less apparent with URL Shorteners like Bitly or TinyURL. You could also poison iframes at legitimate URL locations to then make the XSS request behind the scene via the browser itself. Or link with a named hyperlink, like in documents or email bodies.