Heres just a quick list of tips I tell people
1. Dont use embedded queries, use stored procedures, avoid sp_executesql
2. Remove all < > -- ' / \ from input strings. You will need to write a loop that filters multibyte sequences after single byte sequences and loops until no more can be found. Because for ex.
hello-/-john
if you remove the / you are left with hello--john, and thats a problem.
3. Refilter ALL input, including querystring. If you provide a link www.somesite.com/products.aspx?id=906B
Assume someone is messing around with the url and trying things like
www.somesite.com/products.aspx?id='--
to test for sql injection attacks.
4. Make sure your login pages are https. I know - seems like a given, however many sites actually have login pages that are not https, but post to https pages, hence the data is still secure.
However, the 'lay user' doesn't see the little 'secure' lock in their browser and don't think it is secure. Believe it or not I've heard quite a few complaints from users trying to access sites in that manner.
5. Encrypt all query string information - I should be posting some code shortly for this.
6. Configure error pages for all of your applications (in turn make sure your <customErrors> section in web.config is set to RemoteOnly so remote users wont get asp.net error messages.
Catch errors in global.asax application_onerror and log your errors at least to a file. If you log to the event log, remember to give asp.net permissions to the eventlog registry key
http://support.microsoft.com/default.aspx?scid=kb;en-us;329291 (I believe if you give aspnet (2000,xp)/network service (2003) permissions to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application
you should be ok. Log to a file first, since that is the method most likely to work. If you log to a db and that fails, your code needs to continue logging, hence easiest to log to a file first. TEST THIS for every application you deploy.