Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.
Issue remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:
Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised.
User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
The value of the callback request parameter is copied into the HTML document as plain text between tags. The payload 54668<script>alert(1)</script>f7213acd08e was submitted in the callback parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the TARGET request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3141e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e876337cf11b was submitted in the TARGET parameter. This input was echoed as 3141e"><script>alert(1)</script>876337cf11b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
There is probably no need to perform a second URL-decode of the value of the TARGET request parameter as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Header -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitiona ...[SNIP]... <INPUT type="hidden" name="Destination" value="HTTP://solutions.3m.com/wps/myportal/3M/en_US/OHES/Distributor/?WT.mc_id=OHESDistributor3141e"><script>alert(1)</script>876337cf11b"/> ...[SNIP]...
The value of the r request parameter is copied into the HTML document as plain text between tags. The payload 18624<script>alert(1)</script>e7cd51e722d was submitted in the r parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /php-bin/mjd_1317131663.php?gv=1&bid=&mid=479&r=www.shop3m.com18624<script>alert(1)</script>e7cd51e722d&mst=utmcsr%3Ddirect%7Cutmcmd%3Dnone&p=index&prk=1&fv=2.9&fv=2.9 HTTP/1.1 Host: live.monitus.net Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.187 Safari/535.1 Accept: */* Referer: http://www.shop3m.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Server: nginx/0.8.36 Date: Wed, 05 Oct 2011 17:20:20 GMT Content-Type: text/javascript Connection: keep-alive Vary: Accept-Encoding X-Powered-By: PHP/5.2.13 Cache-Control: max-age=0, no-store Expires: Fri, 02-Jan-1970 00:00:00 GMT Pragma: no-cache P3P: policyref="http://www.monitus.net/P3P/p3p.xml", CP="NON DSP CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS UNI COM NAV INT DEM" Content-Length: 2827
//--Monitus Tools code v2.9 //-- Copyright 2006-2011 Monitus LLC, All Rights Reserved.
The value of the zip request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 29cff"style%3d"x%3aexpression(alert(1))"339d9834413 was submitted in the zip parameter. This input was echoed as 29cff"style="x:expression(alert(1))"339d9834413 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The PoC attack demonstrated uses a dynamically evaluated expression with a style attribute to introduce arbitrary JavaScript into the document. Note that this technique is specific to Internet Explorer, and may not work on other browsers.
The value of the keyword request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ab934"><script>alert(1)</script>8f4983bcde6 was submitted in the keyword parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the keyword request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 25418"%3balert(1)//062be295512 was submitted in the keyword parameter. This input was echoed as 25418";alert(1)//062be295512 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 11124%2522%253balert%25281%2529%252f%252f8be92676f9f was submitted in the REST URL parameter 1. This input was echoed as 11124";alert(1)//8be92676f9f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2bbe3%2522%253balert%25281%2529%252f%252f1061ac20ebd was submitted in the REST URL parameter 2. This input was echoed as 2bbe3";alert(1)//1061ac20ebd in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4f625%2522%253balert%25281%2529%252f%252fc74391ad960 was submitted in the REST URL parameter 3. This input was echoed as 4f625";alert(1)//c74391ad960 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 3 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 81777%2522%253balert%25281%2529%252f%252f748f00a53a0 was submitted in the REST URL parameter 4. This input was echoed as 81777";alert(1)//748f00a53a0 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 4 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6d187%2522%253balert%25281%2529%252f%252f655a65f46ba was submitted in the REST URL parameter 1. This input was echoed as 6d187";alert(1)//655a65f46ba in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload de8d5%2522%253balert%25281%2529%252f%252f91afbb86344 was submitted in the REST URL parameter 2. This input was echoed as de8d5";alert(1)//91afbb86344 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7b1b8%2522%253balert%25281%2529%252f%252f9f31a8f21d1 was submitted in the REST URL parameter 3. This input was echoed as 7b1b8";alert(1)//9f31a8f21d1 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 3 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a4d2c%2522%253balert%25281%2529%252f%252f2b57422d777 was submitted in the REST URL parameter 4. This input was echoed as a4d2c";alert(1)//2b57422d777 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 4 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c2b58%2522%253balert%25281%2529%252f%252f42c7def327f was submitted in the REST URL parameter 5. This input was echoed as c2b58";alert(1)//42c7def327f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 5 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 6 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b0e54%2522%253balert%25281%2529%252f%252fc1796fd6c68 was submitted in the REST URL parameter 6. This input was echoed as b0e54";alert(1)//c1796fd6c68 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 6 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 67deb%2522%253balert%25281%2529%252f%252f87063d96adb was submitted in the REST URL parameter 1. This input was echoed as 67deb";alert(1)//87063d96adb in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9bb01%2522%253balert%25281%2529%252f%252fe9d2157136f was submitted in the REST URL parameter 2. This input was echoed as 9bb01";alert(1)//e9d2157136f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d86b2%2522%253balert%25281%2529%252f%252fb5d7e2a3826 was submitted in the REST URL parameter 3. This input was echoed as d86b2";alert(1)//b5d7e2a3826 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 3 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3babd%2522%253balert%25281%2529%252f%252fcc556bd7989 was submitted in the REST URL parameter 4. This input was echoed as 3babd";alert(1)//cc556bd7989 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 4 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 256f1%2522%253balert%25281%2529%252f%252f782b9fbcbd7 was submitted in the REST URL parameter 5. This input was echoed as 256f1";alert(1)//782b9fbcbd7 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 5 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 6 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b18df%2522%253balert%25281%2529%252f%252fa49788534ab was submitted in the REST URL parameter 6. This input was echoed as b18df";alert(1)//a49788534ab in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 6 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a5c18%2522%253balert%25281%2529%252f%252fd917b1be2dc was submitted in the REST URL parameter 1. This input was echoed as a5c18";alert(1)//d917b1be2dc in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f124c%2522%253balert%25281%2529%252f%252f5117e78d9c was submitted in the REST URL parameter 2. This input was echoed as f124c";alert(1)//5117e78d9c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 85885%2522%253balert%25281%2529%252f%252fab20fa63ac5 was submitted in the REST URL parameter 3. This input was echoed as 85885";alert(1)//ab20fa63ac5 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 3 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 47851%2522%253balert%25281%2529%252f%252fcccbe47ceee was submitted in the REST URL parameter 4. This input was echoed as 47851";alert(1)//cccbe47ceee in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 4 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 631e4%2522%253balert%25281%2529%252f%252fea1b4197830 was submitted in the REST URL parameter 5. This input was echoed as 631e4";alert(1)//ea1b4197830 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 5 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 6 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 841a9%2522%253balert%25281%2529%252f%252ff67be3321ea was submitted in the REST URL parameter 6. This input was echoed as 841a9";alert(1)//f67be3321ea in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 6 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5f280%2522%253balert%25281%2529%252f%252f9ee9d856a7a was submitted in the REST URL parameter 1. This input was echoed as 5f280";alert(1)//9ee9d856a7a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload df92c%2522%253balert%25281%2529%252f%252fc637b4220a8 was submitted in the REST URL parameter 2. This input was echoed as df92c";alert(1)//c637b4220a8 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6dfd4%2522%253balert%25281%2529%252f%252f9ff44154a8 was submitted in the REST URL parameter 3. This input was echoed as 6dfd4";alert(1)//9ff44154a8 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 3 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3c42a%2522%253balert%25281%2529%252f%252f81d5270967f was submitted in the REST URL parameter 4. This input was echoed as 3c42a";alert(1)//81d5270967f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 4 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload dbe6c%2522%253balert%25281%2529%252f%252fb68d71f599a was submitted in the REST URL parameter 5. This input was echoed as dbe6c";alert(1)//b68d71f599a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 5 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 6 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b83bc%2522%253balert%25281%2529%252f%252f847f04f9d54 was submitted in the REST URL parameter 6. This input was echoed as b83bc";alert(1)//847f04f9d54 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 6 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6be50%2522%253balert%25281%2529%252f%252ff264953ccc2 was submitted in the REST URL parameter 1. This input was echoed as 6be50";alert(1)//f264953ccc2 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload aec72%2522%253balert%25281%2529%252f%252fe636287b250 was submitted in the REST URL parameter 2. This input was echoed as aec72";alert(1)//e636287b250 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fb6a8%2522%253balert%25281%2529%252f%252f1bbf9499319 was submitted in the REST URL parameter 3. This input was echoed as fb6a8";alert(1)//1bbf9499319 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 3 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a5a6c%2522%253balert%25281%2529%252f%252f1e713f9d8ed was submitted in the REST URL parameter 4. This input was echoed as a5a6c";alert(1)//1e713f9d8ed in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 4 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d3f37%2522%253balert%25281%2529%252f%252ff0f97f61b00 was submitted in the REST URL parameter 5. This input was echoed as d3f37";alert(1)//f0f97f61b00 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 5 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 6 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8a792%2522%253balert%25281%2529%252f%252fa5abc0a59d3 was submitted in the REST URL parameter 6. This input was echoed as 8a792";alert(1)//a5abc0a59d3 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 6 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 38e88%2522%253balert%25281%2529%252f%252f0be1788ff8d was submitted in the REST URL parameter 1. This input was echoed as 38e88";alert(1)//0be1788ff8d in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 16ec4%2522%253balert%25281%2529%252f%252f3293b13a11c was submitted in the REST URL parameter 2. This input was echoed as 16ec4";alert(1)//3293b13a11c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload dc978%2522%253balert%25281%2529%252f%252fb4ecf93120a was submitted in the REST URL parameter 3. This input was echoed as dc978";alert(1)//b4ecf93120a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 3 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6fe37%2522%253balert%25281%2529%252f%252f0e539c8da90 was submitted in the REST URL parameter 4. This input was echoed as 6fe37";alert(1)//0e539c8da90 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 4 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c9a5d%2522%253balert%25281%2529%252f%252f4bf7848d23e was submitted in the REST URL parameter 5. This input was echoed as c9a5d";alert(1)//4bf7848d23e in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 5 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 6 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b1bca%2522%253balert%25281%2529%252f%252f3c5359236c7 was submitted in the REST URL parameter 6. This input was echoed as b1bca";alert(1)//3c5359236c7 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 6 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 79501%2522%253balert%25281%2529%252f%252f5d4c37295b2 was submitted in the REST URL parameter 1. This input was echoed as 79501";alert(1)//5d4c37295b2 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 32c81%2522%253balert%25281%2529%252f%252f4a8d5aec4d6 was submitted in the REST URL parameter 2. This input was echoed as 32c81";alert(1)//4a8d5aec4d6 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ef312%2522%253balert%25281%2529%252f%252ff9452d189b7 was submitted in the REST URL parameter 1. This input was echoed as ef312";alert(1)//f9452d189b7 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3ae99%2522%253balert%25281%2529%252f%252fedc79d9f9f9 was submitted in the REST URL parameter 2. This input was echoed as 3ae99";alert(1)//edc79d9f9f9 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9190c%2522%253balert%25281%2529%252f%252f57f65b3d75b was submitted in the REST URL parameter 1. This input was echoed as 9190c";alert(1)//57f65b3d75b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
Request
GET /retail9190c%2522%253balert%25281%2529%252f%252f57f65b3d75b/content.asp HTTP/1.1 Host: www.dunnedwards.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 404 Not Found Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 Set-Cookie: language=en-US; path=/; HttpOnly X-Powered-By: ASP.NET Date: Wed, 05 Oct 2011 17:12:05 GMT Connection: close Content-Length: 66690
The value of REST URL parameter 1 is copied into a JavaScript rest-of-line comment. The payload 8981b%250aalert%25281%2529%252f%252f795b01ba423 was submitted in the REST URL parameter 1. This input was echoed as 8981b alert(1)//795b01ba423 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2c9b0%2522%253balert%25281%2529%252f%252f20311e39e76 was submitted in the REST URL parameter 1. This input was echoed as 2c9b0";alert(1)//20311e39e76 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 1 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of REST URL parameter 2 is copied into a JavaScript rest-of-line comment. The payload ccd53%250aalert%25281%2529%252f%252fee008b70279 was submitted in the REST URL parameter 2. This input was echoed as ccd53 alert(1)//ee008b70279 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.