Here are the OWASP Top 10 for 2007 and how they relate to ColdFusion development.

10. Failure to Restrict URL Access

Many people will protect sensitive functionality by just hiding the display of links or URLs. But this is not enough. You can obviously access those URLs directly. So we need to actually restrict access to those URLs, either programmatically or with server security.

• Create an access control matrix during application design. Design a map to every URL and function.
• Don’t assume users are unaware of ‘hidden’ URLs. Spidering and other technology can make you page suddenly pop up on Google! Oops.
• Don’t just secure the presentation layer. Don’t rely on just HTML or JavaScript. The model should have security as well. Server-side should also be checking that it should do what it is being asked.
• Block access to file types your application should never serve. Eliminates possibility of stuff you might not even know about. Lock it down in IIS or Apache.

9. Insecure Communications

Apps frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

• Use SSL for all connections that are authenticated. Think about it. Even the session tokens should be protected, otherwise we’re open to session hijacking. This requires SSL.
• Secure internal infrastructure connections need to be secured also.
  • Talking to the database. Think about what you’re writing to the database and is it secure?
  • <cfftp> will be secure in CF8 with SFTP support.

8. Insecure Storage

Web apps rarely use cryptographic functions when storing data.

• Protect sensitive data. Passwords, credit cards, SSNs. Ask yourself if you really need this info. If not, don’t take the burden to store it securely.
• When you do need it, use encryption before sending it, including to the database.
• Hash() in ColdFusion. Creates a “fingerprint” or a unique identifier for an original string, but it is impossible to convert the hash back to the original source string. Nice because it doesn’t require a key.
• If you need to read it back, Encrypt() and Decrypt(). Requires a secret key to encrypt and get it back. So the key has to be somewhere were your app can read it, so be sure to protect that key. Off the webroot and in a secure manner.

Starting with CFMX7, can install Java Cryptology Extension (JCE) security providers. Ships with CFMX_COMPAT, AES, Blowfish, DES, DESEDE. CF8 includes RSA BSAFE Crypto J Library, which is FIPS 140 compliant (nice for govt apps).

7. Broken Authentication and Session Management

Some apps may have poor security and authentication processes, which make hacking easier.

• Passwords. Require a certain level of complexity. Limit the number of invalid login attempts. Store the password as a hash rather than plaintext or encrypted. Don’t send passwords via email! Send them a link that goes to a page where they can change their password within a certain time period, and the link expires within a certain time.
• UI feedback. Tell the user the last time they logged in, it may alert them to an invalid login by a hacker.
• Log login attempts. If there are a certain number of invalid attempts in a short period of time, lock them out.
• Authenticate via SSL, transmit session IDs over SSL. Don’t pass IDs over the URL. Use J2EE sessions if you can.

6. Information Leakage & Improper Error Handling

Web apps frequently generate error conditions during normal operation. That’s fine. An error message should include meaningful messages for the user; error message may include diagnostic info for the site maintainer, but it is better to have this information stored to a database or emailed to the administrator or developer; error message should not include info that an attacker could use.

So robust exception handling shouldn’t be on, debugging shouldn’t be on.  Those are for your development or QA servers. Use the site-wide error handler and <cferror> or onError for app-wide error handlers. Hide the ColdFusion Administrator; any ColdFusion person knows what the address should be, and that will give them insight into what version of CF you’re using.

5. Cross Site Request Forgery

A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable web app, which then forces the victim’s browser to perform hostile actions to the benefit of the hacker.  The typically leverage XSS vulnerabilities.

• Protect against Cross Site Scripting (XSS).
• When processing sensitive data, only use POST. Not impossible to get around this, but much harder.
• If they’re doing something very sensitive, ask the user to reauthenticate. This will shut down a CSRF attack.
• Create a randomized token for each page/form. If the receiving page doesn’t get the token it expects, it will reauthenticate or just not process its actions.

4. Insecure Direct Object Reference

Don’t make it really clear when you’re doing just via a URL or form parameter. For instance, /getfile.cfm?file=c:myfile.txt makes it very clear what the code is doing. An attacker sees this and will try to get ANY file. Could get your CF files!

• Avoid exposing so directly what you are referencing.
• Validate the references.
• Pass credentials, ask every step along the way if they can do this, right through into the model.

3. Malicious File Execution

Allowing attackers to include hostile code and data. Anywhere where you may expose a file that will be included or executed, an attacker could change that file to execute a different file. Particularly dangerous in conjunction with forms that allow uploading of files.

2. Injection Flaws

Allowing hackers to relay malicious code. Typically comes in the form of SQL Injection, especially via URL parameters.

• Set up a sandbox for the app. Limits how the hacker can exploit the app to get to any system-level stuff, or anything else external to the app.
• Limit access to <cfexecute>, <cfregistry>, etc. Depending on your app functions, maybe even stuff like <cffile>.
• Carefully validate data receiving in before using it in database calls. <cfqueryparam>. Especially now that it can be used in cached queries in CF8.
• Limit database permissions. Use an account with the lightest permissions necessary. You can limit the datasource functions (SELECT/UPDATE/INSERT/DELETE/EXEC/etc) and the RDBMS user’s access permissions.

1.  Cross Site Scripting (XSS)

Attacker uses a web app to send malicious code in the form of a script, to a different end user who will then execute it.

Stored and reflective attacks. Reflective is the type when scripts may send sensitive data to another server that will save the info for use. Or will send spam to someone with your info.

Samy from MySpace in Oct 2005 amassed 1 million friends. Everyone who visited his page added him to their friends, but then their profile was affected also, so then everyone viewing an infected person’s profile also added him as a friend. GodOfTheNoose did a similar thing in Dec 2005, but did it with Flash, so he exploited the <embed> tag.

• Enable global script protection in ColdFusion Administrator, or at least in <cfapplication> or application.cfc. Not fire-proof, but a good start.
• Encode user-supplied output with a UDF like HTMLTrans() (available at cflib.org).
• Install web server filters like URL Scan (IIS).

Newest stuff in last few years: CSRF, insecure communications, malicious file execution. Stuff that has dropped in importance in last few years: Unvalidated inputs, buffer overflows, denial of service. So a lot of the insecurities in the past were browser application level stuff out of our control. So the impetus is now on web app developers to improve their code.

Unvalidated inputs was #1 in 2004. Consider some of our validation techniques: Using input masks, validation onBlur, onSubmit, or on server side. In CF, use the isValid() function. Supports many common types and can make validation a lot easier.  Remember, validate from your model all the way up to your view.