CF, XSS & SQLi – Keeping Your Users Safe

I’ve recently been thinking a lot (more) about web security, specifically XSS (Cross Site Scripting) and SQLi (SQL injection). Coldfusion is one of, if not the easiest, web scripting language to code securely. Straight out of the box, it’s harder to run an SQLi attack against than most. (please… I said harder, not impossible)

here’s a pretty good discussion about this with several of the top CF “experts” at EE

Bottom line for a CF coder is that using cfqueryparam will eliminate your SQLi risk. It’s an Adobe recommended best practice

Adobe recommends that you use the cfqueryparam tag within every cfquery tag, to help secure your databases from unauthorized users. For more information, see Security Bulletin ASB99-04, “Multiple SQL Statements in Dynamic Queries,” in the Security Zone,, and “Accessing and Retrieving Data” in the ColdFusion Developer’s Guide.

From LiveDocs

and you’re crazy not to use it.

You may actually see a performance boost using it as well.

If the DBMS doesn’t have to parse, analyze, and validate as much text, it’ll be able to respond to requests quicker and more efficiently

Faster and Safer Queries Using The cfqueryparam tag

However, just because you use cfqueryparam don’t get smug. You still may be vulnerable to exploits. XSS is harder to deal with and while CF does have some built in protection you can enable, it doesn’t protect you in all cases.

In CF8 (and maybe CF7..I can’t remember) CFadmin has a Server Settings > Settings > Enable Global Script Protection.

This is to “Specify whether to protect Form, URL, CGI, and Cookie scope variables from cross-site scripting attacks”. Sounds great. Check that box and your done. Safe and sound? Not so much.

Submit the following form with Global Script Protection (GSP) disabled. You should see an alert box which means you’re hax0red. Enable GSP and you won’t get the alert and you’re safe. However, while GSP is good for protecting against js hacks like alert(‘Gotcha?’) it -won’t- do anything to protect you against an iFrame attack. I’ve simulated one here using a visible iFrame, an actual iFrame used in an attack would be hidden. You’ll notice that the injected iFrame shows up whether GSP is enabled or not. This is because an iFrame is not actually a “script” so it’s not filtered. To fix this we need to strip html tags from input (which you should never allow to be submitted in any case) by using reReplaceNoCase and the regex <[^>]*>

As you can see, this eliminates the iFrame issue. This also defeats the JS inject issue as well even without GSP enabled.

 <cfif structkeyexists(form, "f1")>
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 Did you see the JS Alert???<br>
 <cfif structkeyexists(form, "f2")>
 <cfset myvar = rereplacenocase(form.f2,"<[^>]*>", "", "All")>
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 <cfif structkeyexists(form, "f3")>
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 I'm an injected iframe<br>
 That's bad ;(
 <cfif structkeyexists(form, "f4")>
 <cfset myvar = rereplacenocase(form.f4,"<[^>]*>", "", "All")>
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 No iframe here
 <div style="margin:50px;padding:35px;border:1px solid;width:350px;">
 <h2>XSS Demo</h2><br>
 <form name="1" method="post" action="index.cfm">
 <input type="text" name="f1" value="<script>alert('Gotcha?')</script>"><br>
 <input type="text" name="f2" value="<script>alert('I am harmless')</script>"><br>
 <input type="text" name="f3" value="<iframe></iframe>"><br>
 <input type="text" name="f4" value=""><br>
 <input type="submit">

I’ve got a couple of free tools to recommend as well.

SQL Injection Blocker v.3
by Mary Jo Sminkey

This is a “blacklist” tag which looks at common CGI variables and checks them for common SQLi keywords like insert|delete|select|update etc and for other nasty bits which don’t belong in form submits. You just cfinclude it in application.cfm or cfc and it should head off most attacks. Note:this is -not- meant as a replacement for everything I’ve outlined above. It’s an added layer.

I figure it’s a good idea to find out if a site is under attack ASAP so I customized blocker.cfm by adding a log variable to each cgi variable section
log =url;
log =form;

and then output the log as well as a cgi.remote_addr (attacker IP) in a cfmail which gets sent to me via SMS when blocker intercepts a hack attempt. This gives me the time, remote ip and details of the hack.

Another set of tools I just came across and really like are the ExploitMe plugins for firefox from Security Compass They do SQLi, XSS and Access Control Checking

You can also use HP Lab’s scrawlr for SQLi

If you have already been hacked with a SQLi attack you can use scrubbr from to help sanitize your db.

Take Out? Always use cfqueryparam, always use rereplacenocase to remove html and test, test, test.