• Choose a category
• All
• Classic-Fiction

ASP.NET simplifies programming secure applications by providing a built-in infrastructure that supplies application-level protection against unauthorized access to Web pages. Be aware, though, that this kind of security is only one side of the coin. A really secure Web site is especially well protected against server attacks, which can sneakily be used to scale the highest protective walls of the application logic.

In this chapter, we will discuss the security context of ASP.NET, including its relationship with server-side Internet Information Services (IIS) authentication mechanisms and best coding practices to fend off Web attacks.

Where the Threats Come From

The concept of security implies the presence of an enemy we’re protecting against. In Table 19-1, you find summarized the most common types of Web attacks.

Table 19-1. Common Web Attacks

Attack

Description

Cross-site scripting (XSS)

The attacker exploits user input blindly echoed to the page to add malicious behavior to the page such as capturing sensitive data.

Denial of service (DoS)

The attacker floods the network with fake requests, overloading the system and blocking regular traffic.

Eavesdropping

The attacker uses a sniffer to read unencrypted network packets as they are transported on the network.

Hidden-field tampering

The attacker compromises unchecked (and trusted) hidden fields stuffed with sensitive data.

One-click

Malicious HTTP posts are sent via script.

Session hijacking

The attacker guesses or steals a valid session ID and connects over another user’s session.

SQL injection

The attacker inserts malicious input that the code blissfully concatenates to form dangerous SQL commands.

The bottom line is that whenever you insert any sort of user input into the browser’s markup, you potentially expose yourself to a code-injection attack (that is, any variations of SQL injection and XSS). In addition, sensitive data should never be sent across the wire (let alone as clear text) and must be stored safely on the server.

If there’s a way to write a bulletproof and tamper-resistant application, it can consist only of the combination of the following aspects:

Coding practices Data validation, type and buffer-length checking, and antitampering measures

Data access strategies Using roles to ensure the weakest possible account is used on the server to limit server resource access, and using stored procedures or, at least, parameterized commands

Effective storage and administration No sending of critical data down to the client, using hashed values to detect manipulation, authenticating users and protecting identities, and applying rigorous policies for passwords

As you can see from this list, a secure application can result only from the combined efforts of developers, architects, and administrators. Don’t imagine that you can get it right otherwise.

The ASP.NET Security Context

From an application point of view, security is mostly a matter of authenticating users and authorizing actions on the system’s resources. ASP.NET provides a range of authentication and authorization mechanisms implemented in conjunction with IIS, the Microsoft .NET Framework, and the underlying security services of the operating system. The overall security context of an ASP.NET application is composed of three distinct levels:

The IIS level associates a valid security token with the sender of the request. The security token is determined according to the current IIS authentication mechanism.

The ASP.NET worker process level determines the identity of the thread in the ASP.NET worker process serving the request. If enabled, impersonation settings can change the security token associated with the thread. The identity of the process model is determined by settings in the configuration file or the IIS metabase, according to the process model in use. These two levels are unified if the ASP.NET application runs in integrated mode on IIS 7 and later.

The ASP.NET pipeline level