SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.
Various attacks can be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and executing operating system commands.
Issue remediation
The most effective way to prevent SQL injection attacks is to use parameterised queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterised queries. It is strongly recommended that you parameterise every variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.
You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective:
One common defence is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defence is designed to prevent malformed data from terminating the string in which it is inserted. However, if the data being incorporated into queries is numeric, then the defence may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defence to be bypassed.
Another often cited defence is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.
1.1. https://hackalert.armorize.com/register.php/9f662%22%3E%3Cscript%3Ealert(document.location)%3C/_js/tooltips.js [name of an arbitrarily supplied request parameter]next
The name of an arbitrarily supplied request parameter appears to be vulnerable to SQL injection attacks. The payload ')waitfor%20delay'0%3a0%3a20'-- was submitted in the name of an arbitrarily supplied request parameter. The application took 45721 milliseconds to respond to the request, compared with 28377 milliseconds for the original request, indicating that the injected SQL command caused a time delay.
The REST URL parameter 2 appears to be vulnerable to SQL injection attacks. The payload 'waitfor%20delay'0%3a0%3a20'-- was submitted in the REST URL parameter 2. The application took 81191 milliseconds to respond to the request, compared with 15833 milliseconds for the original request, indicating that the injected SQL command caused a time delay.
Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.
Issue remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:
Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised.
User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
2.1. https://hackalert.armorize.com/register.php [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
https://hackalert.armorize.com
Path:
/register.php
Issue detail
The name of an arbitrarily supplied request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9f662"><script>alert(1)</script>25a9cf2398e was submitted in the name of an arbitrarily supplied request parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <meta http-equiv="X-UA-Compatible" content="IE=7"> <meta h ...[SNIP]... <a href="/register.php/9f662"><script>alert(1)</script>25a9cf2398e?status=setLanguage&languagecode=jp" style="color:#ffffff;"> ...[SNIP]...
2.2. https://hackalert.armorize.com/register.php [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
https://hackalert.armorize.com
Path:
/register.php
Issue detail
The name of an arbitrarily supplied request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a3be8"><script>alert(1)</script>d49d0fefd8eae8548 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
The value of the pass request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 63694"><script>alert(1)</script>26f259216e0 was submitted in the pass parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the pass_conf request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 8e2f0"><script>alert(1)</script>d553daa9606 was submitted in the pass_conf parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 67366"><script>alert(1)</script>0cdecdb0b1f was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload dbc66"-alert(1)-"a68063b8cfd was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload c152b%3balert(1)//5c04f315b79 was submitted in the REST URL parameter 2. This input was echoed as c152b;alert(1)//5c04f315b79 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7fe1a"-alert(1)-"a02149e3215 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 782fa%3balert(1)//ad57a65c4bd was submitted in the REST URL parameter 3. This input was echoed as 782fa;alert(1)//ad57a65c4bd in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload bd2bf"-alert(1)-"ffb533c75d8 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 82e26%3balert(1)//749e9e8db7b was submitted in the REST URL parameter 4. This input was echoed as 82e26;alert(1)//749e9e8db7b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 916ae%3balert(1)//8474c6649b6 was submitted in the REST URL parameter 2. This input was echoed as 916ae;alert(1)//8474c6649b6 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2a2ec"><script>alert(1)</script>e5103ddab74 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e223b"-alert(1)-"2bdabef8849 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 9d646%3balert(1)//fb3b62f33e5 was submitted in the REST URL parameter 3. This input was echoed as 9d646;alert(1)//fb3b62f33e5 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d6823"-alert(1)-"9033c12b731 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 3a955%3balert(1)//b478ccb9948 was submitted in the REST URL parameter 4. This input was echoed as 3a955;alert(1)//b478ccb9948 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 80f52"-alert(1)-"9203f59f7c4 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 9a8bb%3balert(1)//770fc431939 was submitted in the REST URL parameter 2. This input was echoed as 9a8bb;alert(1)//770fc431939 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a317c"><script>alert(1)</script>d80220df516 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ed003"-alert(1)-"31f203daed7 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload e9a10%3balert(1)//c68165ed25 was submitted in the REST URL parameter 3. This input was echoed as e9a10;alert(1)//c68165ed25 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7a4e4"-alert(1)-"9fb18383382 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ab26a"-alert(1)-"d481389cb03 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload af2ad%3balert(1)//23c1c2aca98 was submitted in the REST URL parameter 4. This input was echoed as af2ad;alert(1)//23c1c2aca98 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 2864d%3balert(1)//0b9758833f1 was submitted in the REST URL parameter 2. This input was echoed as 2864d;alert(1)//0b9758833f1 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 42087"><script>alert(1)</script>e5477b0b5c0 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 90547"-alert(1)-"d152766ca9f was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 11104%3balert(1)//b2747dc2468 was submitted in the REST URL parameter 3. This input was echoed as 11104;alert(1)//b2747dc2468 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a468b"-alert(1)-"f3421dcbcb2 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 3f88e%3balert(1)//0832fc1f8e6 was submitted in the REST URL parameter 4. This input was echoed as 3f88e;alert(1)//0832fc1f8e6 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4785c"-alert(1)-"a0ff127d5d1 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 10e54"><script>alert(1)</script>922f5c37426 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 2e50a%3balert(1)//ea1282f5d1e was submitted in the REST URL parameter 2. This input was echoed as 2e50a;alert(1)//ea1282f5d1e in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 22eef"-alert(1)-"0cf45b84078 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3697d"-alert(1)-"432bf243bd8 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload e9324%3balert(1)//7c25ddbf1fc was submitted in the REST URL parameter 3. This input was echoed as e9324;alert(1)//7c25ddbf1fc in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 869fa%3balert(1)//92ce6ba322 was submitted in the REST URL parameter 4. This input was echoed as 869fa;alert(1)//92ce6ba322 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b0303"-alert(1)-"4ec4b1aa242 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 650c9"><script>alert(1)</script>9f248f4ee0a was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload f2bc9%3balert(1)//bd29a3501f5 was submitted in the REST URL parameter 2. This input was echoed as f2bc9;alert(1)//bd29a3501f5 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f4206"-alert(1)-"913e1c1e16b was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 49768"-alert(1)-"8b0c87240d3 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload a3b1f%3balert(1)//5f017ecd6f6 was submitted in the REST URL parameter 3. This input was echoed as a3b1f;alert(1)//5f017ecd6f6 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 975b1%3balert(1)//04ecf96ce96 was submitted in the REST URL parameter 4. This input was echoed as 975b1;alert(1)//04ecf96ce96 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d6cc6"-alert(1)-"1e47b38900 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 49508"-alert(1)-"ce67ad602e0 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload e99de"><script>alert(1)</script>f6fa0c6c1d0 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 147a0%3balert(1)//485c1224fde was submitted in the REST URL parameter 2. This input was echoed as 147a0;alert(1)//485c1224fde in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload c1a64%3balert(1)//1b6fe37197 was submitted in the REST URL parameter 3. This input was echoed as c1a64;alert(1)//1b6fe37197 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 20c90"-alert(1)-"b132f8d09a2 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8926f"-alert(1)-"f19aa2bac8f was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 249f6%3balert(1)//3e8150a178d was submitted in the REST URL parameter 4. This input was echoed as 249f6;alert(1)//3e8150a178d in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 920fd%3balert(1)//d0c17cd4bb1 was submitted in the REST URL parameter 2. This input was echoed as 920fd;alert(1)//d0c17cd4bb1 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 20b97"-alert(1)-"dc963dafe8 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ab01d"><script>alert(1)</script>969ff5339f3 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload b26a0%3balert(1)//1733eab8f53 was submitted in the REST URL parameter 3. This input was echoed as b26a0;alert(1)//1733eab8f53 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9bbe7"-alert(1)-"470bc104df8 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 15e3c%3balert(1)//4e3caf563e2 was submitted in the REST URL parameter 4. This input was echoed as 15e3c;alert(1)//4e3caf563e2 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 26fbf"-alert(1)-"1ad15f73caf was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fa4ac"-alert(1)-"4fca0daf21e was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 97b0c%3balert(1)//cb3658c039d was submitted in the REST URL parameter 2. This input was echoed as 97b0c;alert(1)//cb3658c039d in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 439b6"><script>alert(1)</script>261e57805f1 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ed262"-alert(1)-"13226647afa was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload a33e2%3balert(1)//6439e6af149 was submitted in the REST URL parameter 3. This input was echoed as a33e2;alert(1)//6439e6af149 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2ea68"-alert(1)-"f90fe1cffa7 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload ad015%3balert(1)//904d991fa1a was submitted in the REST URL parameter 4. This input was echoed as ad015;alert(1)//904d991fa1a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 4d87f%3balert(1)//a580e806038 was submitted in the REST URL parameter 2. This input was echoed as 4d87f;alert(1)//a580e806038 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 65912"-alert(1)-"36e70dab0b6 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a4463"><script>alert(1)</script>a96f525d50a was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 9cbb1%3balert(1)//b17901411b9 was submitted in the REST URL parameter 3. This input was echoed as 9cbb1;alert(1)//b17901411b9 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 95898"-alert(1)-"9820e95774d was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload b8d64%3balert(1)//0d3ed02ba17 was submitted in the REST URL parameter 4. This input was echoed as b8d64;alert(1)//0d3ed02ba17 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 89320"-alert(1)-"f06115191a4 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload bb61a%3balert(1)//38f6240e10d was submitted in the REST URL parameter 2. This input was echoed as bb61a;alert(1)//38f6240e10d in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9d6d8"-alert(1)-"0adc505c1eb was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2efe3"><script>alert(1)</script>3ba901ba74 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f05a3"-alert(1)-"214e8f5794a was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload d6f1f%3balert(1)//6218b11bdf0 was submitted in the REST URL parameter 3. This input was echoed as d6f1f;alert(1)//6218b11bdf0 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload bb618"-alert(1)-"ef70f00db5d was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 4863e%3balert(1)//b1f86550f23 was submitted in the REST URL parameter 4. This input was echoed as 4863e;alert(1)//b1f86550f23 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a4a09"-alert(1)-"e384f70b3f4 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a9576"><script>alert(1)</script>5a922b5eb95 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload d9218%3balert(1)//490f97b6515 was submitted in the REST URL parameter 2. This input was echoed as d9218;alert(1)//490f97b6515 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 8feba%3balert(1)//2ba498cd550 was submitted in the REST URL parameter 3. This input was echoed as 8feba;alert(1)//2ba498cd550 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6a506"-alert(1)-"b57e03bf1c7 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 806b8%3balert(1)//78f6259811 was submitted in the REST URL parameter 4. This input was echoed as 806b8;alert(1)//78f6259811 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f823b"-alert(1)-"2cce22e77ac was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5205e"-alert(1)-"62b5fa0c680 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 279b5"><script>alert(1)</script>c0f57aac89d was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload d9303%3balert(1)//70ee3cf2d72 was submitted in the REST URL parameter 2. This input was echoed as d9303;alert(1)//70ee3cf2d72 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e828e"-alert(1)-"514b277815b was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 59a1a%3balert(1)//6e0a6fe9b6c was submitted in the REST URL parameter 3. This input was echoed as 59a1a;alert(1)//6e0a6fe9b6c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 544de"><script>alert(1)</script>eab4d33622d was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e00aa"-alert(1)-"54d51a680fa was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload b928a%3balert(1)//69c58adbbe8 was submitted in the REST URL parameter 2. This input was echoed as b928a;alert(1)//69c58adbbe8 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 77448"-alert(1)-"fe9f201249e was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 97a38%3balert(1)//b01b4a2a216 was submitted in the REST URL parameter 3. This input was echoed as 97a38;alert(1)//b01b4a2a216 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 8de3d%3balert(1)//bc5f299fbd3 was submitted in the REST URL parameter 4. This input was echoed as 8de3d;alert(1)//bc5f299fbd3 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a29f7"-alert(1)-"d3848583dbb was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 34c1e"-alert(1)-"a34dfbbcdd6 was submitted in the REST URL parameter 5. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload b3252%3balert(1)//431aa355168 was submitted in the REST URL parameter 5. This input was echoed as b3252;alert(1)//431aa355168 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d84e5"-alert(1)-"07bb3d4c9cb was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload c481b%3balert(1)//ca8ab330bbe was submitted in the REST URL parameter 2. This input was echoed as c481b;alert(1)//ca8ab330bbe in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload ec938"><script>alert(1)</script>a29f3fc93b was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload abf65%3balert(1)//2eee8c25453 was submitted in the REST URL parameter 3. This input was echoed as abf65;alert(1)//2eee8c25453 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e01ca"-alert(1)-"317cb53ca6e was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload aac1d"-alert(1)-"9f9190e1686 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 5c094%3balert(1)//fdc672a90d7 was submitted in the REST URL parameter 4. This input was echoed as 5c094;alert(1)//fdc672a90d7 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <meta http-equiv="X-UA-Compatible" content="IE=7"> <meta h ...[SNIP]... </images/captcha.php5c094;alert(1)//fdc672a90d7?status=setLanguage&languagecode=jp" style="color:#ffffff;"> ...[SNIP]...
2.110. https://hackalert.armorize.com/register.php/9f662%22%3E%3Cscript%3Ealert(document.location)%3C/images/captcha.php [name of an arbitrarily supplied request parameter]previousnext
The name of an arbitrarily supplied request parameter is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 24e26%3balert(1)//2269ba39bcf was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as 24e26;alert(1)//2269ba39bcf in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <meta http-equiv="X-UA-Compatible" content="IE=7"> <meta h ...[SNIP]... </images/captcha.php/24e26;alert(1)//2269ba39bcf?status=setLanguage&languagecode=jp" style="color:#ffffff;"> ...[SNIP]...
2.111. https://hackalert.armorize.com/register.php/9f662%22%3E%3Cscript%3Ealert(document.location)%3C/images/captcha.php [name of an arbitrarily supplied request parameter]previousnext
The name of an arbitrarily supplied request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 28e2a"-alert(1)-"b6c6b4036c0 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 39a94"-alert(1)-"72c6a72738c was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 984ba%3balert(1)//82be0326519 was submitted in the REST URL parameter 2. This input was echoed as 984ba;alert(1)//82be0326519 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 724cf"><script>alert(1)</script>cb344a084ee was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f9e3b"-alert(1)-"4865a24ba8f was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload b9135%3balert(1)//425f90b78df was submitted in the REST URL parameter 3. This input was echoed as b9135;alert(1)//425f90b78df in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload ba152%3balert(1)//0877ec22dea was submitted in the REST URL parameter 4. This input was echoed as ba152;alert(1)//0877ec22dea in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f03bf"-alert(1)-"dcb279790c0 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 864d5"-alert(1)-"fed4153d35d was submitted in the REST URL parameter 5. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 8de2b%3balert(1)//b495f829b9f was submitted in the REST URL parameter 5. This input was echoed as 8de2b;alert(1)//b495f829b9f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 6 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 968d4"-alert(1)-"3e0231fd4c3 was submitted in the REST URL parameter 6. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 6 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 1e82f%3balert(1)//7b7b9d040ef was submitted in the REST URL parameter 6. This input was echoed as 1e82f;alert(1)//7b7b9d040ef in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2c817"-alert(1)-"1c3e9f606d3 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 265d6"><script>alert(1)</script>72f5cd3ab87 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 62291%3balert(1)//7f394d80862 was submitted in the REST URL parameter 2. This input was echoed as 62291;alert(1)//7f394d80862 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 86533"-alert(1)-"7cff52bad78 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload b1fe9%3balert(1)//55dff5e2e6e was submitted in the REST URL parameter 3. This input was echoed as b1fe9;alert(1)//55dff5e2e6e in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 6d520%3balert(1)//44841a0c230 was submitted in the REST URL parameter 4. This input was echoed as 6d520;alert(1)//44841a0c230 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6f6c0"-alert(1)-"a6c7cdc283f was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 49fc1%3balert(1)//e5f7179fe3b was submitted in the REST URL parameter 2. This input was echoed as 49fc1;alert(1)//e5f7179fe3b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload f8f1b"><script>alert(1)</script>467b1bb9f7 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9e9df"-alert(1)-"11fb93fe642 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c94f8"-alert(1)-"44eff63519e was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 793d5%3balert(1)//2fea90d5d7d was submitted in the REST URL parameter 3. This input was echoed as 793d5;alert(1)//2fea90d5d7d in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload d24da%3balert(1)//a7e9a31a46a was submitted in the REST URL parameter 4. This input was echoed as d24da;alert(1)//a7e9a31a46a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 58a68"-alert(1)-"495c6efacbf was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 8c584%3balert(1)//2a1deb55774 was submitted in the REST URL parameter 5. This input was echoed as 8c584;alert(1)//2a1deb55774 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d2d19"-alert(1)-"3b076d4e827 was submitted in the REST URL parameter 5. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a2081"><script>alert(1)</script>dd2752b460 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 753da%3balert(1)//2b4d3e703f2 was submitted in the REST URL parameter 2. This input was echoed as 753da;alert(1)//2b4d3e703f2 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d9992"-alert(1)-"7269bcab6ee was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 707af"-alert(1)-"ed02f606ffa was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 8fae6%3balert(1)//d331dc424a5 was submitted in the REST URL parameter 3. This input was echoed as 8fae6;alert(1)//d331dc424a5 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 3ae1b%3balert(1)//d0063734710 was submitted in the REST URL parameter 4. This input was echoed as 3ae1b;alert(1)//d0063734710 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9ae23"-alert(1)-"63f8fb2bbda was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a6383"-alert(1)-"f0a51632d0d was submitted in the REST URL parameter 5. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 41927%3balert(1)//7eadb8d4895 was submitted in the REST URL parameter 5. This input was echoed as 41927;alert(1)//7eadb8d4895 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a0d02"-alert(1)-"a40efa800ea was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload ce270%3balert(1)//1e635729bf6 was submitted in the REST URL parameter 2. This input was echoed as ce270;alert(1)//1e635729bf6 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 43ea7"><script>alert(1)</script>3b6cb39c4f1 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 7ffbb%3balert(1)//c1552cd4887 was submitted in the REST URL parameter 3. This input was echoed as 7ffbb;alert(1)//c1552cd4887 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e2390"-alert(1)-"5d269465a6e was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 34f6c%3balert(1)//16e7e4ef2f8 was submitted in the REST URL parameter 4. This input was echoed as 34f6c;alert(1)//16e7e4ef2f8 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload df84a"-alert(1)-"ccbe163dc50 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 5fc10%3balert(1)//b61f4f2ef54 was submitted in the REST URL parameter 5. This input was echoed as 5fc10;alert(1)//b61f4f2ef54 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a26f4"-alert(1)-"aa027df5bd4 was submitted in the REST URL parameter 5. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c8159"><script>alert(1)</script>899067cda44 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8f7c9"-alert(1)-"1ebd3a6d5b was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 2b447%3balert(1)//d0b28f8b6f8 was submitted in the REST URL parameter 2. This input was echoed as 2b447;alert(1)//d0b28f8b6f8 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2de41"-alert(1)-"48785f170f9 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 85f38%3balert(1)//fa6b927070e was submitted in the REST URL parameter 3. This input was echoed as 85f38;alert(1)//fa6b927070e in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 5414d%3balert(1)//c7beb553e0c was submitted in the REST URL parameter 4. This input was echoed as 5414d;alert(1)//c7beb553e0c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ba565"-alert(1)-"8c0ac875e43 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 90972"-alert(1)-"31082f01fc3 was submitted in the REST URL parameter 5. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 21caf%3balert(1)//f62b4c6ef0b was submitted in the REST URL parameter 5. This input was echoed as 21caf;alert(1)//f62b4c6ef0b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 95ff1"-alert(1)-"35ac958f42a was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7dba1"><script>alert(1)</script>0b6a973ea52 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 3aa99%3balert(1)//3e00e5c246a was submitted in the REST URL parameter 2. This input was echoed as 3aa99;alert(1)//3e00e5c246a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 181bc%3balert(1)//20be249555b was submitted in the REST URL parameter 3. This input was echoed as 181bc;alert(1)//20be249555b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2b7c6"-alert(1)-"c002ab44339 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload c2837%3balert(1)//e5b5a6f8428 was submitted in the REST URL parameter 4. This input was echoed as c2837;alert(1)//e5b5a6f8428 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5da76"-alert(1)-"6662331f607 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 375fa"-alert(1)-"5ac38691248 was submitted in the REST URL parameter 5. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 8eaa9%3balert(1)//b81cbc5f155 was submitted in the REST URL parameter 5. This input was echoed as 8eaa9;alert(1)//b81cbc5f155 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 433f0%3balert(1)//14084ca8057 was submitted in the REST URL parameter 2. This input was echoed as 433f0;alert(1)//14084ca8057 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 792ef"><script>alert(1)</script>e1f3d67c07a was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3055c"-alert(1)-"93122f013fc was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload bcedc%3balert(1)//6543e4084bb was submitted in the REST URL parameter 3. This input was echoed as bcedc;alert(1)//6543e4084bb in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f9757"-alert(1)-"045df674128 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9b8c9"-alert(1)-"3ea4e91969 was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 7b7ae%3balert(1)//818c4ea74c5 was submitted in the REST URL parameter 4. This input was echoed as 7b7ae;alert(1)//818c4ea74c5 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f951a"-alert(1)-"d01d1512a01 was submitted in the REST URL parameter 5. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 5d51f%3balert(1)//a142d027bc5 was submitted in the REST URL parameter 5. This input was echoed as 5d51f;alert(1)//a142d027bc5 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload e38f4"><script>alert(1)</script>0e24bcb5c2b was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3b212"-alert(1)-"d168d7e1241 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 2 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload 10bac%3balert(1)//ebe47a7fa9d was submitted in the REST URL parameter 2. This input was echoed as 10bac;alert(1)//ebe47a7fa9d in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 81967"-alert(1)-"5385296e5c4 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 3 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload fe63e%3balert(1)//53c85f4fdad was submitted in the REST URL parameter 3. This input was echoed as fe63e;alert(1)//53c85f4fdad in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 65804"-alert(1)-"bb27b431bb was submitted in the REST URL parameter 4. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 4 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload b2477%3balert(1)//16f9bf8bc6a was submitted in the REST URL parameter 4. This input was echoed as b2477;alert(1)//16f9bf8bc6a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload fa52a%3balert(1)//e740129cc1c was submitted in the REST URL parameter 5. This input was echoed as fa52a;alert(1)//e740129cc1c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of REST URL parameter 5 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e4bd7"-alert(1)-"98d920a11b was submitted in the REST URL parameter 5. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Most browsers have a facility to remember user credentials that are entered into HTML forms. This function can be configured by the user and also by applications which employ user credentials. If the function is enabled, then credentials entered by the user are stored on their local computer and retrieved by the browser on future visits to the same application.
The stored credentials can be captured by an attacker who gains access to the computer, either locally or through some remote compromise. Further, methods have existed whereby a malicious web site can retrieve the stored credentials for other applications, by exploiting browser vulnerabilities or through application-level cross-domain attacks.
Issue remediation
To prevent browsers from storing credentials entered into HTML forms, you should include the attribute autocomplete="off" within the FORM tag (to protect all form fields) or within the relevant INPUT tags (to protect specific individual fields).
The following email address was disclosed in the response:
re@richarea.com
Issue background
The presence of email addresses within application responses does not necessarily constitute a security vulnerability. Email addresses may appear intentionally within contact information, and many applications (such as web mail) include arbitrary third-party email addresses within their core content.
However, email addresses of developers and other individuals (whether appearing on-screen or hidden within page source) may disclose information that is useful to an attacker; for example, they may represent usernames that can be used at the application's login, and they may be used in social engineering attacks against the organisation's personnel. Unnecessary or excessive disclosure of email addresses may also lead to an increase in the volume of spam email received.
Issue remediation
You should review the email addresses being disclosed by the application, and consider removing any that are unnecessary, or replacing personal addresses with anonymous mailbox addresses (such as helpdesk@example.com).
About the script: ----------------- Rich Calendar is 100% JavaScript calendar script. No pop-up windows. Skinnable and multilingual. Multiple calendar instances on one page. Allows to embed ca ...[SNIP]...
5. Cacheable HTTPS responseprevious There are 11 instances of this issue:
Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time.
Issue remediation
The application should return caching directives instructing browsers not to store local copies of any sensitive data. Often, this can be achieved by configuring the web server to prevent caching for relevant paths within the web root. Alternatively, most web development platforms allow you to control the server's caching directives from within individual scripts. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content:
