ColdFusion Code Security Michael Smith President TeraTech, Inc ColdFusion, database & VB custom development and training

Speaker Information Who am I? n Michael Smith n President of TeraTech, Inc Rockville MD u u ttWebReportServer, CFXGraphicserver n MDCFUG, CFUN-02, Fusebox Conf n Articles in CFDJ, Fusion Authority

Introduction The ColdFusion security challenge: n Keeping hackers out n While still letting users and friendly apps in n Balance security vs easy of use

ColdFusion Security Here is what we will be covering: n Error handling n Form Validation n Page parameter validation n User Authentication n Members Only n Encryption and passwords

Not covered in this talk n Server security n Database security n Hardware security n Operating system security n TeraTech’s CF201 Class covers more security topics than we can cover in an hour.

Error handling n Always have an error handler in Application.cfm n Never display default CF errors - gives out SQL information and template paths n Instead error to admin n Don’t explain why attempt failed n Standard processing time

Error handling code In Application.cfm: <CFMAIL to="#error.MailTo#" subject="ColdFusion Error"> #error.RemoteAddress# #error.Template# #error.DateTime# #error.Diagnostics#

Form Validation n Why it is important n Underscore validation n CFFORM validation n Javascript validation n CF validation n SQL validation n Fake form submits

Why is validation important? n Malicious exploits are possible n Bad data may be entered n Server crashes n Hacker can force an error message

Underscore Validation n AKA Form-level validation n Easiest to implement n Runs on the server based on this hidden parameter from the form page n Trusts the browser that the form variable is passed n Effectively client-side, although actual validation occurs on the server

CFFORM Validation n Automagically generates form-level validation and javascript validation n Works well enough in simple forms n Does not adapt well for complex forms, need for complex validation, javascript, etc. n Generally roll-your-own is preferred n Still trusts browser

Javascript Validation n Available many places u Swipe from the source code generated by CFForm u n Totally browser dependent n With CF Form, won’t even submit if javascript not present n Effectively useless with 508 n BUT! Least server traffic

CF Validation n Occurring on the ACTION page, on the server side n Need not trust the browser n 508 compliant, browser independent n A little more complicated to write, but necessary on public sites

Authentication n Stateless web - any page can call another - this is good for open sites n Hacker pages call your page with false data n Use CGI. HTTP_REFERER to control who calls you n Use CGI. CF_TEMPLATE_PATH application.cfm control what is run. Warning - Can be spoofed by browser

Fake form submits n Hacker copies your HTML source to their machine, edits form fields and submits to your action page. n They can now edit your hidden fields or remove fields to generate error messages n Hidden form field token n Check HTTP_REFERER is in your domain

Fake URLs n Hacker edits your URL to get data they shouldn’t see or to force page error. n Protect URLs with checksum – eg hash() function.

Fake cookies n Cookies can be faked too – they are just in text file on client machine n Don’t assume cookie value is valid n For top security add checksum to cookie.

Page Validation n URL and Form parameters used in SQL u SELECT * FROM EMP WHERE ID = #USERID# u Extra SQL commands on SQL Server M%20MyCustomerTable u | VBA functions - shell() on Access u xp_cmdshell in SQL Server n Use VAL() on parameters or check for ‘ and | or use n Encrypt Variables n Checksum URLs

CFQUERYPARAM n Code example SELECT * FROM courses WHERE Course_ID= n Also runs faster SQL too – cached query plan.

Protect CFINCLUDE and CFMODULE files n Don’t let CFINCLUDE and CFMODULE files be run standalone – they may do bad things or generate error messages n Protect using a naming convention/ subdirectory and test in application.cfm of CGI.script_name n Especially important for Fusebox applications with many include files

Code to protect CFINCLUDE files n For Fusebox In Application.cfm: n Non-Fusebox – check filename/directory

Code Defensively n Assume bad things will happen and code for them n Always code the CFELSE and CFDEFAULTCASE n Check input parameters exist using CFPARAM, they are of correct type and are that they are in range. E.g.

Datasource password n Don’t put datasource userid and password in CF Admin – if any template is compromised hacker can destroy data n Don’t hardcode in every CFQUERY call n Use request variables in application.cfm and encrypt it n Or for super security set up user accounts in Oracle and have users enter userid/password when they logon.

Input massaging n Textarea field may be stored to database for redisplay n Bad users may enter JavaScript or CF functions into your text hoping you will use evaluate() on them. n Strip them out using a regular expression.

CFCONTENT n CFCONTENT can be misused to send back your source code – eg filename/path in URL n Store files it sends in directory outside of webroot.

Logins n Use Strong SSL where available u n Require at least 8 chr password n Consider requiring numbers in password n Consider forcing regular password changes depending on application n Strong form validation n Consider blocking accounts after multiple failed attempts

Authentication u Protected Header code In your application.cfm or header.cfm to be included in every page. Your protected links here Warning - spoofed IP numbers will get around this code

Members Only n Session, client and cookies n Refresh issues n Timeouts n Remember me

Session, client and cookies Client Management n Use short timeouts. (conflicts with 508) n Consider rolling your own security u Use CFID / CFToken from URL or create your own cookies u Store information in database with a table to keep track of ID/Token combinations against user Ids u Most flexible method

Session, client and cookies Client Management n If you use session management (as enabled with CFApplication) u Lock your usage u Limit session timeout, minutes not hours u Consider passing session vars into request vars at top and bottom of page

Session, client and cookies Client Management n Use client variables in place of session variables where you do not need to store complex values n Configure storage so that variables are stored in a DB, NOT the registry n Use WDDX if you have the occasional need for a complex variable n Don’t use too many cookies n Manually test for timeout less than 2 hours – client.last_access_datetime

Timeouts n Use as short a timeout as practical n Don’t want users annoyed n Do want to protect against trouble n Consider (also/instead) having cookies go away after browser closing u This is the default with cookies if you do not specify a time n If you create your own session management, you can do more

Session Tracking n Who is logged on now u Keep track of login times to see who’s logged in now, can record activity and determine based on last activity or logoff option n Variable and structure dump u Use CF_Dump or CF5 CFDump tags to output all session variables or all cookies, etc. objects.com/docs.cfm?f=cf_dump.htm

Session hang over n User logs in then closes browser without logging out. n Hacker uses browser and if the session has not timed out they are logged in as previous user n Use CFCOOKIE on CFID and CFTOKEN to set these session cookies to expire immediately on browser close.

Remember Me Sites with Login functions often have “Remember Me” option n Be careful - want to be clear what this option means n Use to set your own cookie n Store something other than username / password or a flag - consider some random values n Don’t turn option on by default

Members Only Summary n Session variables can still be used, with locks, but Client or Cookies are preferable n Use after insert/cfmail to avoid issues n Short timeouts for login - experiment n Remember Me is easy with Cookie

Back button hacking n Hacker uses back button to view sensitive information from a users browser n Consider disabling back button, especially on logout

Encryption n Encrypt source so even if downloaded can not be read n Be aware that decryption programs exist n Encrypt sensitive data such as credit card numbers in database using CF encrypt() and decrypt(). n Consider storing hash() of password instead of plain text.

Hashing passwords SELECT PasswordHash FROM SecureData WHERE UserID=

Refresh Issues If delete/insert/update pages are refreshed, or other action pages, problems occur – hacker sees error message. n Immediately after one of these actions to avoid this n Use the addtoken=“yes” parameter to keep any session changes across pages

Resources n ecurityzone/ ecurityzone/ n veloper/securityzone/ veloper/securityzone/ n Security section

What Security Means n Security is hard because a hacker only needs one window to be open to get in while the poor webmaster must work on closing dozens of holes. n Security is a way of thinking - how can they get in... n More knowledge is power - don’t keep security tips secret!

Next Steps n Conduct a security audit u Download Michael Dinowitz’s MunchkinLAN to test your site for holes u Remove CFDOCS n Validate pages n Authenticate pages n TeraTech’s CF201 class n Questions? me at