Someone recently posted about a Fusebox "vulnerability" which is making the rounds in some security circles. The full thread can be read here. But to save you some time (the thread is long), the issue is really that someone realized that you can perform a cross-site scripting (XSS) attack on a Fusebox site by passing some script tags into the fuseaction URL value. Note that this only works in cases where the error handler outputs the code, and where no other XSS prevention measures are in place.

Now protecting against XSS is something that all developers should already be doing as good practice. Heck, in ColdFusion 7, stopping this takes one line of code: enabling scriptProtect in Application.cfc or the cfapplication tag. Which begs the question, should Fusebox (or any framework for that matter) be responsible for filtering out things like this? Even if it was added to the framework, it should probably be disabled by default because if someone is already using scriptProtect you don't want that logic running twice. And that means that if the user has to turn it on they already know about the problem. And if they already know about the problem then couldn't they just enable scriptProtect or use one of the custom tags out there that do this? It's kind of a vicious circle. I'm interested to hear what folks think about this as it applies to Fusebox (or Mach-II or Model-Glue or onTap, for that matter).

Comments Comments (9) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 4495 Views

Comments

  • # Posted By Raymond Camden | 8/12/05 6:34 AM

    I definitely think it should be done outside the framework. It is like any other protection (ie, my url.id val must be a uuid, or must be numeric above 0, etc).

  • # Posted By Steve Ray | 8/12/05 6:50 AM

    agreed.

  • # Posted By Christian Ready | 8/12/05 7:01 AM

    I agree that it should be done outside the framework as well. Having said that, is it just as simple as adding the following code to my application.cfm (this is an FB 4.1 app):

    <cfapplication name="myapp" scriptprotect="all">

    I ask this because I tried the following XSS on my site:

    http://mdcap.org/new/index.cfm?fuseaction=calendar...(document.cookie)</script><

    And it still returns an alert box.

    Chris

  • # Posted By Brian | 8/12/05 7:58 AM

    Christian, are you running CFMX 7? ScriptProtect in new in 7, and when I tested it, it did prevent the script from executing by replacing all the script tags with escaped characters.

  • # Posted By Christian Ready | 8/12/05 8:09 AM

    Hi Brian,

    Yes, I am using CFMX 7. I will play with it, though, as I think it may have unhinged something in my CMS application. Still, it's cool that there' an otherwise simple way to do this.

    Chris

  • # Posted By Sean Corfield | 8/13/05 6:42 PM

    Outside the framework.

    Otherwise the framework takes on the job of server security and that places the framework in an uncomfortable (and high-risk) position, especially since security issues tends to escalate and evolve independently of any framework.

  • # Posted By quiksilv | 11/1/05 5:17 AM

    i think Pete Freitag makes some good comments about script portect here: http://www.petefreitag.com/item/362.cfm

    Though i would mention it.

  • # Posted By Joe FitzGerald | 11/10/06 5:42 PM

    Definitely outside the framework, although it sure would be nice for people to start posting "plug-ins" for the major frameworks to do these types of common tasks. I guess I need to get busy!

    FYI, while ScriptProtect is a great start, it won't stop all XSS attacks.

  • # Posted By ike | 1/12/08 6:04 AM

    I totally missed this when you posted it a couple years ago... heh... I'm kind of value-neutral on the subject. I tend to feel that features like this one (and this goes for most of the features in my framework even), while not entirely out of place within a framework, should be designed in such a fashion that the developer can disable them if not giving them more granular control to configure them. I would definitely agree that the framework shouldn't force a particular breed of XSS protection on the developer and make them hack or slog through the framework code and modify it in unexpected ways to disable it. But I'd have no qualms about a configurable feature.

    p.s. you've probably already seen it, but the onTap framework is on riaforge now :)