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.

Restrict access for anonymous users

If you are building a SharePoint website on the internet, you might be having the following architecture. 

You will probably have created a web application and configured it to run on Windows Authentication.Then you can extend the same web application from the Central Administration and the extended web application can run on Forms authentication over the internet.

Extending a web application will create a new site in the IIS by SharePoint and this site and the site created to run with Windows Authentication will be sharing the same content database.

For most content based web sites over the internet, Anonymous Authentication may be configured for the site.

But configuring anonymous access creates one significant problem in case of SharePoint sites. The areas of the site sometimes get exposed over the internet which you might want to keep under wraps.

There could be other scenarios where you might want your registered users to have more rights than Restricted Read. But at the same time you want to maintain a tight leash so that your website is less vulnerable even from users who have registered and logged in as they are external users and may not be a part of your organization. If they have malicious intentions, I guess it will be better to be prepared than to be sorry later.

Mostly you would like to restrict the following pages completely from external users who are access the site over the internet:

View All Items Page : /_layouts/viewlsts.aspx

The different views in lists and libraries : <Document Library Name>/Forms/Allitems.aspx etc.

There could be a host of other pages as well. But it will be crucial for the content managers/information workers to access this page from the intranet zone of the website.

The good news is there is a very simple way to solve this problem. One thing to keep in mind is all SharePoint sites are in reality ASP .Net sites. Hence you can modify the web.config file to do your bidding. In this case, what you can do is modify the web.config file for the extended web application running on the forms authentication or anonymous authentication on the internet. Modify the following section on the web.config file:

<!--Added for Access Control-->

    <location path="_layouts/mobile/mbllogin.aspx">

        <system.web>

            <authorization>

                <allow users="*" />

            </authorization>

        </system.web>

    </location>

    <location path="Pages/Forms">

        <system.web>

            <authorization>

                <deny users="?" />

                <deny users="*" />

            </authorization>

        </system.web>

    </location>

    <location path="Css/Forms">

        <system.web>

            <authorization>

                <deny users="?" />

                <deny users="*" />

            </authorization>

        </system.web>

    </location>

    <location path="PublishingImages/Forms">

        <system.web>

            <authorization>

                <deny users="?" />

                <deny users="*" />

            </authorization>

        </system.web>

    </location>

    <location path="Documents/Forms">

        <system.web>

            <authorization>

                <deny users="?" />

                <deny users="*" />

            </authorization>

        </system.web>

    </location>

    <location path="Lists">

        <system.web>

            <authorization>

                <deny users="?" />

                <deny users="*" />

            </authorization>

        </system.web>

    </location>

    <location path="_layouts/1033">

        <system.web>

            <authorization>

                <allow users="?" />

                <allow users="*" />

            </authorization>

        </system.web>

    </location>

    <location path="_layouts/<your custom directory>">

        <system.web>

            <authorization>

                <allow users="?" />

                <allow users="*" />

            </authorization>

        </system.web>

    </location>   

    <location path="_layouts/images">

        <system.web>

            <authorization>

                <allow users="*" />

            </authorization>

        </system.web>

    </location>

    <location path="_layouts">

        <system.web>

            <authorization>

                <deny users="?" />

                <deny users="*" />

            </authorization>

        </system.web>

    </location>

    <!--End for Access Control-->

 The good thing is you can do a lot of mix and match and allow access to certain areas for anonymous users and even registered users logging in and then completely restricting access to other areas. As you can see above this particular setting provides access to:

1. All files and folders under Pages library, style sheets library, images library, but denies access to the Forms folders hence the user cannot actually open various views in the document library and fiddle around.

2.You restrict access to all assets under _layouts directory, but open images under _layouts so that logos, banners icons etc. can be displayed. Similarly you can open 1033 directory and any custom directory that you might have deployed which can contain JavaScript files, resources etc.