CodFusion

Do you recognize this?

5F4DCC3B5AA765D61D8327DEB882CF99

It is the MD5 hash for 'password'. Even if you hash important data in your database like passwords does not mean someone else can't recognize it, even by sight. Most hackers or security specialists will recognize this hash and many others without a problem as if they were stored in cleared text.

Many know that you can't directly decrypt a hashed string. That is true, but that does not mean it is secure.

For example, let us say that we have a hashed string where we want to find the original value. We suspect the original string was alphanumeric without any special characters and that it was 6 characters in length or less*. We can create a database table and then roll through all the possible strings going from 1 to 6 characters and store the string and its hashed version. Then it is just a simple SQL call to match the hash with one in the database and then pull the string that generated it. Hash dictionaries can even be downloaded off the Internet, saving the time of having to generate one. So even with this strong encryption pattern, we are not safe.

Now we have some things to consider here. Hashing is not enough, but we can 'salt' the hash. We take the original string and add a random 'salt' of characters to it, and then we hash the combined string. Salting the hash will buy us more time. A hacker can't use a brute-force attack against the hash within an acceptable timeframe with a proper salt. But remember Moore's law and realize that processing power is always growing. Make sure your salt is indeed random and in a good length (like 32 bits) to make it effective.

Wikipedia has a good explanation salts at..
http://en.wikipedia.org/wiki/Salt_(cryptography)

So remember, "salted hash".

To further illustrate the setup of this, imagine a situation where we have a database table of username and passwords. With a random salted hash pattern, we actually would have three critical columns in our table: username, password (hashed), and the random salt. If we need to verify the user's password, we take the password string and combine it with the random salt from that row and then execute the hash function. Then we see if that hashed value matches the one in the table. If it does, all is good and we log the user into the application.

By the way, if you have a password reminder function in your application, a hash will make the functionality of it unless. If someone needs a password reset, do some proper proof of identity and generate a random password and send it to them. When they login, force them to make a new password which you naturally hash with a random salt and store.

* Determining the patterns are fairly simple. Most passwords are simple one word or date patterns 6 characters or less. Social security numbers are 11 integers long with the dashes. It's 9 without. You get the idea.

I will be presenting on BlazeDS tomorrow at 6:30 EST at the Online Flex Meetup Group 

The meetings are held over Adobe Connect sessions so you only need a computer with speakers and an Internet connection to attend. We will be recording the presentations and posting the recording on Charlie Arehart's UGTV. If you've been wondering what BlazeDS is and how you can use it, I would encourage you to attend. I also recently wrote an article for the Fusion Quarterly about BlazeDS and you can currently view it at labs.fusionlink.com

"It was the best of times, it was the worst of times..."

So this latest Cast()/ASCII attack has now got many people's attention. The fix for it is very simple: do some basic data validation and make certain to parameterize variables before sending to a database. CFQueryParam has been around since ColdFuson 4.5 (that's roughly 10 years now). Why are people still not using it? My CFC based filter, Portcullis , can also provide protection against this latest xss attack, but I would like to address a bigger issue with this.

Some will make the necessary changes others will not and life goes on. The bigger point I would like to make is that this is only two attack vectors: sql injection and XSS. There are many more that I see people simply ignore or do nothing about. If the cast/ascii hack scared you a bit, that fear is really a good thing, because there is a lot more to consider with your applications.

Here are just a few of the bigger attacks that a web application should take into account:
-SQL Injection, injection sql code
-Cross-site scripting (XSS), injecting javascript and/or other code that executes on the victims browser.
-Cross-site request forgery (CSRF), similar to XSS but intended to authorize single operation attacks.
-Insecure urls, accessible webservices, cfcs, cfml pages that don't check for authorization, etc.
-Weak SSL Ciphers, allowing a 40bit cipher when 256bit should be the only one used. By default, the vulnerability is allowed with IIS servers.

Using CFQueryParam is not going to fix all of this and neither will CFStoredProc. Sorry, but security is work. There are no short cuts. Here is a small list of things to think about if you really want to start getting ahead of these things.

- Develop data validation rules for your application that will carefully look over the data before sending to a database. val() and cfqueryparam() are simply not enough.
- Are you validating files you upload to the server? I really shouldn't have to explain why do I :)
- Log the activity, it's not enough to block or attempt to block the attacks. You should log and actively monitor things.
- Check your session management, are you passing cfid and cftokens in your urls? Someone can easily steal a session with this information.
- Consider using SSL more, for example many login forms I see are not protected with a basic SSL cert
- Does the entire world really need to have access to your admin login screen? Try to restrict access to critical areas as much as possible. Limit login attempts, etc. Does a user in Vietname really need to be able to make 10,000 login attempts to your admin area without anything to block them?
- Check your CFCs, are you allowing outside remoting calls to them? Is your Flash remoting configuration in ColdFusion, BlazeDS or LCDS allowing access to public methods in your CFCs? You can also restrict remoting access to just a few CFCs instead of allowing any CFC to be called. For example, the "<source>*</source>" in your configuration is defaulted to access any CFC on your server. Why not limit that down a bit.
- Make certain your compiled Flash and Flex files aren't the debug versions. In flex, do a build export to make a true production version of your swf. Otherwise, you'll expose a lot of information to a hacker.
- Limit the permissions of your datasources, if it simply read/writes information, you don't need to give the login full database owner (DBO) level permissions to also alter or create tables.
- Limit the permissions of the ColdFusion server, the default install has full local system rights. Create a coldfusion user that has just enough rights to run the server. I explain how to do this here.

This, of course, is just a start. Security is NOT a one time event. It's a continuous process that we as system administrators, managers, and developers all have to do to everyday.

Note:
The original quote from above is from a Tale of Two Cities by Charles Dickens. Though not his best effort, it certainly has some good lines. The rest of the passage could probably apply easily to our own time.

"It was the best of times, it was the worst of times; it was the age of wisdom, it was the age of foolishness; it was the epoch of belief, it was the epoch of incredulity; it was the season of Light, it was the season of Darkness; it was the spring of hope, it was the winter of despair; we had everything before us, we had nothing before us; we were all going directly to Heaven, we were all going the other way."