4

So I'm currently using CF11 and CFWheels 1.1, the "Global Script Protection"(GSP) server feature does an awful job of covering the XSS bases. I would like to extend it to block any and all tags/vectors for JS from being inserted into the database.

CF11 offers antiSamy protection via the getSafeHTML() function which applies a xml policy file specified in application.cfc but I would still need to modify every single varchar cfqueryparam in the application to use it right?

Is there a way to get CF11 to enable the antisamy features server or application wide in a similar way that the GSP feature works? What I mean by this is GSP automatically strips tags out of input submitted to the app without having to modify all the queries/form actions. I'd like a way to apply the antisamy policy file or getSafeHTML() in the same way.

Thanks!

gnarbarian
  • 2,622
  • 2
  • 19
  • 25
  • 2
    When outputting anything, I tend to use one of these functions, depending on what I'm outputting: `h()` (CFWheels alias for `HtmlEditFormat()`), `NumberFormat()`, `DateFormat()`. I realize this doesn't solve the garbage-in-garbage-out problem, but you should be taking care in your view templates to escape HTML (except when you want to output HTML, of course). – Chris Peters Sep 25 '14 at 13:42
  • Perhaps another possibility from this answer - http://stackoverflow.com/a/26060722/1636917 - There is a UDF on CFlib.org [isXss](http://www.cflib.org/index.cfm?event=page.udfbyid&udfid=2116) that checks a value to determine if it is xss. – Miguel-F Sep 26 '14 at 15:20

3 Answers3

8

Why would you have to apply it to every one? You would only need to do it for string (varchar) inputs and only when inserting. And even then, you wouldn't use it everywhere. For example, if you ask for my name and bio, there is no reason why you would want html, even "good" html, in my name. So I'm sure you already use something there to escape all html or simply remove it all. Only for a field like bio would you use getSafeHTML.

Validation is work. You (typically) don't want a "all at once" solution imo. Just bite the bullet and do it.

If you did want to do it, you can use onRequestStart to automatically process all keys in the form and url scope. This is written by memory so it may have typos, but here is an example:

function onRequestStart(string req) {
    for(var key in form) { form[key] = getSafeHTML(form[key]); }
    for(var key in url) { url[key] = getSafeHTML(url[key]); }
}
Raymond Camden
  • 10,661
  • 3
  • 34
  • 68
  • There are literally thousands of varchar inputs in the app. I really don't want to do it on each field. And we are not actually escaping html at all. The point is this app is huge and it's not the only app I'm going to have to lock down to prevent XSS. The organization I'm doing this for has dozens of apps like this as well. Going to every varchar input field in the organization and applying a new validation rule isn't feasible. – gnarbarian Sep 25 '14 at 17:19
  • 1
    You aren't escaping html? So for all these thousands of fields you DO want html? That seems unlikely. But - in theory - you can treat the FORM and URL scope as a structure, loop over each field, and run getSafeHTML on every field. You could do this in onRequestStart. I do not recommend doing it. I recommend doing the hard work. But - that would automate it for you. – Raymond Camden Sep 25 '14 at 20:30
  • In one of our apps Yes we do want HTML because it involves some CMS features. In this specific app no HTML/tags should be going into the db, yet at the moment we are not protected against tags going into the DB. The onRequestStart option sounds pretty good to me. Loop over the form vars and then loop over the URL params applying getSafeHTML as I go. It's either that or implement it as a wheels plugin and just do one loop over the param struct, but that won't be as portable to our other apps. – gnarbarian Sep 25 '14 at 20:33
  • P.S. Edit your answer to include the onRequestStart suggestion and I will upvote it / mark it as a solution if you provide a small example. – gnarbarian Sep 25 '14 at 20:38
  • Thanks again. I just realized who you are. Really appreciate your input on this! – gnarbarian Sep 25 '14 at 22:14
  • added a check to exclude JSON from being scrubbed because it was messing with the jqgrid filters. Think that will open me up to any vulnerabilities? if(not IsJSON(url[key])){url[key] = getSafeHTML(url[key]);} – gnarbarian Oct 01 '14 at 20:01
2

I agree with Ray, validation is work, and it is very important work. If you could have a server wide setting it would be way to generalized to fit all situations. When you do your own validation for specific fields you can really narrow down the attack surface. For example, assume you have a form with three fields; name, credit card number, social security number. With one server wide setting it would need to be general enough to allow all three types of input. With your own validation you can be very specific for each field and only allow a certain set of characters; name - only allows alpha characters and space, credit card number - only allows digits, space, dash and must conform to the mod rule, social security number - only allows digits and dash in 3-2-4 format. Nothing else is allowed.

That being said, I just wanted to point out that the "Global Script Protection" rules can be customized. That setting works by applying a regular expression that is defined in the cf_root/lib/neo-security.xml file in the server configuration, or the cf_root/WEB-INF/cfusion/lib/neo-security.xml file in the JEE configuration to the variable value. You can customize the patterns that ColdFusion replaces by modifying the regular expression in the CrossSiteScriptPatterns variable.

The default regular expression is defined as:

<var name='CrossSiteScriptPatterns'>
    <struct type='coldfusion.server.ConfigMap'>
        <var name='&lt;\s*(object|embed|script|applet|meta)'>
            <string>&lt;InvalidTag</string>
        </var>
    </struct>
</var>

Which means, by default, the Global Script Protection mechanism is only looking for strings containing <object or <embed or <script or <applet or <meta and replacing them with <InvalidTag. You can enhance that regular expression to look for more cases if you want.

See Protecting variables from cross-site scripting attacks section on this page

Miguel-F
  • 13,450
  • 6
  • 38
  • 63
  • Thanks for the tip about neo-security.xml This is going to have to work. This app has literally thousands of varchar input fields and this isn't the only app I'm going to have to lock down. – gnarbarian Sep 25 '14 at 17:28
0

The solution as implemented for a cfwheels 1.1 app:

I used the slashdot file from https://code.google.com/p/owaspantisamy/downloads/list

This goes in application.cfc:

<cfcomponent output="false">
    <cfset this.security.antisamypolicy="antisamy-slashdot-1.4.4.xml">      
    <cfinclude template="wheels/functions.cfm">     
</cfcomponent>

This goes in the /ProjectRoot/events/onrequeststart.cfm file

    function xssProtection(){
var CFversion = ListToArray(SERVER.ColdFusion.productversion);
if(CFversion[1]GTE 11){
    for(var key in form) {
        if(not IsJSON(form[key])){
            form[key] = getSafeHTML(form[key]);
        }
    }
    for(var key in url) {
        if(not IsJSON(url[key])){
            url[key] = getSafeHTML(url[key]);
        }
    }
}

} xssProtection();

gnarbarian
  • 2,622
  • 2
  • 19
  • 25