New Security Features in ASP.NET 2.0

Here is a list of new security features in ASP.NET 2.0:

• Significant security advantages on Web sites that use forms authentication
• Membership services that manage a database of user accounts
• A role manager for managing role membership for users
• A provider model that gives you complete control over the implementation of the Membership and Role services and cookieless forms authentication
• The interactive configuration file editor that's built right into the IIS management console
• The new Web Site Administration Tool to create new users and roles, and to control access to pages in a Web application.
• The new Login controls
• The new Membership API
• Hashed passwords

Read Stephen Walther's article New Security Features in ASP.NET 2.0 and Keith Brown's article Security: Security Headaches? Take ASP.NET 2.0! in more detail about new features. Also Read Rob Howard's column "'Nothin' But ASP.NET" about the provider model in greater detail.

ViewState in ASP.NET 2.0

There is one other important place where view state is used, and that is in controls that issue server-side change events. If the user changes the value in a textbox or switches the selected element in a dropdown list, you can register an event handler and have code execute when the event is raised. If you disable view state on a control whose change notification event you are handling, it won't fire correctly since it must always assume that the previous value was the same as the default value in the form.

View state issues

There are many issues with view state in ASP.NET 1.x. It is on by default, and unless you know to look for it and disable it when it is not needed, it can significantly increase the amount of data rendered by your page. This becomes particularly painful when you use data-bound controls, all of which use view state to save their state across postbacks.

If you want to use features like sorting, paging, or editing in the DataGrid, you cannot disable its view state.

View state must encode not only the data but also the type of data (metadata); also, base64 encoding generally adds about 33 percent space overhead.

The primary rule to follow when optimizing view state usage on your site: if you populate the contents of a control every time a page is requested, it is generally safe (and wise) to disable view state for that control.

On the other hand, you may decide to take advantage of the fact that view state is going to retain the state of your controls and only populate control contents on the initial GET requests to a page (just falling through on subsequent POST requests).

View State Improvements in ASP.NET 2.0

• The serialization format for view state will be changed. This will dramatically decrease the size of view state.
• Microsoft will partition the view state into two separate and distinct categories: view state and control state. Control state is another type of hidden state reserved exclusively for controls to maintain their core behavioral functionality, whereas view state only contains state to maintain the control's contents (UI). Control state is stored in the same hidden field as view state (being just another leaf node at the end of the view state hierarchy).

You can find all the contents of this post from Fritz Onion's article: Speed Up Your Site with the Improved View State in ASP.NET 2.0. Read it in more detail.

ViewState in ASP.NET 1.x

ViewState is the mechanism ASP.NET uses to keep track of server control state values that don't otherwise post back as part of the HTTP form.

Read Susan Warren's excellent article Taking a Bite Out of ASP.NET ViewState in more detail about ViewState. I list facts about ViewState related to security:

• ViewState is merely base64-encoded
• ASP.NET to append a hashcode to the ViewState field if the EnableViewStateMAC is enabled
• By default, ASP.NET generates the ViewState hashcode using the SHA1 algorithm. You can select the MD5 algorithm by setting in the machine.config file
• Encryption First, set EnableViewStatMAC="true". Then, set the machineKey validation type to 3DES.
• ViewState Security on a Web Farm By default, ASP.NET creates a random validation key and stores it in each server's Local Security Authority (LSA). In order to validate a ViewState field created on another server, the validationKey for both servers must be set to the same value. The validation key is a string of 20 to 64 random, cryptographically-strong bytes, represented as 40 to 128 hexadecimal characters. A 128-character key is recommended for machines that support it.

When MAC checking is enabled, the serialized view state is appended a hash value that results from some server-side values and the view state user key, if any. Assuming a hacker has the skills to crack and rebuild the view state, he/she needs to know server-stored values to come up with a valid hash. Specifically, the hacker needs to know the machine key referenced in the machineKey entry of machine.config. So the view state is not at risk of tampering.

By default, the machineKey entry is autogenerated and physically stored in the Windows Local Security Authority (LSA). Only in case of Web farms—when the view state's machine keys must be the same on all machines—should you specify it as clear text in the machine.config file.

With the discussion above, ViewStateUserKey makes it much harder for hackers to use the content of the client-side view state to prepare malicious posts against the site.

Reviewing State Management in ASP.NET

I plan to take a look at the security enhencements of the state management in ASP.NET 2.0. Let me first review the state management in ASP.NET 1.x.

ASP.NET supports the following techniques for storing state info at the client side:

• Query strings
• Cookies
• Hidden fields
• View state

Query strings:

• Require no postback operation
• Most browsers limit the length of data that can be included in a query string
• No security
• No option for persistence
• No support for storing structured values
• Access query strings using HttpRequest.QueryString[''KeyName"]

Cookies:

• State can be persisted on user's machine
• Require no postback
• Some users disable cookies in their browsers
• Size restriction by browser (approx. 4 KB - 8 KB)
• No support for storing structured values
• No security
• HttpRequest.Cookies and HttpResponse.Cookies

Hidden fields:

• Can be used for pages that post to themself or to other pages
• Increases HTML size
• No support for storing structured values
• No option for persistence
• No security

View state:

• Support for structure values
• Easy configuration options for security
• Increases HTML size
• Works only when a page posts back to itself
• No option for persistence
• ASP.NET retrieves values for postback controls from the HTTP request while values for nonpostback controls from the hidden field _VIEWSTATE
• Page.ViewState
• You can disable the view state using the EnableViewState property at the level of a control, a page, an app, and the machine
• EnableViewStateMac is enable by default

ASP.NET supports server-side state management at two levels:

• Session state
• Application state

Session state:

• Page.Session
• Passing SessionID is with nonpersistent cookies by default

Application state:

• The application state is stored in memory
• Page.Application
• Modify the contents of the application state using a pair of Applicatin.Lock() and Application.Unlock()

Notes were taken from the book MCAD Developing and Implementing Web Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET Exam Cram 2 (Exam Cram 70-315)by Amit Kalani and Priti Kalani.

The one-click attack and ViewStateUserKey

A one-click attack consists in posting a malicious HTTP form to a known, vulnerable Web site. It is called "one-click" because it usually begins with an unaware victim clicking on an alluring link received through e-mail or found when navigating a crowded forum. By following the link, the user inadvertently triggers a remote process that ends up submitting the malicious form to a site. To be successful, a one-click attack requires certain background conditions:

• The first prerequisite is a social pretext that will lure the victim into clicking a hyperlink.
• The attacker also needs a Web site to host the page that launches the attack - but not always.
• A would-be attacker needs sufficient knowledge of the target application to construct request data, which the application will accept. Generally, this means that the attacker needs to know the URL of the vulnerable page, the name of every form field and query string parameter in the page, and what sort of value is expected for each of them.
• The site must be using cookies (better if persistent cookies) to implement single sign-on, and the attacker should have received a valid authentication cookie.
• Certain users of the site are involved in sensitive transactions.
• The attacker must have access to the target page.

The attacker is limited as to what parts of the victim's request he can control using this technique. The query string parameters and form fields are completely within the attacker's control, but cookies are out of reach. Some of the request headers, such as User-Agent, are also out of the attacker's reach, but others, such as Server and Referer, can be controlled to varying degrees. The only hint that the victim did not intend to submit the request is in the Referer field.

The industrial-strength solution to the problem of one-click attacks is to somehow prevent the attacker from being able to assemble request data that the server will accept. This is done by requiring a field in the request to contain an element of data that the attacker can't supply.

ViewStateUserKey is a string property of the System.Web.UI.Page class. The property helps you prevent one-click attacks by providing additional input to create the hash value that defends the view state against tampering. In other words, ViewStateUserKey makes it much harder for hackers to use the content of the client-side view state to prepare malicious posts against the site.

Read Eric Rachner's article One-click Attack in more detail. Also read Dino Esposito's article Take Advantage of ASP.NET Built-in Features to Fend Off Web Attacks on the most common types of Web attacks.

XML Signatures and Encryption

The .NET Framework 1.x supports the XML Signatures. The .NET Framework 2.0 adds an object model for XML encryption and X.509 certificate integration.

XML encryption is performed using the new EncryptedXml class and The new X509CertificateEx class and related classes make it easier to manipulate and use certificates.

Read the article Exchange Data More Securely with XML Signatures and Encryption
by Mike Downen and Shawn Farkas in more details.

Thread.CurrentCulture and Thread.CurrentUICulture

When a thread is started, its UI culture is initially determined by using GetUserDefaultUILanguage from the Windows API. This API gets the user UI language.

When a thread is started, its culture is initially determined by using GetUserDefaultLCID from the Windows API. This API gets the default user locale.

Let us take an example. Assume that CurrentCulture is fr-FR and CurrentUICulture is en-US and now is February 15, 2005. The following code:

string str += DateTime.Now.ToString();
str += Environment.NewLine;
str += DateTime.Now.ToString( Thread.CurrentThread.CurrentUICulture);
str += Environment.NewLine;
str += DateTime.Now.ToString( Thread.CurrentThread.CurrentCulture);

will generate the following string:

15/02/2005 12:42:44
2/15/2005 12:42:44 PM
15/02/2005 12:42:44

So the default ToString method takes Thread.CurrentThread.CurrentCulture.

It's easy to change the CurrentCulture and CurrentUICulture of a thread. The following is an example.

Thread.CurrentThread.CurrentCulture = new CultureInfo( "fr-FR" );

If you modify the CurrentCulture or CurrentUICulture property of a thread, its child threads don't inherent the modification. Remember that, when a thread is started, its UI culture and culture are initially determined by using GetUserDefaultUILanguage and GetUserDefaultLCID.

In a common case, you might want that all your threads use one culture (for example, InvariantCulture) other than default. You should set the culture manually when you create a new thread. You should also set the culture manually before you do things on a thread pool thread.

CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture

The CultureInfo.CurrentUICulture property is a per-thread setting that returns the current user interface culture. This property is used by the ResourceManager class to look up culture-specific resources at run time. By default, it corresponds to the user UI language.

The user UI language determines the default language of menus and dialog boxes, messages, INF files, and help files. This setting controls the language in which the UI is presented. It is only present if you have the MUI version of Windows (which is to say that you have Windows with the multilanguage files installed).

This setting is found on the second tab of the Windows XP/Server 2003 Regional and Language Options dialog and in the middle of the first tab of the Windows 2000 Regional Options dialog. The setting is per-user and changing it requires a logoff to take effect.

The CultureInfo.CurrentCulture property is a per-thread setting that determines the default formats for dates, times, currency, and numbers, the sorting order of text, string comparisons, and casing. The CurrentCulture property is not a language setting. It contains only data related to the standard settings for a geographical region. Therefore, the CurrentCulture property can only be set to a specific culture or to the InvariantCulture. By default, it corresponds to the default user locale.

The list of locales can be thought of as a big group of defaults that are grouped by many language/region pairings, which you can see in the first tab Regional and Language Options Control Panel applet. Several of the settings are customizable, particularly the various formats. The setting is per-user and when you change the setting, it is effective immediately.

The contents of this post are from SDK and a post from Michael Kaplan.

Globalization Features in Whidbey

Michael Kaplan gave a talk on Globalization Features in Whidbey last night at a group meeting of .NET Developers Association. The following are highlights:

• Customized Cultures
• Handling of the new standard LDML format for persisting custom cutltures to XML
• Updating to the Encoding class to support custom fallback
• Improved platform-independent support of encodings that improve performance tremendously
• Support for all official forms of Unicode normalization
• Updated methods/properties/classes for dealing with supplementary characters/text elements
• Special techniques for Yukon-specific CultureInfo objects

I like the feature of supportting for new "Windows only" cultures in the .NET framework based on new locales supported by Windows. This feature is warpped in CultureTypes.WindowsOnly, previously called CultureTypes.InstalledWin32Cultures in Beta 1.

You can find more on Globalization in Michache's blogs.

Emergent Design

According to Alan Shalloway, design can emerge from refactoring, thinking in patterns, and commonality/variability analysis. The reason why different design appraches can produce the same design is that all these approaches adherence the same "Good Code Qualities" principles. They are:

• Strong cohesion
• Loose coupling
• No redundancy
• Encapsulation
• Testability
• Readability
• Focus

Read more detail from Alan's slides.