1. ColdFusion Code Security Michael Smith President TeraTech, Inc ColdFusion, database & VB custom development and training. http://www.teratech.com 800-447-9120

2. Speaker Information Who am I? n Michael Smith n President of TeraTech, Inc Rockville MD u http://www.teratech.com/ http://www.teratech.com/ u ttWebReportServer, CFXGraphicserver n MDCFUG, CFUN-02, Fusebox Conf n Articles in CFDJ, Fusion Authority

3. 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

4. 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

5. 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.

6. 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 email error to admin n Don’t explain why attempt failed n Standard processing time

7. Error handling code In Application.cfm: <CFMAIL to="#error.MailTo#" from="info@teratech.com" subject="ColdFusion Error"> #error.RemoteAddress# #error.Template# #error.DateTime# #error.Diagnostics#

8. 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

9. 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

10. 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

11. 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

12. Javascript Validation n Available many places u Swipe from the source code generated by CFForm u http://builder.com/ 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

13. 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

14. 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

15. 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

16. 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.

17. 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.

18. Page Validation n URL and Form parameters used in SQL u SELECT * FROM EMP WHERE ID = #USERID# u Extra SQL commands on SQL Server http://myserver/page.cfm?ID_VAR=7%3BDELETE%20FRO 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

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

20. 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

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

22. 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.

23. 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.

24. 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.

25. 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.

26. Logins n Use Strong SSL where available u http://www.thawte.com/ 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

27. 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

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

29. 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

30. 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

31. 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

32. 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

33. 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. http://www.smart- objects.com/docs.cfm?f=cf_dump.htm

34. 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.

35. 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

36. 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

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

38. 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.

39. Hashing passwords SELECT PasswordHash FROM SecureData WHERE UserID=

40. 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

41. Resources n http://www.allaire.com/developer/s ecurityzone/ http://www.allaire.com/developer/s ecurityzone/ n http://www.macromedia.com/v1/de veloper/securityzone/ http://www.macromedia.com/v1/de veloper/securityzone/ n http://www.houseoffusion.com/ Security section http://www.houseoffusion.com/

42. 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!

43. Next Steps n Conduct a security audit u Download Michael Dinowitz’s http://www.houseoffusion.com/ MunchkinLAN to test your site for holes u Remove CFDOCS n Validate pages n Authenticate pages n TeraTech’s CF201 class n Questions? Email me at michael@teratech.com