The task at hand was to integrate our system with a third-party site. I authenticate users locally, request a token from the third-party site that allows the user to access said site, and then redirect the user to that site with the token passed on the URL.

But how does the third-party site know to trust my requests and not the requests from other people? After all you don’t want people forging requests to access the third-party site as some other user. The solution for this third-party site is client certificates. A client certificate is either issued by the third-party site or you provide your public certificate to the third-party site and the third-party’s site is configured to trust the certificate. SOAP requests are then made over SSL using this certificate to confirm your identity and to encrypt the channel.

Starting with ColdFusion 8 CFHTTP accepts two parameters to afford the use of client certs, clientCert and clientCertPassword. The clientCert parameter points to a PKCS12 formatted file containing your public and private keys and, possibly, the certificate chain from the root certificate authority (such as VeriSign or Thawte) down to whoever issued your client certificate. The clientCertPassword parameter contains the password with which the PKCS12 file is encrypted.

A note to ColdFusion developers:
The PKCS12 must be encrypted with a password! For whatever reason (I believe a limitation in the underlying java.security.KeyStore object) your cert must have a password. This is never explicitly stated in the ColdFusion 8 documentation.

I obtained my client certificate and set out to start writing code to talk with this third-party.

The first problem I encountered was I would not be able to use the CreateObject() method covered in part 1. The reason being that there was no way to provide my client certificate to the object. So it’s back to the CFHTTP method.

The second problem I encountered had nothing to do with ColdFusion and everything to do with the documentation provided by the third-party. Turns out the header for the SOAP request changed considerably during development. I had been given some early development documents that did not reflect the current header structure. Once I realized the problem and obtained the current documentation I was able to correctly construct my SOAP request’s envelope header and…

I got another error.

But this time it wasn’t a normal SOAP request error. The CFHTTP object’s filecontent value contained nothing more than “Connection failure”. But the HTTP status code was 200, which indicates a successful request. Previous SOAP request errors would return a 403 status code. This was odd.

In searching the Adobe forums and the internet in general I found sparse comments about possible problems with CFHTTP handling SSLv3 sessions, although there wasn’t any sort of official comment or response to the few reports of this problem. I loaded up the developer edition of ColdFusion 9 on my own computer to see if perhaps this problem had been resolved with the latest copy of ColdFusion. It had not.

To confirm this as a problem with ColdFusion and not my client cert, or my SOAP request, I installed Apache and PHP locally and ran the equivalent PHP code. The PHP code worked perfectly. I started trying to do as much comparison between the two platforms as I could. I event went so far as to run a packet capture on the PHP and CF requests (pointing them at a dummy, local page that wasn’t encrypted so I could see the requests) and compared them to make sure everything was the same, which they were.

Eventually I found a post online that mentioned CFHTTP wasn’t up to the job, but a third-party custom tag written in C++ did work just fine. That custom tag is CFX_HTTP5. I downloaded a demo copy and installed it locally. How CFX_HTTP5 handles client certs is different from CFHTTP. Rather than simply pointing the tag at the client cert, I had to install the client cert into the Windows certificate store and then point the tag at the store. There is a bit of work involved with it, although nothing too difficult and it’s all covered in the CFX_HTTP5 documentation.

Once I had the tag and the certificate imported into the local Windows certificate store, I rewrote the CFHTTP call using CFX_HTTP5 and it worked! The SOAP envelope was the same, the headers were the same, the only difference between the two was the logic underlying the tags.

Something is broken with CFHTTP and it can’t be used to do some operations using client certificates. But at least there is an alternative.

However I didn’t like the alternative.

First, it’s a Windows-only solution. We’re out of luck if we’re running ColdFusion on a Linux machine.

Secondly, the client cert must be stored in a place that the ColdFusion process has permissions to access, and it is accessed without needing to know the client cert password. The result is that any person with permission to create CFM scripts that are executed under this process could authenticate against this third-party web site. In a shared hosting environment this can create a serious security issue. The only solution is to separate the process, but that probably means a separate server and a new OS license and hardware costs. If that option isn’t available you have some problems. You might register the CFX with a name that contains random characters and hope none of the users in the shared environment know how to enumerate registered custom tags. I’m not sure if that is possible, but I’m willing to bet it is.

Long story short, I don’t like the CFX_HTTP5 solution.

So I went back to the drawing board.

The method of obtaining the token is also fairly simple. The application submits a SOAP request over an SSL session to the third-party’s authentication server and that server would respond with the token. SOAP, for all the technical specs and other crap, is very straightforward. It’s a simple XML document consisting of a root element called ENVELOPE which contains two children called HEADER and BODY. The header isn’t always required and the body typically contains elements with the names of various fields the SOAP function your calling requires with each element containing the value of that parameter. Very straightforward.

A SOAP request in ColdFusion couldn’t be simpler, especially with the CFSAVECONTENT tag. Simply construct your envelope inside a CFSAVECONTENT tag and then use CFHTTP to submit the request. It looks a little something like this:

<cfsavecontent variable="variables.soap">
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetCurrentTime xmlns="http://ws.historicaloptiondata.com/" />
  </soap:Body>
</soap:Envelope>
</cfsavecontent>

<cfhttp
  url="http://ws.historicaloptiondata.com/Service.asmx"
  method="POST"
>
  <cfhttpparam type="header" name="SOAPAction" value="""http://ws.historicaloptiondata.com/GetCurrentTime""" />
  <cfhttpparam type="header" name="Content-Length" value="#Len( Trim( variables.soap ))#" />
  <cfhttpparam type="xml" value="#Trim( variables.soap )#" />
</cfhttp>

<cfdump var="#xmlParse( cfhttp.filecontent )#" />

You should be able to plug this code into a CFM file and run it without having to touch a thing and you should see the CFDUMP of an XML object. (I say “should” because xmlParse() seems to first try and open a file with the name of the content of the passed variable and, when that fails, treat the passed value as an XML document itself. This can trigger errors and make it unusable if you employ any sort of file operation restrictions on your server. In which case modify the code to remove the xmlParse() call and just dump the cfhttp.filecontent.)

A few notes about this code SOAP in general.

• This is an example of a SOAP 1.1 request. There is another, slightly different format known as SOAP 1.2. The major differences between the two are that the content-type for 1.1 is text/xml, but for 1.2 it is application/soap+xml. Also the SOAPAction HTTP header is no longer needed in 1.2.
• The SOAPAction HTTP header’s value must be wrapped in double-quotation marks. And sometimes the first character after the open quotes will need to be a pound (#) symbol. This means ColdFusion programmers will need to be certain they escape these special characters in their values.
• If the CFHTTPPARAM type “xml” is present, CFHTTP automatically sets the content-type to text/xml. I am not sure if it’s possible to override this, but I believe not, therefore you’re almost always going to have to stick with SOAP 1.1 if you’re using CFHTTP for your SOAP requests.
• You must Trim() the variables.soap variable! The newline at the beginning of the value, which exists because there is a newline immediately after after CFSAVEDCONTENT tag (for visual formatting purposes) will make the XML document you’re sending an invalid XML document and result in errors.

Now comes the WSDL file. A WSDL file is an XML documents that describes the functions and parameters of said functions available through a SOAP service. The CreateObject() function has a “webservice” object type which will consume a WSDL file and create an object with all the available functions offered by the SOAP service. All the stuff with XML and ENVELOPES and CFHTTP becomes transparent and, as it turns out, SOAP can be simpler than my previous example. The above code can be reduced to the following using CreateObject():

<cfset ws = CreateObject( "webservice", "http://ws.historicaloptiondata.com/Service.asmx?WSDL" ) />
<cfset ws.getCurrentTime() />
<cfdump var="#GetSOAPResponse( ws )#" />

This makes this life much simpler for ColdFusion programmers. No need to worry about what version of SOAP you’re using or what URLs you need to submit your request to, the formatting of your SOAP envelope, the SOAPAction HTTP header variable, etc. It’s all taken care of for you by ColdFusion.

So this integration I was asked to do should be a piece of cake, right?

Wrong.

Simple SOAP is simple. Complex SOAP… well, you’ll see in Part 2.

Output Buffering.

It’s something I first got use to with PHP. What it does is allow you to set a start and end point in your program and any output generated between those two points gets put into a variable which you can then manipulate further before outputting the content.

Recently I was asked if this was possible to do with ColdFusion. I couldn’t think of any existing feature that does this so I put together a (surprisingly) short custom tag that would do just that.

Here it is:

<cfif CompareNoCase( thistag.ExecutionMode, "start" ) EQ 0>
  <cfparam name="attributes.buffer" default="variables.buffer">
<cfelse>
  <cfset "caller.#attributes.buffer#" = thisTag.GeneratedContent>
  <cfset thisTag.GeneratedContent = "">
</cfif>


I put this into a file named buffer.cfm. Now anything that occurs between an opening and closing CF_BUFFER tag will be stored in a variable which can then be further manipulated however you want.

I did find something similar using getPageContext().getOut().getString(), but nothing simpler.

You might argue that this feature shouldn’t be needed in the first place. That whatever the need is it can be solved by redesigning the application. That might be true. But it’s a handy feature to play around with.

Case 1: Evaluate

Here’s the code:

<cfset session.isadmin = false>

<cfparam name="url.x" default="1">

<cfset variables.msg1 = "Welcome To Our Site">
<cfset variables.msg2 = "Site Administration">

<h1><cfoutput>#Evaluate( "variables.msg#x#" )#</cfoutput></h1>

<cfif session.isadmin is true>
  <p>You may now administer the site as you see fit.</p>
<cfelse>
  <p>Buy our product.</p>
</cfif>

This is now how you write CF, this is just a very simplified example to show you the problem that was discovered; in this case, it’s the Evaluate() line. Variable X is being passed on the URL in this example for simplification. In reality, there are any number of ways user-provided data could find it’s way into an Evaluate() statement. I’m just making it easy and obvious here.

Evaluate() will evaluate (and execute) the contents of the string that is passed to the function and return the result. The intention of the example above is to return the relevant message associated with the user’s level of access. Since X is supplied by the user it is possible to inject something into that Evaluate() line. But what?

Long story short, calling this script with the following URL will alter the isadmin session variable to change the user’s access level.
vulnerable.cfm?x=2+eq+'a'+or+SetVariable(session.isadmin,true)

This creates the following Evaluate() statement:
Evaluate( "variables.msg2 eq 'a' or SetVariable(session.isadmin,true)" )

The string now represents a boolean statement. Instead of returning the value of the string variables.msg2 it now will return TRUE or FALSE. And before it does that it will execute every expression in the statement, including a call to the function SetVariable() which alters the isadmin session variable. With that, the user is now an admin and will have full control of the application. What’s worse, more function calls could could be passed to the application which essentially give the user the same level of access to the machine as whatever user ColdFusion is running under. Especially under ColdFusion MX where CreateObject() can be used to create JAVA objects that provide system-level access.

Case 2: Evaluate in a CFQUERY

<cfsetting showdebugoutput="Yes">
<cfset variables.hack = "' OR 1=1 OR Name='">
<cfquery datasource="misc" name="test">
  SELECT *
  FROM Test
  WHERE Name = '#Evaluate( "variables.hack" )#'
</cfquery>

Again, I’m oversiplifying this a bit, but I’ll show you where this would happen in the real world once you understand what’s going on here.

variables.hack represents the point of injection. We assume this variable has a legit purpose but, at this point in the code execution, it’s value has been altered by a malicious user to what it’s set as in the code. The relevant portion of the SQL injection is OR 1=1 OR which will trigger the database to return all records instead of just the one record intended. There are many other things you can do when you’ve got a SQL injection point like this, but this isn’t about SQL injection it’s about how Evaluate() creates problems.

In ColdFusion, any variable in a CFQUERY block that is wrapped in single quotes ('#variables.string#') will be automatically escaped. In other languages like PHP you have to do this maually, but CF does it automatically. Escaping these strings prevents malicious users from injecting SQL commands into the query. It makes the database treat the string as just a string and not as a series of commands that’s part of the SQL statement.

If you were to run this script on a CF server you would discover that the string in variables.hack is NOT escaped. This allows SQL to be injected into the query. Why is this? The Evaluate() statement is wrapped in single quotes, so what gives?

Well.. actually, ColdFusion is working as intended. There are several passes of the SQL statement made by ColdFusion. The first pass handles the escaping of variables. The second pass handles executing functions and after that the SQL is passed on to the database. If you had something like:


<cfset variables.msg="hack'd">
<cfquery datasource="misc" name="test">
  SELECT *
  FROM Test
  WHERE Name = '#Evaluate( "variables.#msg#" )#'
</cfquery>


You would find the Evaluate() statement becomes:
Evaluate( "variables.hack''d" )

Two single-quotes is the escape sequence for a single quot e in SQL. The contents of the msg variable are escaped. After this escape, Evaluate() is executed. In this case it'd return an error since variable names can't contain single-quotes.

So you see, the escaping of variables occurs before Evaluate() is processed. This means the contents of whatever Evaluate() will not be escaped and provides a point of injection for an attacker.

The solution is to set the results of the Evaluate() call to a temp variable and use that temp variable inside the CFQUERY.


<cfset variables.test = Evaluate( "variables.hack" )>
<cfquery datasource="misc" name="test">
  SELECT *
  FROM Test
  WHERE Name = '#variables.test#'
</cfquery>


Where is this used in the real world? Arrays. Something where you loop through a number set, say 1 to 20, where you insert the Nth value in an array into the database. Something like SET data = '#Evaluate( "userdata[#X#]" )#' where userdata is an array that stores data provided by the user (form data, data pulled from a database that was set through another application, etc.)

This problem exists for other functions used in a CFQUERY.

That is, any function that performs an evaluation of a string will have the same problem. IIF() is one such function. I'm not sure what others there are off the top of my head, but it's definately something to think about.

So the point to remember is to never pass any data that, at any time could be set by the user, through Evaluate() and IIF().

And there you go. A couple exploit vectors (as the security guys say) in ColdFusion that you need to be aware of if you're a CF developer.

When working with a file that is used in an application, you almost always use cflock. Now I don’t mean you cflock whenever someone is uploading a file or you’re going to read from some random htm file (like a template system) because your application isn’t going to be altering the file’s contents (more than once, in the case of writing an uploaded file). But if you’ve got a file your application is going to read and write to throughout the application’s life, you need to protect against the chance two writes will occur at the same time. For example, in a user account claim application I have to write usernames to two separate files. One gets picked up by a process that creates e-mail accounts, another that creates LMS accounts. There’s a chance two people will try to claim an account at the same time. So I’ll cflock the file during the write, so no other CF process tries to write to the file at the same time. If that happened, you can wind up with a corrupt or empty file. Guestbooks, blog comments, etc are examples of applications where you’d cflock file access (assuming you’re using files and not a database).

Now why CFLOCK session variables?

Because you can’t assume a user will only make one connection at a time. When a user requests a page, the web browser begins to make several simulatneous connections to download the images, CSS files, javascript, etc.. on top of the HTML for the page. If you’ve got one or more of those files setup as a CFM (a dynamic image, dynamic stylesheet, who knows what) you’re application.cfm will run as well. If you’ve got logic in your application.cfm that manipulates session variables, you run the risk of having your session variables being changed in mid-process, creating either corrupted data (less likely) or incorrect data being acted upon (more likely).

For example, let’s say you’ve got a voting system. The voting system uses a session variable to set whether or not you’ve voted. A person logs into this system, makes their vote selection, and double-clicks the “vote” button. Your CF server now has 2 separate vote processes from the same person that it will process. The application logic is:

1. Check if allowed to vote
2. Record vote
3. Flag user as having voted

Step 2 is a database operation. In computer time, that step is going to take forever to process. While process 1 is working on step 2, process 2 comes along and passes the check in step 1, and gets in line for step 2. Process 1 moves on to step three and records the user has voted, but only after process 2 has started recording the vote for a second time.

Your user has now voted twice because of a race condidtion with session variables.

To fix this process you can do a couple things. You could put all three steps inside a single cflock block. You could swap steps 2 and 3 and then put steps 1 & 2 (check/record allowed to vote flag) then do your database options. The latter option frees the lock sooner to help keep resources to a minimum and is a potential speed increase but you might lose votes. You could wrap the database operation in a cftry/catch block and reset the flag if needed, but now you’re getting overly complicated in a system where just wrapping the 3 steps in a cfblock works fine.

So why not wrap every page in a cflock?

Because you will have pages that take a few seconds to process. If a user double-clicks a button, like in the example above, they will have to wait twice as long for the results to be displayed. If they get bored/angry at the wait, they might press that button 10 or 20 more times thinking it’ll go quicker, when in reality it’s only slowing things down. At that point, you’ve got 20+ processes waiting for that lock to open up. CFMX recommends your number of simultaneous processes allowed in CF be 3 or 4 times the number of CPUs in the machine. I’ll tell you that we have ours set to 12. (3 * 4 (2 P4s, each of which act like 2 separate processors)). So at 20+ processes, each waiting for that lock, each on the stack of running processes, you’re entire site (or your CF applications at least) grind to a halt. Now every user (not just the one) starts clicking on that button to speed things up. You eventually wind up with a really nasty situation where you’ve got hundreds (even thousands) of processes in the queue waiting to be processed by CF. Your site becomes unusable for minutes, maybe even hours.

That’s why you need to be very very efficient in your use of cflock. They can be a source of severe bottlenecking. I have a cf_sleep custom tag that gets CF to hang for a few seconds. I don’t use it much (if ever) but the way it works is by nesting cflocks on the same resource. Create a page with a 20 second sleep, reload it 20 times, and you’ll shut down the site for 20+ seconds. Very nasty.

If you can, set yourself up with a performance monitor (this is a Windows thing. start->run->perfmon) set on your CF server and you can see this in action yourself. (Assuming you’re setup, monitoring all the CF related monitors.) Turn on highlighting in your performance monitor (CTRL+H or click the lightbulb icon in the top toolbar). Then select the “running requests” monitor from the list in the bottom section of the performance monitor window. The highlighted (white) line you see shows you how many current requests are being processed.

Create a script with a 20 second sleep in it. Load the page then check your performance monitor and you’ll see that there is 1 process running. Now hold down CTRL+R in your browser for a few seconds. You’ll get maybe a couple hundred of these processes going. Now check out the performance monitor. The running requests will max out at 12 (which is what I set it to as mentioned earlier). Now check out the “queued requests” monitor and see how that spikes up.

The site is essentially useless while you wait for those processes to finish. All this because of 1 user holding down CTRL+R in a browser for a few seconds. That’s the downside of cflock (and any slow ColdFusion page). Try changing the page so the sleep is only a second and do it again. The server takes a little longer to go unresponsive, and it recovers more quickly. But you start to see how CF can be exploited.

There’s a configuration option to kill any process that runs over X seconds long in the administrator interface. That offers some protection from prolonged denial-of-service attacks, but not much. (I typically set it to 30 seconds, but 5-10 seconds might be better for most people.)

Increase the number of simultaneous requests? That only prolongs the inevitable and when you hit that max, it takes much longer to recover because your server is doing a lot more than it can handle.

So be careful of bottlenecks in your CF code, CFLOCK being potentially one of the biggest in your application.

Session variables are a place to store information specific to the user and to the current session (such as whether or not a user is logged in).

It is possible to hijack a user’s session by supplying the correct CFID and CFTOKEN values to the server, either on the URL, or wherever else you want.

The two numbers combined represent a space of 10^15 numbers. Average brute force will take half that amount, so 10^15/2. Figure 100 attempts per second, and the average time it would take to brute force is in the neighborhood of 150,000 years.

There’s the 1 in a jillion chance someone might guess a correct CFID and CFTOKEN, but that doesn’t really worry me much.

Your more likely to see someone hack your application by doing a little packet sniffing (or looking over someone’s shoulder) and capturing the CFID and CFTOKEN that way.

Packet sniffing you can curb by going over SSL with your application. Over-the-shoulder attacks can be stopped by not passing the CFID and CFTOKEN values on the URL (which CF does with cflocation tag by default… go figure).

If the user has a virus on their machine passing out their cookies, well that user has a bigger problem than having their session hijacked.

So how do you protect against session hijacking? You store the IP address as a session variable. Compare the IP in the session variable to the user’s IP (stored in cgi.remote_addr) and if they don’t match, you’ve got a hijacking attempt.

… But there’s a catch.

AOL, for example, uses a proxy server for their packaged browser. This means everyone comes from the same IP address. Not cool. Now AOL users can simply go into their browser settings and kill the proxy config and they’ll surf using their own IP, but can you really ask users to do that for every little application we have using session variables?

Also AOL users won’t be the only ones behind a proxy server.

And if you have session timeouts set to days, dial-up users and any other user on a network with shared IP addresses will eventually get an IP address of a former user. And they might be able to get into the application that way.

So what can you do? Not much. You won’t ever be 100% certain in your security. It’s all about managing risk. In this case, you’re at a fairly low risk with hijacking if you’re comparing IP addresses.

But here’s what I do to take it 1 step further.

Combine the user’s IP address and browser string (cgi.http_user_agent) into a single string. Then MD5 hash the thing. Store that hash as a session variable. Recalculate and compare hashes as the first step in any user request (in other words: put this logic in your application.cfm file, and put it up at the top). And that should protect you well enough. The browser string provides a little extra security in the event of proxy users hitting the site.

Also keep your session timeouts to a low value (30minutes.. 2 hours MAX, unless security isn’t a big issue for your application).

When you detect a hijack attempt, you might not want to kill the session because the legit user also gets locked out. You can reset CFID and CFTOKEN on the user with the CFCOOKIE tag then redirect the user to the enterance page.

I do a lot of work with Cold Fusion. The other day I hear that Macromedia (who owns ColdFusion) has been bought out by Adobe.

So a friend of mine makes a comment about how one of ColdFusion’s new features is a lens flare tag that throws up a lens flare on a web page. Lens flare being one of the most (ab)used filters in Adobe Photoshop.

Well I think for a minute, and decide it’s absolutely doable, and set to work. I created a lens flare on a black background in Photoshop. I then used the color selection tool to select and remove the black color. This left me with a nice transparent png flare. Good enough for me, afterall this is just a quick goof, nothing I want to really waste time on.

I then create a quick custom tag in ColdFusion which creates a DIV and absolutely positions it on top of the page in the upper left-hand area via some inline CSS.

The PNG is placed inside the div block. I even threw in the filter line needed to get IE 6 working with transparent PNGs.

Silly stuff.

<!–
Here is the result. A fun little easter egg.
–>