Reflected XSS

Reflected XSS are not persistent and not stored in the web application database. However, they are processed by the back-end server. Some social engineering is required to trick a user with a reflected XSS. For example, the attacker needs to induces the victim to click on a malicious link.

Reflected XSS results from improper sanitization of users inputs.

When hunting for reflected XSS:

• Check what characters are sanitized.

• Identify where our user input get reflected in the response (use a canary).

• Try and verify any single input vectors (XSS Rats)

  • HTTP parameters

  • POST parameters

  • POST data

  • Hidden fields

  • Predefined radio or select input

Sometime, we could find an XSS that have no realistic impact. The impact of the reflected XSS we have found depends on the context of the web application and vulnerable request/parameters. However, even if the XSS found has no impact, being able to fire an XSS can inform the developers that the user input filtering is not optimal in the tested web application.