Shaun Mccran

My digital playground

08
A
P
R
2009

Cross-Site 'ScriptProtect' functionality in CF 7+

Until recently I was using a variety of method to stop cross-site scripting attacks, including htmlEditFormat() and a few regular expressions in my frameworks to strip out unwanted characters in returning variables.

I wasn't even aware that there was a 'scriptProtect' setting in ColdFusion until I bumped into it whilst writing a new login CFC recently, so I thought I'd take a closer look.

The first, and most 'global' option is in Cf Admin. If you go to the 'settings' screen there is an option, 'Enable global script protection'. This will enable the option for all sites running on that server. Obviously a bit heavy handed, but I'm not seeing a down side to this at the moment.

Secondly you can set this value in your Application code.

For Application.cfc

view plain print about
1<cfscript>
2    this.name = "applicationName";
3    this.scriptProtext = "all";
4
</cfscript>

Or for Application.cfm

view plain print about
1<cfapplication name="applicationName" scriptprotect="all">

The values for the scriptProtect variable are:

  • all
  • cgi
  • cookie
  • form
  • form,url
  • form,url,cookie
  • none
  • url

Most of these are obvious really. You can set a delimited list of the scopes you want to protect, or specify 'all' or 'none' for more global covering.

So what actually happens with this option enabled? It essentially replaces certain tags, such as script, object, applet, embed, with the text "InvalidTag". (Functionality I've noticed in BlogCFC as a side note.)

So it translates something like:

view plain print about
1<s cript>alert('Hello world');</script>

Into:

view plain print about
1<InvalidTag>alert('Hello world');</script>

There doesn't appear to be any conflict between setting the value in CF Admin, and your Application scopes, so I'd probably do both, it can't hurt.

06
A
P
R
2009

Cross Site scripting hack test form

One of the more basic cross site scripting hacks is where the user simply 'injects' other web templates into yours, using a form.

By submitting a string through a form and allowing it to return the value in an unencoded format a user can inject malicious code. In this example we will create a frameset, and set the source as a different domain than the originating site.

To test this yourself create a simply form, and set the value of the text field to the value that the user enters.

view plain print about
1<cfparam name="form.formValue" default="">
2
3<form method="post">
4
5<input type="text" name="formValue" size="30" value="<cfoutput>#form.formValue#</cfoutput>">
6<input type="submit" name="Action" value="Send">
7
8</form>

I'm using ColdFusion, but the language itself doesn't matter, the vulnerability is the same. Next submit the form using a string like the one below. This string is built up of the form field name, and a valid html frameset, surrounded by escape characters.

view plain print about
1formValue=>"></title></iframe></script></form></td></tr><br><iFraMe src=http://www.google.com width=900 height=1100></IfRamE>

Submit the form, and you will be returned to the same template, but it has translated the html string, and is now proudly displaying someone else's site on your domain.

This is only possible because the form is returning the form value in raw html. You can eliminate this issue by simply adding a html stripping routine to the form. Something like HTMLCodeFormat replaces special characters in a string with their HTML-escaped equivalents.

view plain print about
1#HTMLCodeFormat(form.formValue)#

_UNKNOWNTRANSLATION_