Making CAPTCHA easier on your users

I recently added Peter Farrell’s LylaCAPTCHA to a number of applications.  One repeated comment I got from people testing was that they were aggravated by their inability to get past it due to not being able to easily recognize whether characters were upper or lower case.   In fact for about the first week after I implemented it on this blog I didn’t receive a single comment, which I am going to squarely blame on that issue rather than my dull content. ;)

I decided that I would take the approach of making the CAPTCHA display show all capital letters, but allow the users to put in whatever case they wished.  Here was my approach to this.  In the config file, I made the setting:

<config name=”randStrType” value=”alphaUCase”/>

This tells CAPTCHA to both display and expect capital letters.   This would be fine, but to dumb it down a little more and allow them to type it in any case I added this to the CAPTCHA test:

pass = false;
if (Len(arguments.HashReference) AND Len(arguments.CaptchaInput) AND CaptchaService.validateCaptcha(arguments.HashReference
{ pass = true; }
return pass;

Quick and easy and most importantly… no more user complaining!

slick little multi-file upload tool

I recently had a need to allow users to upload multiple files at the same time.  I came across a cool little script that I used that allows users to append multiple files that works much in the vein of Gmail’s attachment utility using a single file input element.   It was a breeze to implement and was a big time saver over reinventing the wheel.

More on Cross Site Scripting (XSS)

I received some emails/IMs after my blog post this morning and was somewhat surprised to see how many people are still somewhat unaware of cross site scripting (XSS) vulnerabilites.   Rather than individually answer emails to  the various questions (read:  Dave is lazy today), I found a pretty nice FAQ about XSS with some examples of how it can be implemented.  This is about 3 years old, but has some good information. – The Cross Site Scripting (XSS) FAQ

Security Tip: Stop looking for bad characters/strings to block

For the past couple of years I have worked with a large financial industry application.  Considering the sensitive nature our customers’ data, we have quarterly vulnerability assessments performed against our applications by IBM (an eye opening experience if you have never done this before!), and we have occasional security training.

When it comes to the programming layer of web security concerns, we typically find two main types of security vulnerabilities that need focus, those being SQL Injection and Cross Site Scripting.  Although these attacks target different areas of your applications, addressing them and securing your applications is achieved through the same method, scrubbing your data!

One recommendation that has repeatedly come up is to shift  the typical programmer’s thinking of trying to block specific dangerous strings, and instead only allow safe characters.  Although on the surface this sounds like a matter of semantics, we have found this to be valuable advice.    For instance, many times you find that  cross site scripting attacks make use of the Javascript “<script>” tag, which you might find as <script>  or %3cscript%3e.  Early on in fighting this problem, we took the approach of just blocking <, >, %3c , and %3e since we knew that would be effective in blocking that type of attack.  Then without fail, on our next assessment we would discover that some new string that we weren’t accounting for was leaving us vulnerable.

By taking the approach of only allowing good characters, you are better positioning your applications to be safe from future attacks.   One method that we employ is to run a goodChars() method on every request, that loops through URL and FORM scopes and ensures that no one is sneaking in things that might be harmful.  Of course every application has different needs, and this script might need to be altered for other implementations, but the basic idea is seen here:

function goodChars(str)
str = REReplace(str, “[^A-Za-z0-9=_s-.##$&@]“, “”, “ALL”);
return str;

<cfset form.Test1 = “@##&.kws-j$dl927^” />
<cfset form.Test2 = “qsd%0d%0a_fs7=293(*^%5″”" />
<cfset url.Test3 = “asdf|<script>alert(‘HAHA! I am hacking you!’)</script>” />

<cfloop collection=”#form#” item=”i”>
<cfset form[i] = goodChars(form[i]) />

<cfloop collection=”#url#” item=”i”>
<cfset url[i] = goodChars(url[i]) />

<cfdump var=#form# />
<cfdump var=#url# />

When you dump the FORM and URL scopes you will see that our strings were modified like this:

form.Test1 —> @#&.kws-j$dl927
form.Test2 —> qsd0d0a_fs7=2935
url.Test3 —> asdfscriptalertHAHA I am hacking youscript

I should probably note that this is more of a “blunt force” approach to making sure that nothing dirty is getting through.  While this may be perfectly acceptable for some applications, you may want to consider taking a more granular approach and applying this to specific points in your application, or perhaps logging abnormalities to expose users that might be trying to breach your system.  Logging may also shed light on characters that your users need in normal use of the application and may need to be added to the “safe” list.

If you are not already taking steps toward scrubbing your data, hopefully a script like this might be a good starting point to getting the wheels turning on how to keep your data and your users safe.

The song tapper

I stumbled across an interesting site that I had to share…  The Song Tapper.  Using your spacebar, you can tap out songs and it will attempt to match them from 23,XXX-something songs in its database.  I am really surprised at how many it matched that I tapped in.  This definitely ranks up there in uselessness, but I think it is a pretty cool idea nonetheless.

Return the number of active sessions in your application

A few times recently I have seen people ask about calculating the number of active sessions in their application.  Thanks to the fact that ColdFusion sits so comfortably on top of Java, there is a simple way to achieve this.  Try the following code:

<cfset SessionTracker =
CreateObject(“java”,”coldfusion.runtime.SessionTracker”) />

Additionally, if you want to retrieve specific information about the sessions, you have probably guessed that you have a handle on that through the getSessionCollection() method.  To see how that is structured try the following:

<cfdump var=#SessionTracker.getSessionCollection(application.applicationname)#>