Evaluate special programming constructs

May include but is not limited to: dynamic vs. prepared SQL (CREATE PROCEDURE… WITH EXECUTE AS) procedure, protecting against SQL injection

It won’t be so surprising, but I tell you that SQL Server has some great optimization features. One of these is that it caches query plans. A query plan is a compiled form of what the database engine should do. It stores cached plans in a normalized form, and performs hash lookups when it meets with the same hash to skip compiling the given query, and use an existing execution plan. Marvelous.

Sometimes you need quite a lot of flexibility – let’s say you are dealing with optimal parameters. Optimal parameters tend to result in different query execution plans, thus slower performance. This is the time when dynamic SQL comes into place.

Design an application strategy to support security

May include but is not limited to: application roles, schema ownership, execution context, Windows vs. SQL authentication, permissions and database roles

Let’s start with the boring definitions: authentication is the act of identifying yourself, while authorization is that one when you gain access to resources, based on your identity.

SQL Server allows two types of authentication methods: Windows authentication allows you to connect SQL Server with an existing Windows account , while SQL Server authentication allows connections from anywhere – as long as you set it up this way (which is a bad idea). You should use Windows Authentication, because this way you make your life easier (don’t have to store passwords in config files to connect), but if it isn’t possible, SQL Server authentication is the way to go.

Now how to build up your authentication model – there’s an easy way to go – connect with a fixed application credential. This way you can control what the app can do in the database server. However, sometimes you need more granularity – let’s say you are interested in who did what. If you connect with a single application credential, you’ll won’t get user-detailed information. Then you should use built-in user accounts.

Establish an error-handling strategy

Dealing with errors is an important part of every application. Web applications aren’t an exception, in the contrary, they should be even better in graceful error handling, because of their huge amount of users.

We have three possible locations of caching errors in an ASP.NET application. The first one is the source of the error itself, by wrapping our code, which is likely to fail, in a try-catch block. This is a very good solution for the problem, since the error gets treated on the spot of its occurrence. You can decide to bubble the error forth, and catch it in the Page_Error event, or even further, in the Application_Error event, defined in global.asax. There’s a fourth opportunity, but it isn’t the best solution: define custom error pages in the customErrors section of your web.config. They are part of the apologize, not the solution for the problem, so you should restrict the use of them. Even worse, when you are on a custom error page, you have no way to get and deal with the error lead you there.

Before writing error-handling code, make sure that you do everything to prevent errors from happening. The best way to do so is to use a massive amount of validation. String.Empty and the Exists method should be very close friends of you.

But if the worse happened, you should fail elegantly, and without showing any inner workings of your application. Hold the detailed error messages to server administrators, and give user-friendly and meaningless errors to the everyday users. Also, you should log the exception (Health monitoring comes handy for this task).

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.

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.

Control Code Privileges

A quick refresher about the security policies of the .NET Framework:

1. Security Policy Levels
2. A Hierarchy of Code Groups
3. Named Permission Sets associated with Code Groups
4. Evidences of an assembly
5. Application Domain hosts that provide evidences to the CLR

Don’t worry if you can’t recall all of these, check out the MSDN link at the bottom, called Security Policy Management. This post will be about the namespace System.Secuirty.Policy. This namespace contains code groups, membership conditions and evidences. The previous three types are used to create the rules applied by the CLR. Evidence classes are the inputs of security policies, and the membership conditions are switches of it. The policy levels and code groups are the structure of a policy hierarchy. Code groups are the encapsulation of a rule and are members of the policy level.

Improve the Security of a .NET Framework Application with CAS

The .NET Framework introduces a new layer of security, called Code Access Security. This layer lives on top of the OS security, and lets you control what a given assembly can and can’t do, just like the OS lets you define the rights of a user or group.

Before we dive into the details, there’s something (which may seem obvious at first, but is a particularly good thing to remember on the exam): whatever permissions you grant to a code, it will never have more rights than the user who runs it (just recall ASP.NET and IIS).

In the previous post, I wrote about permissions. The first important layer of CAS is the control of them. There are default permission sets, defining what an assembly can do. They are as follows:

FullTrust	Exempts an assembly from CAS checks.
SkipVerification	Enables an assembly to bypass permission checks.
Execution	Enables an assembly to solely run.
Nothing	No permissions granted. Not even enough to run the given assembly.
LocalIntranet	The main restriction is that the assembly is not allowed to tamper with the file system, only through file dialogs.
Internet	A restrictive permission set, but safe.
Everything	Grants all permissions, but still checks the assembly.

 

Control Permissions for Resources

The classes related to controlling permissions and access for resources are live in the System.Security.Permissions namespace. There are a whole lot of permission classes for imperative security access settings, and each of them has its declarative attribute counterpart. There are three major categories of them:

• Code access permissions
• Identity permissions
• Role-based permissions

Code access permissions represents access to a given resource or the ability to perform a specific operation. For example, FileDialogPermission and RegistryPermission are classes which fall into the category of code access permission.

Implement a Custom Authentication Scheme

Now this one is short will be short and will have nothing to do with the title. I’ve found four enumerations in the System.Security.Authentication namespace. The most important of these is the SslProtocols enumeration. It has five possible values. You should know that the Ssl values (Ssl2 and Ssl3) are provided only for backward-compatibility and they are all superseded by the Tsl protocol. The fifth value is None, and it speaks for itself. Here’s a repeat for a better layout of this blog:

• SSlProtocols enumeration:
  • Default (Ssl3 or Tsl will be used)
  • None
  • SSl2
  • Ssl3
  • Tsl

I forgot to mention that this enumeration controls which SSL protocol should be used for a given SslStream. Just in case if someone didn’t figure it out.