23-08-2012, 02:34 PM
Do the changes made in ASP .NET, from version 1.X to 2.0, improve the security?
1ASP .NET.pdf (Size: 462.44 KB / Downloads: 63)
Abstract
The problem, from a security perspective, with every Web application is that they are made
available to the public via the World Wide Web (WWW). The biggest challenge for a Web platform
development company is to make security countermeasures as easy as possible for Web
application developers to implement. This is exactly what Microsoft have tried to achieve with its
new release of Microsoft .NET (2.0).
The thesis is created to be as good and simple as possible. The basic idea is to divide all the most
common Web application vulnerabilities into categories and then systematically tackle them one
by one. By doing this you get a really good overview of each category’s main threats and its
ASP .NET countermeasure in both version 1.X and 2.0.
To summarize the changes, made from ASP .NET 1.X to ASP .NET 2.0, you can say that they
have “patched” most of the shortcomings in ASP .NET 1.X, such as the HttpOnly cookie attribute,
AES encryption is now available for forms authentication and it’s now possible to encrypt parts
of .config files. The biggest change though is the prebuilt features, such as auditing and logging,
authentication and authorization. The reason why they are prebuilt is to increase productivity,
which in turn, indirectly, increases security. The idea is very good from a security perspective, if
you intend to start from scratch and have no intention of implementing anything by your self, but
if you already have a database you’ve to rewrite some of the chosen provider’s code or create a
provider of your own.
Introduction
Background
The pure and simple reason why I wrote this thesis is because it combines two of my biggest
interests; Microsoft .NET and IS / IT security. Since Microsoft .NET is out of the scope of this
thesis and that’s why it’s limited to a part of it; ASP .NET, which is Microsoft’s new initiative of
creating Web form based Web applications.
Method
The obvious source of information for this kind of thesis is of course the Internet and books. I
also did some testing of the countermeasures that I didn’t fully understand. These tests were only
done to help myself produce a better explanation of the countermeasure in the thesis.
The layout of this thesis is inspired by how a good MSDN Library book / Web site tackled the
issue of presenting ASP .NET’s security countermeasures in a good and simple way. The basic
idea is to divide all the most common Web application vulnerabilities into categories and then
systematically tackle them one by one. By doing this you get a really good overview of each
category’s main threats and its ASP .NET countermeasure in both ASP .NET 1.X and ASP .NET 2.0.
ASP .NET security
ASP .NET security and security in general is fundamentally about protecting your assets. An asset
can be everything from your Web page, Web site, Web application or customer database to your
company’s reputation.
What you’re protecting your assets from is threats. A threat is any potential occurrence, malicious
or otherwise, that could harm an asset. The possibility for harm to occur is called risk. Security is
therefore all about risk management and implementing effective countermeasures.
The weakness that makes a threat possible is called a vulnerability. A vulnerability can be caused
by poor design, configuration mistakes or inappropriate and insecure coding techniques. Weak
input validation is one example of a vulnerability, which can result in input attacks. An attack is
an action that exploits a vulnerability or enacts a threat.
How to secure an ASP .NET Web application
To create a secure and “hack resilient”1 distributed ASP .NET Web application, you need to have a
holistic and systematic approach when securing your Web application’s hosts and network.
The core elements of a secure network are; the firewall, the router and the switch. For more
information about these elements, read chapter 15 in Improving Web application security:
Threats and Countermeasures.
The hosts are a little more complex since they include the operating system (OS), the platform
components and services, such as the .NET Framework, Internet Information Services (IIS) and
SQL Server 200X, and the runtime components and services, such as the ASP .NET runtime
environment, which is the runtime environment that executes ASP .NET’s web applications and
web services.
This report will, from now on, mainly investigate the security related changes made to ASP .NET,
from version 1.X to 2.0. Information on how to secure the rest of the hosts can be found in
chapter 16 – 18 in Improving Web application security: Threats and Countermeasures.
Auditing and logging
The auditing and logging vulnerability category addresses the question: who did what and when?
Auditing is all about how you analyze your Web application’s logs and data. Efficient auditing is a
vital aid in identifying intruders or attacks in progress.
Logging is all about how your Web application logs security related events. Efficient logging
proves particularly useful as forensic information when determining how an intrusion or attack
was performed. It’s much harder for a user to deny performing an operation if a series of
synchronized log entries, on multiple servers, indicate that the user performed that operation.
Efficient auditing and logging is therefore the key to preventing threats, such as; foot printing,
password cracking attempts and repudiation. The top auditing and logging related threats include:
Authorization threat: Disclosure of confidential data
The disclosure of confidential data can occur if sensitive data can be viewed by unauthorized
users. Confidential data includes application specific data such as credit card numbers, employee
details, financial records and so on together with application configuration data such as service
account credentials and database connection strings. To prevent the disclosure of confidential
data you should secure it in persistent stores such as databases and configuration files and during
transit over the network. Only authenticated and authorized users should be able to access the
data that is specific to them. Access to system level configuration data should be restricted to
administrators.