Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Build Your Own ASP.NET 2.0 Web Site Using CSharp And VB (2006) [eng]-1.pdf
Скачиваний:
142
Добавлен:
16.08.2013
Размер:
15.69 Mб
Скачать

13 Security and User Authentication

The issue of security is important in many facets of information technology, but it’s especially relevant in web development. While you’ll want to make sure that your web site users are able to go where they need to go and see what they’re allowed to see, you’ll also want to prevent unauthorized and malicious users from getting into your system.

One common approach is to have visitors to your site log in before they can view certain pages; another is to ensure that restricted pages cannot be accessed simply by typing in the appropriate URLs, unless the user has been specifically allowed to view those pages. Although different solutions exist for the various applications you may create—for instance, IIS could provide certain pages to users who have been authenticated by Windows within an intranet environment—this chapter focuses on the more straightforward tasks of formand script-based authentication.

In this chapter, we’ll learn some simple coding techniques and discover just how easy it is to secure your web applications using ASP.NET. As with many other chapters, this one contains many goodies that will be new to existing ASP.NET 1.0 and 1.1 programmers, because ASP.NET 2.0 delivers new techniques for securing your web applications.

Security is a huge topic, and several books have been written on the subject. If you’re serious about developing secure complex applications, we recommend that you check out some additional resources, such as Professional ASP.NET 2.0 Security,

Chapter 13: Security and User Authentication

Membership, and Role Management (Wrox Press, 2006), and Writing Secure Code, Second Edition (Microsoft Press, 2002).

Basic Security Guidelines

The primary and most important element of building secure applications is to consider and plan an application’s security from the early stages of its development. Of course, we must know the potential internal and external threats to which an application will be exposed before we can plan the security aspects of that system. Generally speaking, ASP.NET web application security involves—but is not limited to—the following considerations:

Validate user input.

Back in Chapter 6, you learned how to use validation controls to enable the client-side validation of user input, and how to double-check that validation on the server side.

Since the input your application will receive from web browsers is ultimately under users’ control, there’s always a possibility that the submitted data will not be what you expect. The submission of bad or corrupted data can generate errors in your web application, and compromise its security.

Protect your database.

The database is quite often the most important asset we need to protect—after all, it’s here that most of the information our application relies upon is stored. SQL injection attacks, which target the database, are a common threat to web application security. If the app builds SQL commands by naively assembling text strings that include data received from user input, an attacker can alter the meaning of the commands the application produces simply by including malicious code in the user input.1

You’ve already learned how to use ADO.NET to make use of command parameters, and parameterized stored procedures, in order to include user input in SQL queries. Fortunately, ADO.NET has built-in protection against injection attacks. Moreover, if you specify the data types of the parameters you add, ASP.NET will throw an exception in cases where the input parameter doesn’t match the expected data type.

1 You'll find a detailed article on SQL injection attacks at http://www.unixwiz.net/techtips/sql-injection.html.

528

Basic Security Guidelines

Display data correctly.

Assuming your web application produces HTML output, you should always bear in mind that any text you include in that output will also be interpreted as HTML by your visitors’ browsers. As such, you need to escape special characters (such as < and &) correctly, using the HttpUtility.HtmlEncode method.

This is especially important when you’re outputting a string that was originally received as user input. If that user input were to contain HTML code, that code might disrupt the appearance or functionality of your application when it was displayed. For example, if you want to display the text <script> using a Label control, you should set your label’s Text property to HttpUtility.HtmlEncode("<script>").

Note that the fields or columns of data-bound controls such as GridView and DetailsView have a property called HtmlEncode, the default value of which is True. As such, any values that are displayed by these controls are automatically HTML-encoded unless you set this property to False.

Keep sensitive data to yourself.

Even though it may not be visible in the browser window, any output that your application produces is ultimately accessible to the end user. Consequently, you should never include sensitive data (such as user passwords, credit card data, and so on) in JavaScript code, HTML hidden fields, or the ViewState collection. (Unlike the Application, Session, or Cache collections, ViewState isn’t stored on the server, but is passed back and forth between the client and the server on every request in an easily-decipherable format.)

Use encryption or hashing whenever necessary.

ASP.NET offers you the tools to encrypt your data using symmetric algorithms (which use the same key to encrypt and decrypt the data) or asymmetric algorithms (which are based on public key/private key pairs).

As we’ll see later in this chapter, ASP.NET also supports hashing, an irreversible form of encryption that you can use to encrypt passwords and store them safely on your server.

Use secure communication channels whenever necessary.

You can always use the HTTPS (HTTP Secure) protocol to secure the communication between your visitors and your site. Using this protocol, an attacker who intercepts the data being passed back and forth between your application and its users won’t obtain any meaningful data.

529