Professional ASP.NET Security.pdf

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

Introduction

Chapter 1:

Chapter 2:

Chapter 3:

Chapter 4:

Chapter 5:

Chapter 6:

Chapter 7:

Chapter 8:

Chapter 9:

Chapter 10:

Chapter 11:

Chapter 12:

Chapter 13:

Chapter 14:

Chapter 15:

Appendix A:

Appendix B:

Index

Building Secure Web Applications

Treating the Client with Caution

Storing Secrets Securing

Database Access Implementing

Password Policies The ASP.NET

Security Framework Windows

Authentication .NET Passport

Forms Authentication Extending

Forms Authentication Custom

Authentication Implementing

Authorization Code Access

Security Web Service Security

Impersonation Configuring IIS for

Security ASP.NET Security

Configuration

33 71

79 91

107

123

139

163

203

243

283

309

349

373

383

399

421

Professional ASP.NET Security

Russ Basiura

Richard Conway

Brady Gaster

Dan Kent

Sitaraman Lakshminarayanan

Enrico Sabbadin

Doug Seven

Srinivasa Sivakumar

Ltd.®

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.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: