SQL Injection & CF code Attacks

Question

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

Answer 1

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