SQL Injection & CF code Attacks

[drforbin1970]

One thing I've noticed with sites using CF is that many, many programmers do not take into account SQL Injection and CF Form/URL variable attacks. I've seen SO many CF pages that blow up when the input varies in the slightest, displaying CF error messages, datasources, variable names, etc.

Seems not enough programmers use CFTRY/CFCATCH or even know about it. I've seen where SQL table names and datasources were being passed in a URL!! It's frightening

Interested in everyone's BEST PRACTICES to avoid these type of attacks.

I'll start it off with a few I use:

Use CFTRY / CFCATCH.

ALWAYS set the maxlength value on form input text boxes and make sure the value matches the corresponding column length in your DB. If you do not, someone can enter a huge amount of data in the field, causing your CF routine or DB to choke.

Scope all variables, URL, Form, etc.

Use numbers/integers whenever possible for URL variable values.

Avoid using varchar as the data type in your stored procedures for passed URL or Form variables. Use INT instead.

Validate user input using CF before passing to your SQL, etc. queries. Test for allowed/disallowed characters, blanks, length of input value, etc.

Use stored procedures whenever possible.

Don't make URL or Form variable names too descriptive. ex. ?m=100 is better than ?memberID=100

[paross1]

If you are really worried about SQL injection, then make sure that you ALWAYS use <CFQUERYPARAM> tags in your queries that use URL or FORM variables as parameters, etc.

Phil

[Dan_Bracuk]

First read this: http://www.adobe.com/devnet/security/security_zone/asb99-04.html

A little while back I was testing the vulnerability of our own systems by attempting to inject sql into various dbs. I tested oracle, ms sql and redbrick numeric and char fields. The only time I was able to do successfully inject sql was with ms sql numeric fields. Everything else either crashed or stored the sql into the field. I didn't test date fields because we always ensure we have valid dates before we reach our cfquery tag.

Phil mentioned cfqueryparam. It's a good practice to use that anyway, if you can, because it speeds up your queries. I'm not sure what would happen what would happen if you used it with a numeric field that had text in the value, probably the big grey box.

[CRidgway]

In addition to the things listed above, you should never expect the values sent from any form submission to be 100% as they are coded. There are tons of programs out there that can be used to intercept and alter the submitted data before it hits your server. It is a slow process, but we are locking down any and all form variables not just type="text" and textarea's.

If a user has the ability to alter submitted data, they can change the values for all types of form fields (hidden, radio, checkbox, select, button, etc...). A lot of our old code did not take that into consideration and simply allowed the value entered from a "predefind" (hard coded value) form type (radio, checkbox, etc...) directly into the database without a check.

Another step is to turn off "Enable Robust Exception Information" in the CF Administrator. This step will help in not giving an attacker the complete SQL statement being used in your code. Note: This is a recomended practice for all production CF servers as it is, but it never hurts to say it. CFTRY/CFCATCH blocks work as well to hid that info, but neither way will prevent an attack.

You also can not rely on client side JavaScript for validation.

CR

[Guest]

And when you convert to CFQUERYPARAMs, remember that you cannot use cachedwithin and cachedafter attributes of the CFQUERY tag.