Professional ASP.NET Security - Jeff Ferguson

What You Need to Use this Book

The following is the list of recommended system requirements for running the code in this book:

a Windows 2000 Professional or Windows XP Professional with IIS installed Q Visual Studio .NET Professional or higher Q SQL Server 2000 or MSDE.

This book assumes the following knowledge:

a Good working knowledge of ASP.NET and the .NET Framework a Familiarity with C#

a Some familiarity with the Visual Studio .NET IDE

Summary of Contents

Appendix B:

Index

Building Secure Web Applications

In this chapter, we make no apologies for going back to basics and talking about the key concepts in web application security. It is important to understand why we do what we do when we secure our applications. Blindly applying security checklists is a good recipe for leaving holes in our security. By understanding what needs to be done from the ground up, we will be in a much better position to build secure applications.

We will look at:

Q Why we need security

G The main things we need to keep in mind when addressing security

G What security issues fall outside the ASP.NET application

Q What security issues we can address in the ASP.NET application

What Do We Mean by 'Security'?

Before we start discussing security, we really need to be sure about what we mean by the word 'security'. We often hear people talking about "implementing security" or "building a secure system". What do they mean by this?

One definition of security is the portion of systems design, implementation, and administration that is concerned with ensuring that the system is used in the way in which we intend. Another way at looking at this definition is that security is about preventing our system from being used in ways we don't want.

This definition is quite broad, but this is by necessity. A narrow definition of security can give us a false sense of security - making us think that we have done what we need to do to protect our application when in fact there are issues we have not considered. By keeping the definition broad, we are forced to think about the whole range of ways in which our application could be subverted.

In this book, when we talk about security, we are talking about ensuring that our application is used in the way that we intend.

What Do We Mean by 'Secure'?

The usage of the word 'Secure' can also cause problems. As we will discuss later, we can never guarantee that a system is completely secure. This means that it is not particularly useful for us to mean '100% secure' when we say 'secure'. When we say 'secure', we mean that, based on our current knowledge, we believe that using the system in a way that we do not intend is sufficiently impracticable that the chances of it happening are not significant.

This definition can be confusing as it depends on a number of variable factors so we'll use an example to illustrate what we mean.

A Hypothetical Example Of 'Secure'

Imagine a hypothetical system that is protected by a numerical password. Users must enter the password in order to access the system. Assuming the malicious user does not find a way to steal the password, they will have to guess the correct password in order to access the system.

If our password has only one digit, a malicious user has a 1 in 10 chance to guess the password on their first attempt and will only need 10 guesses to try every possible password. It is pretty obvious that we cannot call this secure.

If our password has 2 digits, there will be 100 possible passwords. This means that a malicious user has a 1 in 100 chance of guessing the password correctly on their first chance. If we allow multiple chances to enter the correct password, the chance will improve with each new guess (assuming the attacker has the sense not to enter duplicate passwords). So, on the second guess, their chance is 1 in 99, and on the third guess, their chance is 1 in 98, and so on.

If we allow unlimited guesses, the attacker will definitely get the right password within 100 guesses. They will probably get the right password much sooner than that. I think we would all agree that we should not call this a secure system.

There are two obvious ways to make this system more secure (that is, to reduce the chances that the correct password can be guessed). Firstly, we can limit the number of guessing users may make. Secondly, we can increase the number of potential passwords.

If we set a limit of three attempts to enter the right password (as is common with ATMs, for example), the chances that our two-digit password will be guessed are much reduced. Here's some math that shows the chance of guessing the password in the first three attempts.

10

A vulnerability is a feature of a system (usually unintentional) that could allow the application to be used other than in the way it is intended to be used. Note that in the context of computer security, 'vulnerability' is often used to mean a (negative) feature of a system (so we might talk about a system having a vulnerability) whereas a dictionary will tell you that 'vulnerability' should refer to the state of being vulnerable. Since it is well established in computer security that 'vulnerability' can refer to a feature as well as a state, we will use it like that in this book.

A threat refers to the possibility of a vulnerability being used to compromise the security of a system. A vulnerability in a particular system means that a threat to the system's security exists. When computer security professionals talk about a threat existing they mean that a vulnerability has cause a significant risk that the system will be compromised.

An exploit is a way of using a vulnerability to realize a threat and use a system in a way other than it was intended to be used. Until an exploit exists for a vulnerability, the risk is theoretical. Some exploits are trivial while other may involve creating complex code. New exploits for vulnerabilities in popular software are being produced all the time.

Pulling these three concepts together, we see that a vulnerability causes a threat, which is realized by an exploit. This process is often known as an attack.

We will look at some examples of vulnerabilities, threats, and exploits later in this chapter.

Why Security?

If you are reading this book, you probably accept the need for security in web applications and are interested in implementing good security. We will, however, take a couple of minutes to remind ourselves why security is so important.

The Web Application - A Double Edged Sword?

If our web server simply serves out static files to users it should, in theory, be an easy system to secure. We need to configure the web server securely but our content should not add any vulnerabilities to the system. Of course, as history has shown, even a simple web server can be compromised if it is not configured securely or vulnerabilities exist in its own code.

Technologies such as ASP and ASP.NET enable us to develop much more sophisticated systems than those built with static pages. Unfortunately, along with being able to provide an interactive experience to our users comes a greater responsibility for security. We still need some faith in the web server we use, but we must now ensure that we do not introduce any vulnerabilities of our own.

Modern web applications can have many capabilities. They usually have access to a database so that they can store and retrieve data. Often, they have direct access to the file system of the server they are running on, reading and writing files. Sometimes, they even connect to other systems within a businesses (or even another business, through a Business-To-Business (B2B) link).

As well as these capabilities, modern web applications are often used to control access to confidential information. Allowing employees to access company information over the Internet through a web application can be useful but poor security could means that competing companies can also access the information. This is obviously a bad situation.

12

Building Secure Web Applications

The Law

If our web applications collect personal information from their users, there may be an additional reason to make security a key feature. Many countries now have laws that require the protection of personal information by those who collect it. Inadequate security could place us in breach of these laws. The European Union has particularly strong data protection laws. A directive of the European Parliament included the following text in a 1995 directive (95/46/EC):

"Article 17 Security of processing

1. Member States shall provide that the controller must implement appropriate technical and organizational measures to protect personal data against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access, in particular where the processing involves the transmission of data over a network, and against all other unlawful forms of processing.

Having regard to the state of the art and the cost of their implementation, such measures shall ensure a level of security appropriate to the risks represented by the processing and the nature of the data to be protected. "

More information on European Data Protection law can be found at

http://europa.eu.int/ISPO/legal/en/dataprot/dataprot.html

In the UK, the European Parliament directive became law in the seventh principle of the 1998 Data Protection Act:

"Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data."

More information on UK Data Protection law can be found at http://www.dataprotection.gov.uk/

The USA is taking an approach to data protection that involves self regulation rather than the legislative European approach. However, in order that American businesses can exchange information with European businesses without falling foul of the European legislation, American businesses can join the Safe Harbor scheme. By joining the scheme, companies certify that they are in compliance with European data protection legislation in a number of areas, including security:

"Security: Organizations must take reasonable precautions to protect personal information from loss, misuse and unauthorized access, disclosure, alteration and destruction. "

Safe Harbor is a self-regulatory system, but breaching it can have some serious consequences. Breaches of Safe Harbor commitments could be considered deceptive practices under the Federal Trade Commission Act. This could lead to fines of up to $12,000 dollars per day!

More information about Safe Harbor can be found at http://WWW.export.gov/safeharbor/.

13

Attacks on Web Applications

There is a multitude of ways to attack Web applications. Some of them can be prevented in our ASP.NET code while others attack other parts of the systems that support the application. We will look at some representative examples of the sort of things our applications come up against.

As we said earlier, an attack consists of a exploit that takes advantage of a vulnerability in order to realize a threat. Attacks can have a wide range of end results. Here are some of the more common ones:

Q Unauthorized Access - users gain more ability to use the application than we intend. This threat often leads on to the others, but it can be an end it its own right.

Q Code Execution - malicious code is run on the target system. Like unauthorized access, this often leads to other threats.

Q Denial of Service - Legitimate users are prevented from accessing our application. Q Information Theft - Private information is compromised.

Q Damage to Information - Information is altered. A good example of this is web site defacement, where web pages are changed, often to carry offensive or political messages.

We will now have a look at some common vulnerabilities, their exploits, and the threats they expose.

Buffer Overflows

Buffer overflows have been a thorn in the side of computer security professionals for years, and are still one of the most common vulnerabilities to be exploited in network-attached applications.

A buffer overflow vulnerability exists when the length of an input from outside the application is not checked before it is inserted into memory (most commonly on the stack but the heap can also be exploited). If the input is longer than the space allocated for it in memory (the buffer), it can spill over into memory it was not supposed to occupy.

A buffer overflow exploit consists of sufficient data to fill the buffer allocated to a particular input along with some additional data that will be written into memory outside of the buffer.

Often, a buffer overflow will cause the application to crash as its memory becomes corrupted. This is a denial of service attack. If the additional data in the exploit is carefully crafted to overwrite the right parts of memory, such as a return address for a function, the execution of the application can be subverted to execute code of the attackers choice.

Execution of malicious code is obviously a big threat - on operating systems without strong security schemes (such as Windows 98) the code can do pretty much anything. Even on systems with strong security systems (such as Windows 2000), the code can do anything that the original application has permissions for.

An example of a buffer overflow vulnerability is that which was found in the Internet Printing Protocol (IPP) capability of Microsoft Internet Information Services 5.0. IPP is implemented as an ISAPI filter that processes requests with a .printer extension. eEye Digital Security (www.eEye.com) discovered that around 420 bytes sent in the host: header of a request to a .printer extension caused a buffer overflow. They created two proof-of-concept exploits of this vulnerability. One, which was publicly released, simply wrote a text file to the target computer warning of the vulnerability. The other, which they never released apart from to Microsoft, allowed an attacker to run arbitrary commands on the target machine using the local system account - effectively gaining control of the target machine.

14

Building Secure Web Applications

Microsoft swiftly released a patch to remove the buffer overflow vulnerability in the IPP ISAPI filter. This is the normal pattern in the discovery of buffer overflow vulnerabilities - a proof-of-concept is sent to the software vendor and they release a patch as soon as they can. The import thing for those of us who use products such as Internet Information Services is that we stay up to date with patches, especially those released in response to a security vulnerability being discovered.

.NET - No More Need to Worry About Buffer Overflows?

Because the code that we write to run under the .NET CLR is fully managed, our code cannot expose buffer overflow vulnerabilities - all data is checked by the CLR before it is inserted into memory. We do, however, still need to be aware of the dangers of buffer overflows.

Because managed code relies on the CLR to do its bounds checking for it, any vulnerabilities in the CLR will become vulnerabilities in our applications. This makes it very important to keep up to date with patches for the .NET Framework (as well as IIS, SQL Server, and any other applications we are running).

If we ever use any unmanaged code in our applications, we are stepping outside of the protection of the CLR and become responsible for our own bounds checking. It is very important in these situations for us to ensure that we do not introduce any buffer overflow vulnerabilities. Fortunately, Visual C++ .NET includes additional protection against buffer overflow vulnerabilities. By default, additional code is added to functions that could be vulnerable to buffer overflows. This code inserts some additional random data (often known as the canary after the birds that miners used to test for bad air) onto the stack, which is checked after the function has executed. If the canary has changed, appropriate action can be taken. By default, the process halts.

Script Injection and Cross-Site Scripting

If we do not deal with input from users properly, we can introduce a script injection vulnerability into our application. Allowing users to insert client-side scripting of their own into a database or even simply onto pages can cause problems.

An exploit for a script injection vulnerability will take the form of some malicious client-side script, designed to be viewed by another user. If there is a way for a user to have this script displayed to other users, they can use it to run their script as if it were coming from our application (which, in a way, it is).

A cross-site scripting exploit will take the form of a URL with client-side script in URL parameters. This URL is designed to trick users into browsing to a page that then has additional script added to it, which is run as if it came from the page being viewed.

The threats exposed by script injection and cross-site scripting are mainly to the users of our application, but they can have some extreme consequences. Some simple redirection code can be used to mount an effective denial of service attack against an application. Cross-site scripting has been used to steal users' cookies. Stealing cookies can allow a malicious user to pose as another user. An infamous example of this was an exploit for a cross-site scripting vulnerability in Hotmail that allowed users to steal the authentication cookies of another user and gain control of their e-mail account.

Both script injection and cross-site scripting are covered in more detail in Chapter 2, along with techniques for preventing these vulnerabilities.