LiveDocs Comments - coldfusion - 7 - htmldocs - 00000284.htm

coldfusion/7/htmldocs/00000284.htm

2008-07-13T21:11:39

There appears to be no way to make default to addtoken="false" - If you don't want tokens you must specify addtoken="false" for every single 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

coldfusion/7/htmldocs/00000284.htm

Giskard — 2005-09-21T06:40:21

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

Change:

To:

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

coldfusion/7/htmldocs/00000284.htm

sjibben — 2005-08-18T20:53:13

I have found a solution to my problem listed earlier.

Change:

To:

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.

coldfusion/7/htmldocs/00000284.htm

sjibben — 2005-08-17T14:26:56

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:

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!

coldfusion/7/htmldocs/00000284.htm

twillerror — 2005-06-14T08:52:32

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.

coldfusion/7/htmldocs/00000284.htm

jrunrandy — 2005-03-29T13:52:59

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 .

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

coldfusion/7/htmldocs/00000284.htm

MikerRoo — 2005-03-18T21:11:05

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:

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

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