There are web applications that are vulnerable to Reflected cross-site scripting because these applications allow remote attackers to inject browser executable code within a single HTTP response. These applications fail to properly process the codes when the attacker uses the executable code as part of his custom URI or HTTP parameters.
A web application is vulnerable to reflected cross-site scripting attack when the application passes unvalidated input from the clients/end-users. In this attack, an attacker creates and tests a malicious URI and initiates a social engineering step, in which the attacker convinces his victims to execute the malicious URI on their browsers. This step by the user allows the execution of the malicious code on their browser. Usually, an attacker uses Javascript for performing this attack, but other scripting languages are also used. e.g., ActionScript and VBScript. An attacker leverages this vulnerability to install keyloggers and steal victim cookies, perform clipboard theft, change the content of the page and so on.
One of the main difficulty in preventing XSS is to implement proper character encoding. In some cases, the web application could not be filtering some encodings of characters. Consider the example where the web application might filter < script > tag, but might not filter %3cscript%3e. This text represents another encoding of tags.
https://www.example.beaglesecurity.com/index.php?user=john
Consider that the above page redirects to a page that has a welcome notice as “Welcome %username%” along with a download link.
The attacker will analyse the link and try to exploit XSS using user variable in hopes of triggering the vulnerability.
A successful execution of the above URL indicates that the site is vulnerable to XSS vulnerability. The above link allows an attacker can execute any script.
An attacker can perform attacks like:-
Beagle recommends the following fixes:-