My jam-packed session at DevDays – Defenses and Countermeasures – shows a huge amount of solutions of things you can do to try to keep the hackers out. It was frustrating not to be able to get into the details of all of the great information that was in there due to the time limitation.

I think it would be interesting to look at all of those lessons in tiers.

The first tier would be basic, easy to remember, somewhat easy to implement solutions like:

• never use sa as the account to access your database
• use integrated security to access your database when you can, however if you *must* use uid & pwd your db access strings, hide them. THere are a number of ways including: use the configuration applicaton block which has this ability built via a wrapper to DPAPI OR encrypt the string yourself before putting it in your web.config file (in .net 1.x you will need to build your own little dpapi library to help you do this as well as to decrypt) OR encrypt to string and stuff it into the registry
• check query strings in URLs to make sure they don’t include possible sql injection strings – this is pretty easy to just do in the page load
• use stored procedures FIRST, paramaterized queries as a 2nd option and concantenated queries never
• validate data entry to limit possiblity of characters that are used for sql injection or cross-site scripting attacks
• never use the system account for your web application
• htmlencode all output back to the browser

Even with this top tier list, there are two audiences. The first audience only needs the list and either know how to accomplish these things or knows how to find them. That audience just wants a check list, then you can also talk about a LOT more things. THe other audience would need this list to be the entire one hour presentation so you can really dig into each thing – how to do the encryption, looking at the difference between the effect of a query string with a sql injection attack and a stored procedure with the same attempted sql injection attack, experiment with the variety of other ways to prevent nasty input.

I will be thinkig about all of this a lot until the next DevDays  (in Boston) where I will presenting this session again.

I am getting some great feedback in my last two security related posts from people who have been thinking about, working with and dealing with asp.net security a lot longer than I have.

DEFINITELY read the comments by Steve Smith and Sam Gentile in my last post.

And don’t miss the comments by Anil John and Andrew Duthie in my post on  the RequestValidation feature in ASPNET 1.1.

There is no ONE solution to security. Threats are coming at you from many many angles. You have to protect yourself in many many ways and then you still won’t be done.

One of the points that is made in the Defenses and Countermeasures session that I am doing for DevDays is that what we are doing with all of these steps is not assuming that we are eliminating all security problems, but instead, we are continuously raising the bar for potential hackers. Making it harder and harder for them to do their deeds.