One of our applications had an entry in the ColdFusion exception logs today:
ScriptProtect error replacing insecure tag in scope CGI;
Essentially someone (via an automated process) was trying to find a weakness in our application by trying URL’s like:
http://www.mysite.com/?mode=>'><script>alert(40891)</script>
Luckily we use scriptprotect (among many other defensive techniques) to prevent this type of thing from causing any damage. But I just thought I’d throw out a quick reminder to EVERYONE using CF7+ (or Railo) to make sure and use the scriptprotect attribute of either the cfapplication tag or Application.cfc
It is simple to do (set once and forget) and helps protect you against XSS attacks and as it’s easier to implement than cfqueryparam there really isn’t any excuse to get caught with your pants down by not using it!
6 Comments
Michael, Yes! I love script protect and absolutely everyone should have it enabled unless they have something else in place for such protection.
I’ve seen some arguments against Script Protect concerning performance and its filtering. Performance is going to be an issue with any real-time solution. That’s not unique to Script Protect.
As for the filtering issues, if you don’t mind me making a plug, I have a post on enhancing script simply and easily. You can add new filters or modify existing filters to be a little less restrictive.
http://tinyurl.com/6zpnk5
@Jason – plug away! I’ve read a few of your posts on security, great stuff. It’s frightening how many unsecured apps are out there (not just ColdFusion ones of course).
I think a lot of developers either just don’t think of it, think it’s too much effort to deal with (which is course it isn’t) or they think “this will never happen to me”.
All of which isn’t good the day it happens
And it doesn’t help when developers don’t have the support of either their administrators or worse…their immediate reports (project managers etc)
Did you know you have two dead links in your main nav? About and Flex Builder aren’t clickable in Safari 3.2
@Joe – ah damn, thanks for that. This is a new-ish theme, I’ll have to take a look. Thanks for letting me know.
The issue with this is that it can conflict with cases where you _do_ want code. For example, on a blog. There isn’t really an easy way to say, ‘block the crap from the public but let me do it.’ Because of this I don’t typically use scriptprotect myself but rather clean the input manually when entered.
@Ray – agreed that is a tricky one. I guess if you know what you’re doing you can leave it off and make the necessary precautions. But it’s very dangerous as it seems easier to forget to protect something like a new form or page which has URL vars etc. I think shared hosting companies *have* to leave this option on.
Maybe in a blog type situation I’d have a standard that you need to surround your “code” with some kind of tag, could be a <code> tag or something like <div class=”code”> then use a JS function to replace all angle brackets within that tag with HTML entities before submitting to the server. Even users who comment on your blog need to know this system.
I guess this way you get the benefit of peace of mind with the flexibility of allowing “code” at the expense of a little extra work up front. I also think this is a case where you needn’t worry about those who have JavaScript turned off. If they do, the scriptprotect will catch them.