Securing ASP.NET Applications

Work Services Company Contact Articles
Get our articles in your inbox and be the first to try out our betas: email address Submit
Securing ASP.NET Applications
Gil Shabat Wednesday, April 8, 2009 2 Comments
There is no glamour in building secure ASP.NET web applications. The vast majority of developers I’ve met would much rather focus on building new & flashy features that can impress their managers and end-users. Even though security can usually take a backseat during the initial stages of development, it usually comes back to bite you when it’s least expected. This article covers some of the security aspects to be aware of when developing a new web application and what to do throughout the development process to protect applications and databases against common attacks.

Back to Reality
Building web applications with ASP.NET has been getting easier as the technology and the development environment, Visual Studio, become more sophisticated. Many of the complexities are taken care of by the framework and are out of view from developers. This allows us to focus more on the business value and features of our web applications and less on technical aspects that very few really understand or appreciate. As a result, many developers believe that security is also taken care of for them and they need not to worry about it.

Unfortunately the reality is quite different. Unless developers make security one of their priorities early on in the development cycle, project managers might end up with a great application but one that cannot go live without compromising the safety of their end-users and their data.

Attacks Are Easier Than You Might Think
It might be surprising to many project & product managers that exploiting web applications does not necessarily require expert knowledge. Attacks are often perpetrated by hobbyists with very simple means. Here are two recent examples.

Attack I: SQL injection at Telegraph results in 700,000 emails stolen
The Attack - On March 6th, 2009, a hacker used blind SQL injection to penetrate to the web site of The Telegraph, a leading English daily paper. Based on reports, he or she was able to gain access to about 700,000 email addresses on the site’s database. Telegraph’s response can be found on their blog.

Some Background – SQL statements are generally used to retrieve, update and delete data against a web application’s database. This is normally done behind the scenes and the results are displayed to a user based on their authority level. This means that the data is protected and access is granted on a selective basis.

Attack Explanation - Many web applications provide some form of search capabilities where users can provide their own filtering on the data the application might display. For example, a filter to see only the records posted in 2009. If the application is not secure, a hacker can potentially exploit this functionality. Rather than supplying a value to filter upon, he might provide another SQL statement that is then injected in to the SQL statement that the application uses to retrieve data.

Attack Example – Let’s assume a user only has access to the records of his department and to filter through the records, he enters some criteria. He wants to see the latest records, so he enters 2009 in the year range.

The application might attempt to execute the following statement against the database: SELECT * FROM … WHERE … AND Year = 2009

A hacker on the other hand, might try to trick the application and enter the following into that same year range field: 2009 OR 1=1

The application, if not careful, might then execute the following statement against the database: SELECT * FROM … WHERE … AND Year = 2009 OR 1=1

This would potentially provide the user with access to all the records in the system, even the ones to which they shouldn’t.

Attack II: Authentication Security Holes at Sage
The Attack – Sage, a leading provider of accounting software in the UK, was about to launch Sage Live, a small business accounting product as SaaS (software as a service). However according to ZDnet, Sage Live went dead after serious security flaws were exposed in the product. The flaws were exposed by the founder of a tiny rival. Duane Jackson, CEO of UK-based KashFlow, described what she found on her blog: “A little bit of prodding around the site and I found myself looking at… pages that only authorized people should be seeing.”

Attack Explanation - Users navigate to and though web applications by going from one URL address to another, much like postal addresses point to residential homes and businesses. As a result, users can easily change the URL and its parameters that can potentially lead to pages and information that they wouldn’t ordinarily be allowed to view.

Common ASP.NET Security Flaws
There is a wide array of attacks that ASP.NET web applications need to protect against but most security holes are due to flaws in the following:

- Authentication

Making it easy for attackers to reveal users credentials, or worse to circumvent the application’s authentication altogether.

Possible deficiencies: lack of password policy (strong passwords, expiration date etc), passing internal messages back to the browser, using dynamic SQL on the login page (SQL injection), using cookies and other insecure means to store users’ credentials, and passing user names and passwords in clear text .

Possible attacks: network eavesdropping, brute force & dictionary attacks, SQL injection (on login page), Cookie replay attacks and credential theft.


- Authorization

Allowing logged-in users to perform actions without authorization verification (i.e. vertical & horizontal privilege escalation.)

Possible deficiencies: inconsistent checks for user authorization for every user’s request and web page, lack of data validation and trusting data submitted by users (i.e. cookies, hidden fields, URL parameters, etc.)

Possible attacks: privilege escalation attacks (horizontal and vertical), disclosure of confidential data and Data tampering attacks.

- Data Validation

Trusting data submitted by the user and acting upon it.

Possible deficiencies: lack of consistent and strict data validation throughout the web, and failing to encode data sent to the browser.

Common Attacks: cross-site scripting (XSS), SQL injection, data tampering (query string, form fields, cookies, and HTTP headers), embedded malicious characters and HTTP response splitting.

- Application Configuration

Using default configuration on the application and hosted server.

Possible deficiencies: granting the application more permissions than it actually needs, failing to properly secure resources (operating system, database, etc.) and passing internal application information back to the browser (internal messages, exceptions and trace information.)

Common Attacks: unauthorized access to administrator functionality, unauthorized access to configuration information, retrieval of clear text configuration information and unauthorized access to data stores.

Securing Your ASP.NET Web Application
Implementing security after the fact has a steep cost associated with it. Fixing software defects after the application goes into production might cost up to 15 times more than during development. Lax security also has some other indirect costs, such as damaging a company’s reputation and losing customers.

While securing an ASP.NET web application can be complex, it needs to be done on a continuous basis. The .NET framework, and ASP.NET in particular, offers great features to make it easier to properly secure your web application.

Authentication
Although ASP.NET supports several authentication methods, form authentication is the most commonly used by web applications. Unfortunately, this approach is not a particularly secure approach as it sends user’s credentials to the server in clear text. Depending on requirements, you might want to consider using SSL throughout the site or at least on the login page.

But since SSL might be impractical for many commercial web applications, one new & unique approach that you can consider is using Silverlight. Silverlight can be embedded on any sensitive page and provide encryption of any submitted data.

A web application’s authentication can be further enhanced with the following:

- Password Policy

Enforce a password policy including strong passwords, password expiration, and possibly locking user accounts after a few unsuccessful login attempts.

- Guessing Credentials – Brute Force Attacks

In addition to the above, you might want to introduce a random delay of a few seconds upon unsuccessful user login. This would make brute force attacks impractical to execute (use Thread.Sleep for this scenario.)

- Password Hashing

If you manage your authentication store, make sure to hash all user passwords.

Page Authorization & Data Validation
Small web applications are often built as a series of fairly isolated web pages. Each page is designed to handle its own security and functionality, basically acting as a mini application. Although this approach might work when security & maintenance concerns are few, it very rarely works for a larger web application.

One approach that is commonly implemented, which can offer a solid data validation and authorization infrastructure, is the development of a web framework to be used by all ASP.NET web pages in a consistent manner. This web framework should be designed to employ common authorization and data validation security check points upon every user request, allowing the application to streamline and tighten many security aspects throughout the application.

Building such a web framework in ASP.NET is surprisingly easy. Using .NET inheritance, we can design one or more ASP.NET base classes to inherit from the System.Web.UI.Page object. These base classes would run during each page lifecycle and would verify each user request before the results are served to the user.

The following page lifecycle events are commonly used to perform security checks before the page begins processing the request: Init, InitComplete and PreLoad.

Constructing the ASP.NET Web Framework
Structuring base web pages is easy. Let’s assume that our ASP.NET web application supports three kinds of users:

Unregistered users – allowed to browse anything publicly available.

Logged-in users – allowed to browse anything that’s public plus their own private information.

Administrators - same as a logged-in user plus some extra admin functionality.

Diagram 1: Base class to serve unregistered users and the foundation for other base classes

public abstract class BaseWebPage : System.Web.UI.Page
{
...
}Note: This class should verify general information submitted by users, such as URL parameters, form data to some extent, cookies and other info that is not tied to any particular user.
Diagram 2: User base class to be inherited by all pages used by logged-in users

public abstract class UserWebPage : BaseWebPage
{
...
}Note: This class should ensure that the user is currently logged-in and has access to the page functionality and to the date they want to view.
Diagram 3: Administrator base class to be inherited by all pages used by administrators

public abstract class AdminWebPage : UserWebPage
{
...
}Note: This class should ensure that in the current user is indeed an administrator.
Linking the Page to Our Web Framework
Utilizing the ASP.NET web framework above requires very minor adjustments to a web page. Rather than using the default ASP.NET page base class (System.Web.UI.Page) use the appropriate base class defined earlier.

For instance, if we defined a new ASPX page that is supposed to serve logged-in users we would define it as follows:

Diagram 4: Sample ASPX code-behind page serving a particular user

public partial class ShowUserSettingsPage : UserWebPage
{
...
}

Performing Page Authorization & Data Validation
Now that we have built our web framework, all we have left is to verify user authorization per page and to perform general data validation for each request.

To perform page authorization, we would define one virtual method on the BaseWebPage class to authorize the current user. Both the UserWebPage and the AdminWebPage would override this method and provide their own implementation. We would call this method on Page_Init from the BaseWebPage before any page processing is taking place.

This might be implemented as follows:

Diagram 5: Page authorization & data validation on BaseWebPage base class

public abstract class BaseWebPage : System.Web.UI.Page
{
protected void Page_Init(object sender, EventArgs e)
{
AuthorizeUser();

ValidateSubmittedData();
}

protected virtual void AuthorizeUser()
{
//no need to do anything for unregistered users
}

...

}Note: Class calls a virtual method AuthorizeUser that inheriting classes can implement to force specific user access rights, and once the user is authorized, the class verifies all data submitted to the web page.
Diagram 6: Page authorization on UserWebPage for ASP.NET web pages designated for logged-in users

public abstract class UserWebPage : BaseWebPage
{
protected override void AuthorizeUser()
{
if(!User.IsInRole("User"))
{
//user cannot see the page - redirect to appropriate page
}
}
}Note: Class overrides the AuthorizeUser to make sure current user is logged-in.
More on Data Validation
A centralized web framework can offer many security benefits to web applications, but it often needs to be complemented with page-specific security measures to ensure proper data validation.

Web pages should employ data validation based on the following guidelines:

Data validation – web pages should enforce strict data validation on any piece of data not strictly covered by the web framework. This might include additional type casting (for instance ensures that a piece of data is an integer) range and length. Regular expressions and Regex class are a great a great way to constrain input in ASP.NET.
Encoding – any web page displaying data on the browser that cannot be guaranteed to be safe should be encoded using Server.HtmlEncode to prevent any malicious cross-site scripting (XSS) attacks.
URL write actions– avoid performing database write actions against URL parameters even if data is valid and the user has authorization to perform such actions. Also ensure that every POST action is actually done from an internal application page to prevent cross-site request forgeries (CSRF) attacks.
Exceptions – make sure to catch any possible exceptions and only send user-friendly messages to the browser to avoid revealing any sensitive information that might reveal an application’s vulnerabilities.
Data Authorization – Data Access Framework
N-tier infrastructure is not a foreign concept to most ASP.NET developers and can provide substantial benefits in terms of performance and scalability. Among the many benefits of n-tier architecture, it also can be used to centralize and enforce strict authorization rules.

To do this effectively, a data access framework should be built as an isolated component and should be designed to do the following for each piece of functionality exposed to the ASP.NET web application:

Parameter Validation - validate all parameters supplied by the user for type, range, length, etc.
Authentication - ensure that the calling user is a valid user.
Authorization – verify that the user has rights to perform the current database operation.
Database Queries - avoid using dynamic SQL queries, if possible, and only use parameters.
User Data - only send back data that the current user is entitled to view or return user-friendly exceptions.
Application Configuration
Different applications require different configurations but the focus of this section is on those that fall under the responsibility of the web developer.

Encrypting Sensitive Configuration Information
Any sensitive configuration information on the web.config and beyond should be properly encrypted to avoid exposing sensitive details like connection strings to potential attackers. You can use the web.config protectedData section to indicate which sections of the web.config file should be encrypted.

The following shows how to protect the connectionStrings section:

Diagram 7: Protecting the connectionStrings section within the web.config

protectedData
protectedDataSections
add name="connectionStrings"
provider="RSAProtectedConfigurationProvider"
protectedDataSections
protectedData

Note: This is a more suitable way to protect data across different web servers. Unlike DPAPI, the information is not tied down to any particular machine.
You can now use aspnet_regiis to encrypt the appropriate section:
aspnet_regiis -pef connectionStrings "c:\...\MyWebApplication"

Protect Internal Exceptions
Prevent detailed exceptions from being displayed on the client’s browser entirely or display this only when the client is browsing on the web server itself.

Final Note
Even though it can be tempting to push off dealing with security (or avoiding it altogether), its importance should never be underestimated. An attack or even a request for a security audit by a customer can cost you time, money and potentially your company’s reputation.

Comments
DotNetKicks.com
April 8, 2009
4:21 PMTrackback from DotNetKicks.com

Securing ASP.NET Applications DotNetShoutout
April 8, 2009
4:24 PMTrackback from DotNetShoutout

Securing ASP.NET Applications Have a comment?
Required


Name*

Please choose another nameRequired
E-mail*

RequiredPlease enter a valid e-mail
Website

Please enter a valid URL