Top 20 measures to secure your ASP.Net Web Application

Inspired by this man's one of the wittiest blog posts and his endless obsession with lists, here is my list of top twenty TO-DO's to secure your ASP.Net applications and sites over the internet:

1. Use SSL when transmitting account information, passwords, user identities over the wire. If you develop things such as a user log in page, registration page or edit profile page etc. keep in mind that people out there would be ready to sniff your traffic for identity information and steal it. SSL is one of the better ways to protect to secure the communication channel and prevent your users' identities from being stolen.

**How to set up SSL?

2. Encrypt your connectionstrings.

3. Encrypt your configurationsettings under appsettings in the web.config file.

4. Use CAPTCHA validation for anonymous users when they enter data. Great way to stop many types of DOS(Denial of Service) Attacks from happening.

5. Respect thy Firewall. Do not host applications in servers which can be accessed from the internet without connecting through a secure communication channel.

6. Use ASP .Net membership, role managers etc and make sure that sections of your application which should stay protected from undesired access, stays so.

7. Encrypt your SQL databases.

8. Fight the holy war against XSS (Cross Site Scripting). Here is the arsenal.

9. Use impersonation and delegations properly.

10. Encrypt your cookies.

11.Encrypt your Query strings.

12. If you are storing any sensitive information in the view states using hidden-fields, then encrypt them as well. Use my favorite AES Encryption.

13. If you want to create an extremely secure application, for example a web application which contains company budgets, legal and M&A data, data for the board of directors and what not, you can create a dual mode of authentication(on top of using SSL). E.g. you can configure the application to run on standard Windows authentication with membership and role management happening through Active Directory or some other profile store. Additionally you can have your own custom authentication module developed as a custom HTTP module. The module will have function which will trigger every time a request is made to the server. It will check for an encrypted Cookie that you will create and store in the user's browser for the session in question. If the cookie is not found, redirect the user to a custom log-in page. In the log-in page the user must enter a different set of user IDs and password which must be matched against your custom database. When a match will be found, create the cookie and redirect the user to the URL requested earlier.

14. Use client certificates for secure web service calls.

15. Avoid creating persistent cookies as much as possible.

16. A brief note on password policies. Please remember, a password policy for strong passwords is helpful for the users to create a password which meets your standards for a strong password. At the same time, it is also helpful for hackers to design a much more intelligent brute force dictionary attack. (I like using the password strength indicator provided by Ajax Control Toolkit to help users determine their password strengths without giving away too much on my password policy )

17.Use validation controls to make sure that the user data entries are not messed up. This means that you should(read must) stop end users from entering text in the field which asks them enter their phone numbers. 
18. Kerberos is difficult than NTLM, but there is a bigger pay-off.
19.Use impersonations and delegations properly.
20. Work on exception handling and errors must be handled. Test, test and test to make sure the end user cannot crash your system unintentionally(or intentionally for that matter) and you have taken measures that your code exits such scenarios gracefully.


For the complete list and more detailed white papers, you can visit this link.

Please understand that the above list will not make your web-site impenetrable. Theoretically all computer systems and networks can be cracked given sufficient time and resources. The motive of a malicious user will not always be about stealing data from you. The motive could be as simple as disrupting the service you provide. The combination of the above steps will decrease the probability of your system getting cracked or disrupted and the pay-off for trying to do so lesser and lesser for the hacker/cracker taking a shot at it.
The topic also does not speak of anything about network security etc.(An area which requires a great deal of detailed expertise, which unfortunately I do not possess) and deals with the aspects related to ASP .Net web site security only. 
The key thing is, if your data can be stolen, probably it will be stolen. If your systems can be cracked, probably they will be cracked! So it is better to be proactive than reactive.