Establish security settings in Web.config

In this post (which is the 100th one in the life of the blog), we’ll review three important security-related settings that you can define in your application’s web.config file, namely: authentication, authorization and impersonation. You’ll find a very thorough article about the topic here.

First a little terminology: authentication is the process of identifying, authorization is of checking rights. A common example: when you check-in to a plane, you show your ID, passport, etc. to identify yourself. Then you show your ticket for the given plane, to show that you are authorized to be there. It’s that simple. And impersonation is the process of taking someone else’s personality, which is a bad, bad thing. So long for terminology.

There are some a few authentication types in ASP.NET.  Windows authentication uses the Kerberos protocol (or NTLM) to identify itself. Let’s consider it using with and without impersonation. You’d use Windows authentication with impersonation when:
Continue reading “Establish security settings in Web.config”

Ensure that sensitive information in applications is protected

I really don’t know what to think about this one. Microsoft gives the following guidelines: hash and salt passwords, encrypting information. Now this topic is a bit broad, but let’s see it. If you don’t find my post detailed enough, feel free to refer this Patterns & practices article on MSDN.

Our first issue is the connection to a database. The main recommendation is: whenever it’s possible, use Windows Authentication. This has many benefits, including that you don’t need to store authentication information in your application, you don’t need to send this authentication info across the network, etc.

Continue reading “Ensure that sensitive information in applications is protected”

Identify Vulnerable Elements in Applications

In this section, I’d like to provide a guideline which helps you build a secure website in ASP.NET. The following list is from the Pro ASP.NET 3.5 in C# 2008 book, refer to it for further information.

Never trust user input: use strong validation method when you’re dealing with user input. Whenever possible, grant a white-list of values that are acceptable for the current input.

Never, never use string concatenation for creating SQL statements: really never do it. Use parameters instead, data source controls have natural support for them. In the lower level, every ADO.NET command class supports them either.

Never output user-entered data before validating and encoding it: this one’s barely need any explanation. If you do output that information, you expose your site to serious XSS attacks. To gain an idea about the seriousness of them, check out this video.

Never store sensitive or business logic data in hidden fields: your users aren’t dumb, they can open the source of your site, tamper with it, and send it back to you.

Never store sensitive data in the View State: View State is little more than another hidden field. If you assume that its encrypted, you are wrong. However, you can make sure that it’s the same what you’ve sent to the user by setting EnableViewStateMAC to true.

Enable SSL when using Forms Authentication: no comment, enable SSL if you can.

Protect your cookies: and don’t forget to set timeouts on them.

Decide which User-related Information to Store in a Profile

Before you start using profiles, you should know some limitations of the SqlProfileProvider shipped with ASP.NET. First of all, it can become a performance-bottleneck. Each time you query profile information for a user, the profile API retrieves all of the user profile information from the underlying database (a roundtrip to SQL Server). However, after that you are free to process the requested information as long as you don’t post back your page to the server. When you modify profile information, another roundtrip is taken to the server.

Given these facts, you should store relatively small amount of information in user profiles. Another problem is that this information is serialized as clear text (or binary data/XML) but in any way, it’s not encrypted. So you should never include sensitive data in user profiles. Good news that your custom classes (as long as they are serializable) can be stored in profiles. I’ve kept the worst to the last: all profile information is stored in two cells for each user. In the first, all the names of the properties, in the second, all their values. So it will be very hard to share profile information with a desktop application, for example.

Continue reading “Decide which User-related Information to Store in a Profile”