Protecting your CFML apps with CFTHROTTLE

You may have heard about the recent high profile attacks on celebrity accounts on Twitter, where by a young (enterprising?) chap simply pointed a brute force password dictionary attack to their login process. Twitter had no throttling process here to stop this from happening.

How can you protect your own CFML applications from such an easy attack?

BlueDragon introduced the CFTHROTTLE tag a number of years ago and naturally is available now in the core distribution of OpenBD. CFTHROTTLE was designed to stop repeated requests coming from a single source consuming too many resources. Developed for Blog-City.com and modelled on the (at the time) well known Apache mod_throttle module.

There was short comings with the Apache module, that made it pretty inflexible. That is why the CFTHROTTLE was designed from the ground up for the flexibility demanded from the CFML developer. Its power is in its simplicity.

The key with CFTHROTTLE is that it helps you determine if a request should be throttled or not. It does nothing with the request in of itself, thats left to you to decide. That was something the Apache module had problems with.

Let us look at a real example of it in action. Let us assume we want to limit a given IP address from making no more than 50 requests in a 10 second window we would use the following:

<cfthrottle token="#cgi.REMOTE_ADDR#" hitthreshold="50" hittimeperiod="10000">
 
<cfif CFTHROTTLE.throttle>
  <cfheader statuscode="503" statustext="Try backing off the time between requests">
  <cfheader name="Retry-After" value="180">
  <h1>503 Server very busy - back off and try again</h1>
  <cfexit method="request">
</cfif>

Here we make the decision to return back the 503 HTTP status code, and abort any further processing of the page. So you would be wanting to throttle as soon as possible before any resources was consumed. Application.cfm/.cfc being your ideal candidate for this tag.

Now, as you probably will appreciate, throttling on IP address alone would be very problematic, especially for visitors coming from large ISP's that would share a common IP address. For example, everyone from say AOL would look like the same person to your throttle!

That is the why the token field is left up to you to decide what works best for your application. At Blog-City for example the token takes on different guises dependent upon the request. We limit the likes of search bots from crawling too fast, as we want to humans to have a fast experience, and robots to have a slow experience. We can control this through CFTHROTTLE.

That is why the CFTHROTTLE is a powerful mechanism in your defence against dictionary and volume attacks. You decide the criteria to throttle on, and then you decide what to do with them.

As the recent Twitter attack illustrated, it is usually the simplest of things that let people in, and after your site has been compromised, public faith and trust has been lost. Take control and get in charge of your security.