cflocation

<cflocation
   url = "url"
   addToken = "yes" or "no">

<h3>cflocation Example</h3>
<p>This tag redirects the browser to a web resource; normally, you would 
use this tag to go to a CF page or an HTML file on the same server. 
The addToken attribute lets you send client information to the 
target page.
<p>If you remove the comments, this code redirects you to CFDOCS home page:

<!--- <cflocation url = "http://localhost:8500/cfdocs/dochome.htm"
addToken = "no"> --->

Comments

MikerRoo said on Mar 18, 2005 at 9:11 PM :

CFLocation has a bug whereby it unduly fails when a carriage-return, or line-feed, is properly encoded in a url parameter.

Consider the following code -- which simulates a typical user input being passed in the URL:

<cfscript>
sCR_LF = Chr (13) & Chr (10);
sRawRemarks = "First Line. #sCR_LF# Second Line. #sCR_LF#";
sEncodedRemarks = URLEncodedFormat (sRawRemarks);
</cfscript>

<cflocation addtoken="no" url="#CGI.SCRIPT_NAME#?sRemarks=#sEncodedRemarks#">

The script name is legal. The URL variable, "sRemarks", has a legal value.
Yet cflocation trips an exception saying "Failed to perform redirection."

jrunrandy said on Mar 29, 2005 at 1:52 PM :

Yes. I believe that the full CF7 error is:

Failed to perform redirection.
ColdFusion was unable to perform the CFLOCATION operation.
Location URL cannot contain (carriage return) CR or (line feed) LF characters

The rule that CR and LF characters are not allowed in headers was added to CF7.
This is a general rule for all headers - including the headers created by <cflocation>.

This is an intentional change in CF7 to deter "split-response" security attacks, like those described in:
http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
http://seclists.org/lists/webappsec/2004/Jan-Mar/0263.html

twillerror said on Jun 14, 2005 at 8:52 AM :

The problem is not line feeds, but URL encoded strings.

%0A and %0D ( chr(10), chr(13) ) are actually okay, and will not cause http response splitting.

Essentially an response header is given to the browser. If an attacker makes the first thing a line break then can fool IE or Mozzilla into displaying content.

The problem in the document is that PHP was incorrectly take %0A and %0D and putting it in there. If CF does not URL decode the values then IE or Mozzila would not break.,

Furthermore the attack only works if the line feed is the first characters like to make the response looks something like this.

HTTP 302
Location:
HTTP 220
Look at me I think I'm a cool hacker.

I want this to happen in my code.

HTTP 302
Location:http://www.somesite.com/index.cfm?variable=%0A%Dae%2D

I'm really irritated that

A) they just stuck this in without telling anyone.
B) it ignore the switch to protect against cross site scripting that is in the administrator
C) That Macromedia is being take such a crappy stance on this. They did not all site around and really think about whether or not the solution was correct, just read some "tech doc" about it and stuck it in.

Please correct this problem. It is a bug, regardless of whether it was intential or not.

sjibben said on Aug 17, 2005 at 2:26 PM :

This change also breaks another implementation of URLEncodedFormat.

For example, it is very common for developers to use the following syntax for encrypting URL variables:

<cflocation url="myTemplate.cfm?myVar=#URLEncodedFormat(Encrypt(form.User,"somekey"))#" ADDTOKEN="Yes">

This works fine until Encrypt translates a perfectly normal user variable like 'JoeCool' to include CR or LF characters. Even though URLEncodedFormat is working correctly CFLocation throws an error. So, how is it possible to even encrypt URL variables with this implementation of CFLocation???

This needs to be corrected!

sjibben said on Aug 18, 2005 at 8:53 PM :

I have found a solution to my problem listed earlier.

Change:
<cflocation url="myTemplate.cfm?myVar=#URLEncodedFormat(Encrypt(form.User,"somekey"))#" ADDTOKEN="Yes">

To:
<cflocation url="myTemplate.cfm?myVar=#Encrypt(form.User,"somekey","CFMX_COMPAT", Hex")#" ADDTOKEN="Yes">

The 4th parameter "Hex" will convert the encrypted data to a hex stream which can be passed on the URL even though LF and CR may be embedded in it. Of course, you have to also add the 3rd and 4th parms to the Decrypt() statements to make it work.

Another bonus is that URLEncodedFormat() is not needed because there will be no special characters in the hex stream.

Giskard said on Sep 21, 2005 at 6:40 AM :

We had the same problem, and in addition to the previous solution, here's another method that works:

Change:
<CFLOCATION URL="myTemplate.cfm?myVar=#URLEncodedFormat(Encrypt(myValue, myKey))#" ADDTOKEN="Yes">

To:
<CFLOCATION URL="myTemplate.cfm?myVar=#URLEncodedFormat(Trim(Encrypt(myValue, myKey)))#" ADDTOKEN="Yes">

Adding Trim() around the Encrypt() function fixes this.

No screen name said on Jul 13, 2008 at 9:11 PM :

There appears to be no way to make <cflocation> default to addtoken="false" - If you don't want tokens you must specify addtoken="false" for every single <cflocation> tag.

The following trick will fix that. Put this at the start of every request: (I put mine in the onRequest function) This will cause there to never be any tokens regardless of the setting of addtoken

<cfset StructDelete(session, "urltoken") >