Summary
Reflected Cross-site Scripting (XSS) is another name for non-persistent XSS, where the attack doesn’t load with the vulnerable web application but is originated by the victim loading the offending URI. In this article we will see some ways to test a web application for this kind of vulnerability.
Generated by OWASP PTK DAST Module
Solution
Reflected XSS attacks are the most frequent type of XSS attacks found nowadays. When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests to the client. Reflected attacks are delivered to the victim in various ways, such as in an e-mail message, or through some specially crafted URI. When a user is tricked into clicking on the malicious link, the injected code travels to the vulnerable web site, which reflects the attack back to the user\u2019s browser. The browser then executes the offending code because it came from a "trusted" server. Commonly the attacker's code is written in the Javascript language, but other scripting languages are also used, e.g., ActionScript and VBScript. Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g. download links). To remediate against reflected XSS vulnerabilities, strict filtering of HTML character encodings must be adhered to. In some cases, the web application may not be filtering some character encodings. For example, it may filter out "<script>", but might not filter "%3Cscript%3E" which simply includes another encoding of tags. A nice tool for testing character encodings is OWASP's CAL9000. Filtering of all information sent to the server via form POST/GET and URL query parameters with a particular emphasis on filtering out HTML-specific characters is advised.
Other Info
References
Code
src/ptk/background/dast/modules/modules.json