Chapter 2 – Threats and Countermeasures

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Microsoft Corporation

Published: June 2003

Last Revised: January 2006

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.

Summary: This chapter identifies and explains the set of top network, host and application layer threats and describes the countermeasures that are appropriate to address each threat. It also explains common attacker methodology and a series of common attacks. This chapter will help you begin to understand and categorize threats in preparation for performing threat modeling.

Contents

In This Chapter
Overview
How to Use This Chapter
Anatomy of an Attack
Understanding Threat Categories
Network Threats and Countermeasures
Host Threats and Countermeasures
Application Threats and Countermeasures
Input Validation
Authentication
Authorization
Configuration Management
Sensitive Data
Session Management
Cryptography
Parameter Manipulation
Exception Management
Auditing and Logging
Summary
Additional Resources

In This Chapter

• An explanation of attacker methodology
• Descriptions of common attacks
• How to categorize threats
• How to identify and counter threats at the network, host, and application levels

Overview

When you incorporate security features into your application's design, implementation, and deployment, it helps to have a good understanding of how attackers think. By thinking like attackers and being aware of their likely tactics, you can be more effective when applying countermeasures. This chapter describes the classic attacker methodology and profiles the anatomy of a typical attack.

This chapter analyzes Web application security from the perspectives of threats, countermeasures, vulnerabilities, and attacks. The following set of core terms are defined to avoid confusion and to ensure they are used in the correct context.

• Asset. A resource of value such as the data in a database or on the file system, or a system resource
• Threat. A potential occurrence — malicious or otherwise — that may harm an asset
• Vulnerability. A weakness that makes a threat possible
• Attack (or exploit). An action taken to harm an asset
• Countermeasure. A safeguard that addresses a threat and mitigates risk

This chapter also identifies a set of common network, host, and application level threats, and the recommended countermeasures to address each one. The chapter does not contain an exhaustive list of threats, but it does highlight many top threats. With this information and knowledge of how an attacker works, you will be able to identify additional threats. You need to know the threats that are most likely to impact your system to be able to build effective threat models. These threat models are the subject of Chapter 3, "Threat Modeling."

How to Use This Chapter

The following are recommendations on how to use this chapter:

• Become familiar with specific threats that affect the network host and application. The threats are unique for the various parts of your system, although the attacker's goals may be the same.
• Use the threats to identify risk. Then create a plan to counter those threats.
• Apply countermeasures to address vulnerabilities. Countermeasures are summarized in this chapter. Use Part III, "Building Secure Web Applications," and Part IV, "Securing Your Network, Host, and Application," of this guide for countermeasure implementation details.
• When you design, build, and secure new systems, keep the threats in this chapter in mind. The threats exist regardless of the platform or technologies that you use.

Anatomy of an Attack

By understanding the basic approach used by attackers to target your Web application, you will be better equipped to take defensive measures because you will know what you are up against. The basic steps in attacker methodology are summarized below and illustrated in Figure 2.1:

• Survey and assess
• Exploit and penetrate
• Escalate privileges
• Maintain access
• Deny service

Figure 2.1

Basic steps for attacking methodology

Survey and Assess

Surveying and assessing the potential target are done in tandem. The first step an attacker usually takes is to survey the potential target to identify and assess its characteristics. These characteristics may include its supported services and protocols together with potential vulnerabilities and entry points. The attacker uses the information gathered in the survey and assess phase to plan an initial attack.

For example, an attacker can detect a cross-site scripting (XSS) vulnerability by testing to see if any controls in a Web page echo back output.

Exploit and Penetrate

Having surveyed a potential target, the next step is to exploit and penetrate. If the network and host are fully secured, your application (the front gate) becomes the next channel for attack.

For an attacker, the easiest way into an application is through the same entrance that legitimate users use — for example, through the application's logon page or a page that does not require authentication.

Escalate Privileges

After attackers manage to compromise an application or network, perhaps by injecting code into an application or creating an authenticated session with the Microsoft® Windows® 2000 operating system, they immediately attempt to escalate privileges. Specifically, they look for administration privileges provided by accounts that are members of the Administrators group. They also seek out the high level of privileges offered by the local system account.

Using least privileged service accounts throughout your application is a primary defense against privilege escalation attacks. Also, many network level privilege escalation attacks require an interactive logon session.

Maintain Access

Having gained access to a system, an attacker takes steps to make future access easier and to cover his or her tracks. Common approaches for making future access easier include planting back-door programs or using an existing account that lacks strong protection. Covering tracks typically involves clearing logs and hiding tools. As such, audit logs are a primary target for the attacker.

Log files should be secured, and they should be analyzed on a regular basis. Log file analysis can often uncover the early signs of an attempted break-in before damage is done.

Deny Service

Attackers who cannot gain access often mount a denial of service attack to prevent others from using the application. For other attackers, the denial of service option is their goal from the outset. An example is the SYN flood attack, where the attacker uses a program to send a flood of TCP SYN requests to fill the pending connection queue on the server. This prevents other users from establishing network connections.

Understanding Threat Categories

While there are many variations of specific attacks and attack techniques, it is useful to think about threats in terms of what the attacker is trying to achieve. This changes your focus from the identification of every specific attack — which is really just a means to an end — to focusing on the end results of possible attacks.

STRIDE

Threats faced by the application can be categorized based on the goals and purposes of the attacks. A working knowledge of these categories of threats can help you organize a security strategy so that you have planned responses to threats. STRIDE is the acronym used at Microsoft to categorize different threat types. STRIDE stands for:

• Spoofing. Spoofing is attempting to gain access to a system by using a false identity. This can be accomplished using stolen user credentials or a false IP address. After the attacker successfully gains access as a legitimate user or host, elevation of privileges or abuse using authorization can begin.
• Tampering. Tampering is the unauthorized modification of data, for example as it flows over a network between two computers.
• Repudiation. Repudiation is the ability of users (legitimate or otherwise) to deny that they performed specific actions or transactions. Without adequate auditing, repudiation attacks are difficult to prove.
• Information disclosure. Information disclosure is the unwanted exposure of private data. For example, a user views the contents of a table or file he or she is not authorized to open, or monitors data passed in plaintext over a network. Some examples of information disclosure vulnerabilities include the use of hidden form fields, comments embedded in Web pages that contain database connection strings and connection details, and weak exception handling that can lead to internal system level details being revealed to the client. Any of this information can be very useful to the attacker.
• Denial of service. Denial of service is the process of making a system or application unavailable. For example, a denial of service attack might be accomplished by bombarding a server with requests to consume all available system resources or by passing it malformed input data that can crash an application process.
• Elevation of privilege. Elevation of privilege occurs when a user with limited privileges assumes the identity of a privileged user to gain privileged access to an application. For example, an attacker with limited privileges might elevate his or her privilege level to compromise and take control of a highly privileged and trusted process or account.

STRIDE Threats and Countermeasures

Each threat category described by STRIDE has a corresponding set of countermeasure techniques that should be used to reduce risk. These are summarized in Table 2.1. The appropriate countermeasure depends upon the specific attack. More threats, attacks, and countermeasures that apply at the network, host, and application levels are presented later in this chapter.

Table 2.1   STRIDE Threats and Countermeasures

Threat	Countermeasures
Spoofing user identity	Use strong authentication. Do not store secrets (for example, passwords) in plaintext. Do not pass credentials in plaintext over the wire. Protect authentication cookies with Secure Sockets Layer (SSL).
Tampering with data	Use data hashing and signing. Use digital signatures. Use strong authorization. Use tamper-resistant protocols across communication links. Secure communication links with protocols that provide message integrity.
Repudiation	Create secure audit trails. Use digital signatures.
Information disclosure	Use strong authorization. Use strong encryption. Secure communication links with protocols that provide message confidentiality. Do not store secrets (for example, passwords) in plaintext.
Denial of service	Use resource and bandwidth throttling techniques. Validate and filter input.
Elevation of privilege	Follow the principle of least privilege and use least privileged service accounts to run processes and access resources.

Network Threats and Countermeasures

The primary components that make up your network infrastructure are routers, firewalls, and switches. They act as the gatekeepers guarding your servers and applications from attacks and intrusions. An attacker may exploit poorly configured network devices. Common vulnerabilities include weak default installation settings, wide open access controls, and devices lacking the latest security patches. Top network level threats include:

• Information gathering
• Sniffing
• Spoofing
• Session hijacking
• Denial of service

Information Gathering

Network devices can be discovered and profiled in much the same way as other types of systems. Attackers usually start with port scanning. After they identify open ports, they use banner grabbing and enumeration to detect device types and to determine operating system and application versions. Armed with this information, an attacker can attack known vulnerabilities that may not be updated with security patches.

Countermeasures to prevent information gathering include:

• Configure routers to restrict their responses to footprinting requests.
• Configure operating systems that host network software (for example, software firewalls) to prevent footprinting by disabling unused protocols and unnecessary ports.

Sniffing

Sniffing or eavesdropping is the act of monitoring traffic on the network for data such as plaintext passwords or configuration information. With a simple packet sniffer, an attacker can easily read all plaintext traffic. Also, attackers can crack packets encrypted by lightweight hashing algorithms and can decipher the payload that you considered to be safe. The sniffing of packets requires a packet sniffer in the path of the server/client communication.

Countermeasures to help prevent sniffing include:

• Use strong physical security and proper segmenting of the network. This is the first step in preventing traffic from being collected locally.
• Encrypt communication fully, including authentication credentials. This prevents sniffed packets from being usable to an attacker. SSL and IPSec (Internet Protocol Security) are examples of encryption solutions.

Spoofing

Spoofing is a means to hide one's true identity on the network. To create a spoofed identity, an attacker uses a fake source address that does not represent the actual address of the packet. Spoofing may be used to hide the original source of an attack or to work around network access control lists (ACLs) that are in place to limit host access based on source address rules.

Although carefully crafted spoofed packets may never be tracked to the original sender, a combination of filtering rules prevents spoofed packets from originating from your network, allowing you to block obviously spoofed packets.

Countermeasures to prevent spoofing include:

• Filter incoming packets that appear to come from an internal IP address at your perimeter.
• Filter outgoing packets that appear to originate from an invalid local IP address.

Session Hijacking

Also known as man in the middle attacks, session hijacking deceives a server or a client into accepting the upstream host as the actual legitimate host. Instead the upstream host is an attacker's host that is manipulating the network so the attacker's host appears to be the desired destination.

Countermeasures to help prevent session hijacking include:

• Use encrypted session negotiation.
• Use encrypted communication channels.
• Stay informed of platform patches to fix TCP/IP vulnerabilities, such as predictable packet sequences.

Denial of Service

Denial of service denies legitimate users access to a server or services. The SYN flood attack is a common example of a network level denial of service attack. It is easy to launch and difficult to track. The aim of the attack is to send more requests to a server than it can handle. The attack exploits a potential vulnerability in the TCP/IP connection establishment mechanism and floods the server's pending connection queue.

Countermeasures to prevent denial of service include:

• Apply the latest service packs.
• Harden the TCP/IP stack by applying the appropriate registry settings to increase the size of the TCP connection queue, decrease the connection establishment period, and employ dynamic backlog mechanisms to ensure that the connection queue is never exhausted.
• Use a network Intrusion Detection System (IDS) because these can automatically detect and respond to SYN attacks.

Host Threats and Countermeasures

Host threats are directed at the system software upon which your applications are built. This includes Windows 2000, Microsoft Windows Server 2003, Internet Information Services (IIS), the .NET Framework, and SQL Server depending upon the specific server role. Top host level threats include:

• Viruses, Trojan horses, and worms
• Footprinting
• Profiling
• Password cracking
• Denial of service
• Arbitrary code execution
• Unauthorized access

Viruses, Trojan Horses, and Worms

A virus is a program that is designed to perform malicious acts and cause disruption to your operating system or applications. A Trojan horse resembles a virus except that the malicious code is contained inside what appears to be a harmless data file or executable program. A worm is similar to a Trojan horse except that it self-replicates from one server to another. Worms are difficult to detect because they do not regularly create files that can be seen. They are often noticed only when they begin to consume system resources because the system slows down or the execution of other programs halt. The Code Red Worm is one of the most notorious to afflict IIS; it relied upon a buffer overflow vulnerability in a particular ISAPI filter.

Although these three threats are actually attacks, together they pose a significant threat to Web applications, the hosts these applications live on, and the network used to deliver these applications. The success of these attacks on any system is possible through many vulnerabilities such as weak defaults, software bugs, user error, and inherent vulnerabilities in Internet protocols.

Countermeasures that you can use against viruses, Trojan horses, and worms include:

• Stay current with the latest operating system service packs and software patches.
• Block all unnecessary ports at the firewall and host.
• Disable unused functionality including protocols and services.
• Harden weak, default configuration settings.

Footprinting

Examples of footprinting are port scans, ping sweeps, and NetBIOS enumeration that can be used by attackers to glean valuable system-level information to help prepare for more significant attacks. The type of information potentially revealed by footprinting includes account details, operating system and other software versions, server names, and database schema details.

Countermeasures to help prevent footprinting include:

• Disable unnecessary protocols.
• Lock down ports with the appropriate firewall configuration.
• Use TCP/IP and IPSec filters for defense in depth.
• Configure IIS to prevent information disclosure through banner grabbing.
• Use an IDS that can be configured to pick up footprinting patterns and reject suspicious traffic.

Password Cracking

If the attacker cannot establish an anonymous connection with the server, he or she will try to establish an authenticated connection. For this, the attacker must know a valid username and password combination. If you use default account names, you are giving the attacker a head start. Then the attacker only has to crack the account's password. The use of blank or weak passwords makes the attacker's job even easier.

Countermeasures to help prevent password cracking include:

• Use strong passwords for all account types.
• Apply lockout policies to end-user accounts to limit the number of retry attempts that can be used to guess the password.
• Do not use default account names, and rename standard accounts such as the administrator's account and the anonymous Internet user account used by many Web applications.
• Audit failed logins for patterns of password hacking attempts.

Denial of Service

Denial of service can be attained by many methods aimed at several targets within your infrastructure. At the host, an attacker can disrupt service by brute force against your application, or an attacker may know of a vulnerability that exists in the service your application is hosted in or in the operating system that runs your server.

Countermeasures to help prevent denial of service include:

• Configure your applications, services, and operating system with denial of service in mind.
• Stay current with patches and security updates.
• Harden the TCP/IP stack against denial of service.
• Make sure your account lockout policies cannot be exploited to lock out well known service accounts.
• Make sure your application is capable of handling high volumes of traffic and that thresholds are in place to handle abnormally high loads.
• Review your application's failover functionality.
• Use an IDS that can detect potential denial of service attacks.

Arbitrary Code Execution

If an attacker can execute malicious code on your server, the attacker can either compromise server resources or mount further attacks against downstream systems. The risks posed by arbitrary code execution increase if the server process under which the attacker's code runs is over-privileged. Common vulnerabilities include weak IIS configuration and unpatched servers that allow path traversal and buffer overflow attacks, both of which can lead to arbitrary code execution.

Countermeasures to help prevent arbitrary code execution include:

• Configure IIS to reject URLs with "../" to prevent path traversal.
• Lock down system commands and utilities with restricted ACLs.
• Stay current with patches and updates to ensure that newly discovered buffer overflows are speedily patched.

Unauthorized Access

Inadequate access controls could allow an unauthorized user to access restricted information or perform restricted operations. Common vulnerabilities include weak IIS Web access controls, including Web permissions and weak NTFS permissions.

Countermeasures to help prevent unauthorized access include:

• Configure secure Web permissions.
• Lock down files and folders with restricted NTFS permissions.
• Use .NET Framework access control mechanisms within your ASP.NET applications, including URL authorization and principal permission demands.

Application Threats and Countermeasures

A good way to analyze application-level threats is to organize them by application vulnerability category. The various categories used in the subsequent sections of this chapter and throughout the guide, together with the main threats to your application, are summarized in Table 2.2.

Table 2.2   Threats by Application Vulnerability Category

Category	Threats
Input validation	Buffer overflow; cross-site scripting; SQL injection; canonicalization
Authentication	Network eavesdropping; brute force attacks; dictionary attacks; cookie replay; credential theft
Authorization	Elevation of privilege; disclosure of confidential data; data tampering; luring attacks
Configuration management	Unauthorized access to administration interfaces; unauthorized access to configuration stores; retrieval of clear text configuration data; lack of individual accountability; over-privileged process and service accounts
Sensitive data	Access sensitive data in storage; network eavesdropping; data tampering
Session management	Session hijacking; session replay; man in the middle
Cryptography	Poor key generation or key management; weak or custom encryption
Parameter manipulation	Query string manipulation; form field manipulation; cookie manipulation; HTTP header manipulation
Exception management	Information disclosure; denial of service
Auditing and logging	User denies performing an operation; attacker exploits an application without trace; attacker covers his or her tracks

Input Validation

Input validation is a security issue if an attacker discovers that your application makes unfounded assumptions about the type, length, format, or range of input data. The attacker can then supply carefully crafted input that compromises your application.

When network and host level entry points are fully secured; the public interfaces exposed by your application become the only source of attack. The input to your application is a means to both test your system and a way to execute code on an attacker's behalf. Does your application blindly trust input? If it does, your application may be susceptible to the following:

• Buffer overflows
• Cross-site scripting
• SQL injection
• Canonicalization

The following section examines these vulnerabilities in detail, including what makes these vulnerabilities possible.

Buffer Overflows

Buffer overflow vulnerabilities can lead to denial of service attacks or code injection. A denial of service attack causes a process crash; code injection alters the program execution address to run an attacker's injected code. The following code fragment illustrates a common example of buffer overflow vulnerability.

void SomeFunction( char *pszInput )
{
  char szBuffer[10];
  // Input is copied straight into the buffer when no type checking is performed
  strcpy(szBuffer, pszInput);
  . . .
}

Managed .NET code is not susceptible to this problem because array bounds are automatically checked whenever an array is accessed. This makes the threat of buffer overflow attacks on managed code much less of an issue. It is still a concern, however, especially where managed code calls unmanaged APIs or COM objects.

Countermeasures to help prevent buffer overflows include:

• Perform thorough input validation. This is the first line of defense against buffer overflows. Although a bug may exist in your application that permits expected input to reach beyond the bounds of a container, unexpected input will be the primary cause of this vulnerability. Constrain input by validating it for type, length, format and range.
• When possible, limit your application's use of unmanaged code, and thoroughly inspect the unmanaged APIs to ensure that input is properly validated.
• Inspect the managed code that calls the unmanaged API to ensure that only appropriate values can be passed as parameters to the unmanaged API.
• Use the /GS flag to compile code developed with the Microsoft Visual C++® development system. The /GS flag causes the compiler to inject security checks into the compiled code. This is not a fail-proof solution or a replacement for your specific validation code; it does, however, protect your code from commonly known buffer overflow attacks. For more information, see the .NET Framework Product documentation https://msdn.microsoft.com/en-us/library/8dbf701c(VS.71).aspx and Microsoft Knowledge Base article 325483 "WebCast: Compiler Security Checks: The –GS compiler switch."

Example of Code Injection Through Buffer Overflows

An attacker can exploit a buffer overflow vulnerability to inject code. With this attack, a malicious user exploits an unchecked buffer in a process by supplying a carefully constructed input value that overwrites the program's stack and alters a function's return address. This causes execution to jump to the attacker's injected code.

The attacker's code usually ends up running under the process security context. This emphasizes the importance of using least privileged process accounts. If the current thread is impersonating, the attacker's code ends up running under the security context defined by the thread impersonation token. The first thing an attacker usually does is call the RevertToSelf API to revert to the process level security context that the attacker hopes has higher privileges.

Make sure you validate input for type and length, especially before you call unmanaged code because unmanaged code is particularly susceptible to buffer overflows.

Cross-Site Scripting

An XSS attack can cause arbitrary code to run in a user's browser while the browser is connected to a trusted Web site. The attack targets your application's users and not the application itself, but it uses your application as the vehicle for the attack.

Because the script code is downloaded by the browser from a trusted site, the browser has no way of knowing that the code is not legitimate. Internet Explorer security zones provide no defense. Since the attacker's code has access to the cookies associated with the trusted site and are stored on the user's local computer, a user's authentication cookies are typically the target of attack.

Example of Cross-Site Scripting

To initiate the attack, the attacker must convince the user to click on a carefully crafted hyperlink, for example, by embedding a link in an email sent to the user or by adding a malicious link to a newsgroup posting. The link points to a vulnerable page in your application that echoes the unvalidated input back to the browser in the HTML output stream. For example, consider the following two links.

Here is a legitimate link:

www.yourwebapplication.com/logon.aspx?username=bob

Here is a malicious link:

www.yourwebapplication.com/logon.aspx?username=<script>alert('hacker code')</script>

If the Web application takes the query string, fails to properly validate it, and then returns it to the browser, the script code executes in the browser. The preceding example displays a harmless pop-up message. With the appropriate script, the attacker can easily extract the user's authentication cookie, post it to his site, and subsequently make a request to the target Web site as the authenticated user.

Countermeasures to prevent XSS include:

• Perform thorough input validation. Your applications must ensure that input from query strings, form fields, and cookies are valid for the application. Consider all user input as possibly malicious, and filter or sanitize for the context of the downstream code. Validate all input for known valid values and then reject all other input. Use regular expressions to validate input data received via HTML form fields, cookies, and query strings.
• Use HTMLEncode and URLEncode functions to encode any output that includes user input. This converts executable script into harmless HTML.

SQL Injection

A SQL injection attack exploits vulnerabilities in input validation to run arbitrary commands in the database. It can occur when your application uses input to construct dynamic SQL statements to access the database. It can also occur if your code uses stored procedures that are passed strings that contain unfiltered user input. Using the SQL injection attack, the attacker can execute arbitrary commands in the database. The issue is magnified if the application uses an over-privileged account to connect to the database. In this instance it is possible to use the database server to run operating system commands and potentially compromise other servers, in addition to being able to retrieve, manipulate, and destroy data.

Example of SQL Injection

Your application may be susceptible to SQL injection attacks when you incorporate unvalidated user input into database queries. Particularly susceptible is code that constructs dynamic SQL statements with unfiltered user input. Consider the following code:

SqlDataAdapter myCommand = new SqlDataAdapter(
         "SELECT * FROM Users 
          WHERE UserName ='" + txtuid.Text + "'", conn);

Attackers can inject SQL by terminating the intended SQL statement with the single quote character followed by a semicolon character to begin a new command, and then executing the command of their choice. Consider the following character string entered into the txtuid field.

'; DROP TABLE Customers -

This results in the following statement being submitted to the database for execution.

SELECT * FROM Users WHERE UserName=''; DROP TABLE Customers --'

This deletes the Customers table, assuming that the application's login has sufficient permissions in the database (another reason to use a least privileged login in the database). The double dash (--) denotes a SQL comment and is used to comment out any other characters added by the programmer, such as the trailing quote.

Note   The semicolon is not actually required. SQL Server will execute two commands separated by spaces.

Other more subtle tricks can be performed. Supplying this input to the txtuid field:

' OR 1=1 -

builds this command:

SELECT * FROM Users WHERE UserName='' OR 1=1 -

Because 1=1 is always true, the attacker retrieves every row of data from the Users table.

Countermeasures to prevent SQL injection include:

• Perform thorough input validation. Your application should validate its input prior to sending a request to the database.
• Use parameterized stored procedures for database access to ensure that input strings are not treated as executable statements. If you cannot use stored procedures, use SQL parameters when you build SQL commands.
• Use least privileged accounts to connect to the database.

Canonicalization

Different forms of input that resolve to the same standard name (the canonical name), is referred to as canonicalization. Code is particularly susceptible to canonicalization issues if it makes security decisions based on the name of a resource that is passed to the program as input. Files, paths, and URLs are resource types that are vulnerable to canonicalization because in each case there are many different ways to represent the same name. File names are also problematic. For example, a single file could be represented as:

c:\temp\somefile.dat
somefile.dat
c:\temp\subdir\..\somefile.dat
c:\  temp\   somefile.dat
..\somefile.dat

Ideally, your code should not accept input file names. If it does, the name should be converted to its canonical form prior to making security decisions, such as whether access should be granted or denied to the specified file.

Countermeasures to address canonicalization issues include:

• Avoid using file names as input where possible and instead use absolute file paths that cannot be changed by the end user.
• Make sure that file names are well formed (if you must accept file names as input) and validate them within the context of your application. For example, check that they are within your application's directory hierarchy.
• Ensure that the character encoding is set correctly to limit how input can be represented. Check that your application's Web.config has set the requestEncoding and responseEncoding attributes on the <globalization> element.

Authentication

Depending on your requirements, there are several available authentication mechanisms to choose from. If they are not correctly chosen and implemented, the authentication mechanism can expose vulnerabilities that attackers can exploit to gain access to your system. The top threats that exploit authentication vulnerabilities include:

• Network eavesdropping
• Brute force attacks
• Dictionary attacks
• Cookie replay attacks
• Credential theft

Network Eavesdropping

If authentication credentials are passed in plaintext from client to server, an attacker armed with rudimentary network monitoring software on a host on the same network can capture traffic and obtain user names and passwords.

Countermeasures to prevent network eavesdropping include:

• Use authentication mechanisms that do not transmit the password over the network such as Kerberos protocol or Windows authentication.
• Make sure passwords are encrypted (if you must transmit passwords over the network) or use an encrypted communication channel, for example with SSL.

Brute Force Attacks

Brute force attacks rely on computational power to crack hashed passwords or other secrets secured with hashing and encryption. To mitigate the risk, use strong passwords. Additionally, use hashed passwords with salt; this slows down the attacker considerably and allows sufficient time for countermeasures to be activated.

Dictionary Attacks

This attack is used to obtain passwords. Most password systems do not store plaintext passwords or encrypted passwords. They avoid encrypted passwords because a compromised key leads to the compromise of all passwords in the data store. Lost keys mean that all passwords are invalidated.

Most user store implementations hold password hashes (or digests). Users are authenticated by re-computing the hash based on the user-supplied password value and comparing it against the hash value stored in the database. If an attacker manages to obtain the list of hashed passwords, a brute force attack can be used to crack the password hashes.

With the dictionary attack, an attacker uses a program to iterate through all of the words in a dictionary (or multiple dictionaries in different languages) and computes the hash for each word. The resultant hash is compared with the value in the data store. Weak passwords such as "Yankees" (a favorite team) or "Mustang" (a favorite car) will be cracked quickly. Stronger passwords such as "?You'LlNevaFiNdMeyePasSWerd!", are less likely to be cracked.

Note   Once the attacker has obtained the list of password hashes, the dictionary attack can be performed offline and does not require interaction with the application.

Countermeasures to prevent dictionary attacks include:

• Use strong passwords that are complex, are not regular words, and contain a mixture of upper case, lower case, numeric, and special characters.
• Store non-reversible password hashes in the user store. Also combine a salt value (a cryptographically strong random number) with the password hash.

For more information about storing password hashes with added salt, see Chapter 14, "Building Secure Data Access."

Cookie Replay Attacks

With this type of attack, the attacker captures the user's authentication cookie using monitoring software and replays it to the application to gain access under a false identity.

Countermeasures to prevent cookie replay include:

• Use an encrypted communication channel provided by SSL whenever an authentication cookie is transmitted.
• Use a cookie timeout to a value that forces authentication after a relatively short time interval. Although this doesn't prevent replay attacks, it reduces the time interval in which the attacker can replay a request without being forced to re-authenticate because the session has timed out.

Credential Theft

If your application implements its own user store containing user account names and passwords, compare its security to the credential stores provided by the platform, for example, a Microsoft Active Directory® directory service or Security Accounts Manager (SAM) user store. Browser history and cache also store user login information for future use. If the terminal is accessed by someone other than the user who logged on, and the same page is hit, the saved login will be available.

Countermeasures to help prevent credential theft include:

• Use and enforce strong passwords.
• Store password verifiers in the form of one way hashes with added salt.
• Enforce account lockout for end-user accounts after a set number of retry attempts.
• To counter the possibility of the browser cache allowing login access, create functionality that either allows the user to choose to not save credentials, or force this functionality as a default policy.

Authorization

Based on user identity and role membership, authorization to a particular resource or service is either allowed or denied. Top threats that exploit authorization vulnerabilities include:

• Elevation of privilege
• Disclosure of confidential data
• Data tampering
• Luring attacks

Elevation of Privilege

When you design an authorization model, you must consider the threat of an attacker trying to elevate privileges to a powerful account such as a member of the local administrators group or the local system account. By doing this, the attacker is able to take complete control over the application and local machine. For example, with classic ASP programming, calling the RevertToSelf API from a component might cause the executing thread to run as the local system account with the most power and privileges on the local machine.

The main countermeasure that you can use to prevent elevation of privilege is to use least privileged process, service, and user accounts.

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.

Countermeasures to prevent disclosure of confidential data include:

• Perform role checks before allowing access to the operations that could potentially reveal sensitive data.
• Use strong ACLs to secure Windows resources.
• Use standard encryption to store sensitive data in configuration files and databases.

Data Tampering

Data tampering refers to the unauthorized modification of data.

Countermeasures to prevent data tampering include:

• Use strong access controls to protect data in persistent stores to ensure that only authorized users can access and modify the data.
• Use role-based security to differentiate between users who can view data and users who can modify data.

Luring Attacks

A luring attack occurs when an entity with few privileges is able to have an entity with more privileges perform an action on its behalf.

To counter the threat, you must restrict access to trusted code with the appropriate authorization. Using .NET Framework code access security helps in this respect by authorizing calling code whenever a secure resource is accessed or a privileged operation is performed.

Configuration Management

Many applications support configuration management interfaces and functionality to allow operators and administrators to change configuration parameters, update Web site content, and to perform routine maintenance. Top configuration management threats include:

• Unauthorized access to administration interfaces
• Unauthorized access to configuration stores
• Retrieval of plaintext configuration secrets
• Lack of individual accountability
• Over-privileged process and service accounts

Unauthorized Access to Administration Interfaces

Administration interfaces are often provided through additional Web pages or separate Web applications that allow administrators, operators, and content developers to managed site content and configuration. Administration interfaces such as these should be available only to restricted and authorized users. Malicious users able to access a configuration management function can potentially deface the Web site, access downstream systems and databases, or take the application out of action altogether by corrupting configuration data.

Countermeasures to prevent unauthorized access to administration interfaces include:

• Minimize the number of administration interfaces.
• Use strong authentication, for example, by using certificates.
• Use strong authorization with multiple gatekeepers.
• Consider supporting only local administration. If remote administration is absolutely essential, use encrypted channels, for example, with VPN technology or SSL, because of the sensitive nature of the data passed over administrative interfaces. To further reduce risk, also consider using IPSec policies to limit remote administration to computers on the internal network.

Unauthorized Access to Configuration Stores

Because of the sensitive nature of the data maintained in configuration stores, you should ensure that the stores are adequately secured.

Countermeasures to protect configuration stores include:

• Configure restricted ACLs on text-based configuration files such as Machine.config and Web.config.
• Keep custom configuration stores outside of the Web space. This removes the potential to download Web server configurations to exploit their vulnerabilities.

Retrieval of Plaintext Configuration Secrets

Restricting access to the configuration store is a must. As an important defense in depth mechanism, you should encrypt sensitive data such as passwords and connection strings. This helps prevent external attackers from obtaining sensitive configuration data. It also prevents rogue administrators and internal employees from obtaining sensitive details such as database connection strings and account credentials that might allow them to gain access to other systems.

Lack of Individual Accountability

Lack of auditing and logging of changes made to configuration information threatens the ability to identify when changes were made and who made those changes. When a breaking change is made either by an honest operator error or by a malicious change to grant privileged access, action must first be taken to correct the change. Then apply preventive measures to prevent breaking changes to be introduced in the same manner. Keep in mind that auditing and logging can be circumvented by a shared account; this applies to both administrative and user/application/service accounts. Administrative accounts must not be shared. User/application/service accounts must be assigned at a level that allows the identification of a single source of access using the account, and that contains any damage to the privileges granted that account.

Over-privileged Application and Service Accounts

If application and service accounts are granted access to change configuration information on the system, they may be manipulated to do so by an attacker. The risk of this threat can be mitigated by adopting a policy of using least privileged service and application accounts. Be wary of granting accounts the ability to modify their own configuration information unless explicitly required by design.

Sensitive Data

Sensitive data is subject to a variety of threats. Attacks that attempt to view or modify sensitive data can target persistent data stores and networks. Top threats to sensitive data include:

• Access to sensitive data in storage
• Network eavesdropping
• Data tampering

Access to Sensitive Data in Storage

You must secure sensitive data in storage to prevent a user — malicious or otherwise — from gaining access to and reading the data.

Countermeasures to protect sensitive data in storage include:

• Use restricted ACLs on the persistent data stores that contain sensitive data.
• Store encrypted data.
• Use identity and role-based authorization to ensure that only the user or users with the appropriate level of authority are allowed access to sensitive data. Use role-based security to differentiate between users who can view data and users who can modify data.

Network Eavesdropping

The HTTP data for Web application travels across networks in plaintext and is subject to network eavesdropping attacks, where an attacker uses network monitoring software to capture and potentially modify sensitive data.

Countermeasures to prevent network eavesdropping and to provide privacy include:

• Encrypt the data.
• Use an encrypted communication channel, for example, SSL.

Data Tampering

Data tampering refers to the unauthorized modification of data, often as it is passed over the network.

One countermeasure to prevent data tampering is to protect sensitive data passed across the network with tamper-resistant protocols such as hashed message authentication codes (HMACs).

An HMAC provides message integrity in the following way:

1. The sender uses a shared secret key to create a hash based on the message payload.
2. The sender transmits the hash along with the message payload.
3. The receiver uses the shared key to recalculate the hash based on the received message payload. The receiver then compares the new hash value with the transmitted hash value. If they are the same, the message cannot have been tampered with.

Session Management

Session management for Web applications is an application layer responsibility. Session security is critical to the overall security of the application.

Top session management threats include:

• Session hijacking
• Session replay
• Man in the middle

Session Hijacking

A session hijacking attack occurs when an attacker uses network monitoring software to capture the authentication token (often a cookie) used to represent a user's session with an application. With the captured cookie, the attacker can spoof the user's session and gain access to the application. The attacker has the same level of privileges as the legitimate user.

Countermeasures to prevent session hijacking include:

• Use SSL to create a secure communication channel and only pass the authentication cookie over an HTTPS connection.
• Implement logout functionality to allow a user to end a session that forces authentication if another session is started.
• Make sure you limit the expiration period on the session cookie if you do not use SSL. Although this does not prevent session hijacking, it reduces the time window available to the attacker.

Session Replay

Session replay occurs when a user's session token is intercepted and submitted by an attacker to bypass the authentication mechanism. For example, if the session token is in plaintext in a cookie or URL, an attacker can sniff it. The attacker then posts a request using the hijacked session token.

Countermeasures to help address the threat of session replay include:

• Re-authenticate when performing critical functions. For example, prior to performing a monetary transfer in a banking application, make the user supply the account password again.
• Expire sessions appropriately, including all cookies and session tokens.
• Create a "do not remember me" option to allow no session data to be stored on the client.

Man in the Middle Attacks

A man in the middle attack occurs when the attacker intercepts messages sent between you and your intended recipient. The attacker then changes your message and sends it to the original recipient. The recipient receives the message, sees that it came from you, and acts on it. When the recipient sends a message back to you, the attacker intercepts it, alters it, and returns it to you. You and your recipient never know that you have been attacked.

Any network request involving client-server communication, including Web requests, Distributed Component Object Model (DCOM) requests, and calls to remote components and Web services, are subject to man in the middle attacks.

Countermeasures to prevent man in the middle attacks include:

• Use cryptography. If you encrypt the data before transmitting it, the attacker can still intercept it but cannot read it or alter it. If the attacker cannot read it, he or she cannot know which parts to alter. If the attacker blindly modifies your encrypted message, then the original recipient is unable to successfully decrypt it and, as a result, knows that it has been tampered with.
• Use Hashed Message Authentication Codes (HMACs). If an attacker alters the message, the recalculation of the HMAC at the recipient fails and the data can be rejected as invalid.

Cryptography

Most applications use cryptography to protect data and to ensure it remains private and unaltered. Top threats surrounding your application's use of cryptography include:

• Poor key generation or key management
• Weak or custom encryption
• Checksum spoofing

Poor Key Generation or Key Management

Attackers can decrypt encrypted data if they have access to the encryption key or can derive the encryption key. Attackers can discover a key if keys are managed poorly or if they were generated in a non-random fashion.

Countermeasures to address the threat of poor key generation and key management include:

• Use built-in encryption routines that include secure key management. Data Protection application programming interface (DPAPI) is an example of an encryption service provided on Windows 2000 and later operating systems where the operating system manages the key.
• Use strong random key generation functions and store the key in a restricted location — for example, in a registry key secured with a restricted ACL — if you use an encryption mechanism that requires you to generate or manage the key.
• Encrypt the encryption key using DPAPI for added security.
• Expire keys regularly.

Weak or Custom Encryption

An encryption algorithm provides no security if the encryption is cracked or is vulnerable to brute force cracking. Custom algorithms are particularly vulnerable if they have not been tested. Instead, use published, well-known encryption algorithms that have withstood years of rigorous attacks and scrutiny.

Countermeasures that address the vulnerabilities of weak or custom encryption include:

• Do not develop your own custom algorithms.
• Use the proven cryptographic services provided by the platform.
• Stay informed about cracked algorithms and the techniques used to crack them.

Checksum Spoofing

Do not rely on hashes to provide data integrity for messages sent over networks. Hashes such as Secure Hash Algorithm (SHA1) and Message Digest compression algorithm (MD5) can be intercepted and changed. Consider the following base 64 encoding UTF-8 message with an appended Message Authentication Code (MAC).

Plaintext: Place 10 orders.
Hash: T0mUNdEQh13IO9oTcaP4FYDX6pU=

If an attacker intercepts the message by monitoring the network, the attacker could update the message and recompute the hash (guessing the algorithm that you used). For example, the message could be changed to:

Plaintext: Place 100 orders.
Hash: oEDuJpv/ZtIU7BXDDNv17EAHeAU=

When recipients process the message, and they run the plaintext ("Place 100 orders") through the hashing algorithm, and then recompute the hash, the hash they calculate will be equal to whatever the attacker computed.

To counter this attack, use a MAC or HMAC. The Message Authentication Code Triple Data Encryption Standard (MACTripleDES) algorithm computes a MAC, and HMACSHA1 computes an HMAC. Both use a key to produce a checksum. With these algorithms, an attacker needs to know the key to generate a checksum that would compute correctly at the receiver.

Parameter Manipulation

Parameter manipulation attacks are a class of attack that relies on the modification of the parameter data sent between the client and Web application. This includes query strings, form fields, cookies, and HTTP headers. Top parameter manipulation threats include:

• Query string manipulation
• Form field manipulation
• Cookie manipulation
• HTTP header manipulation

Query String Manipulation

Users can easily manipulate the query string values passed by HTTP GET from client to server because they are displayed in the browser's URL address bar. If your application relies on query string values to make security decisions, or if the values represent sensitive data such as monetary amounts, the application is vulnerable to attack.

Countermeasures to address the threat of query string manipulation include:

• Avoid using query string parameters that contain sensitive data or data that can influence the security logic on the server. Instead, use a session identifier to identify the client and store sensitive items in the session store on the server.
• Choose HTTP POST instead of GET to submit forms.
• Encrypt query string parameters.

Form Field Manipulation

The values of HTML form fields are sent in plaintext to the server using the HTTP POST protocol. This may include visible and hidden form fields. Form fields of any type can be easily modified and client-side validation routines bypassed. As a result, applications that rely on form field input values to make security decisions on the server are vulnerable to attack.

To counter the threat of form field manipulation, instead of using hidden form fields, use session identifiers to reference state maintained in the state store on the server.

Cookie Manipulation

Cookies are susceptible to modification by the client. This is true of both persistent and memory-resident cookies. A number of tools are available to help an attacker modify the contents of a memory-resident cookie. Cookie manipulation is the attack that refers to the modification of a cookie, usually to gain unauthorized access to a Web site.

While SSL protects cookies over the network, it does not prevent them from being modified on the client computer. To counter the threat of cookie manipulation, encrypt and use an HMAC with the cookie.

HTTP Header Manipulation

HTTP headers pass information between the client and the server. The client constructs request headers while the server constructs response headers. If your application relies on request headers to make a decision, your application is vulnerable to attack.

Do not base your security decisions on HTTP headers. For example, do not trust the HTTP Referer to determine where a client came from because this is easily falsified.

Exception Management

Exceptions that are allowed to propagate to the client can reveal internal implementation details that make no sense to the end user but are useful to attackers. Applications that do not use exception handling or implement it poorly are also subject to denial of service attacks. Top exception handling threats include:

• Attacker reveals implementation details
• Denial of service

Attacker Reveals Implementation Details

One of the important features of the .NET Framework is that it provides rich exception details that are invaluable to developers. If the same information is allowed to fall into the hands of an attacker, it can greatly help the attacker exploit potential vulnerabilities and plan future attacks. The type of information that could be returned includes platform versions, server names, SQL command strings, and database connection strings.

Countermeasures to help prevent internal implementation details from being revealed to the client include:

• Use exception handling throughout your application's code base.
• Handle and log exceptions that are allowed to propagate to the application boundary.
• Return generic, harmless error messages to the client.

Denial of Service

Attackers will probe a Web application, usually by passing deliberately malformed input. They often have two goals in mind. The first is to cause exceptions that reveal useful information and the second is to crash the Web application process. This can occur if exceptions are not properly caught and handled.

Countermeasures to help prevent application-level denial of service include:

• Thoroughly validate all input data at the server.
• Use exception handling throughout your application's code base.

Auditing and Logging

Auditing and logging should be used to help detect suspicious activity such as footprinting or possible password cracking attempts before an exploit actually occurs. It can also help deal with the threat of repudiation. It is 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 transaction.

Top auditing and logging related threats include:

• User denies performing an operation
• Attackers exploit an application without leaving a trace
• Attackers cover their tracks

User Denies Performing an Operation

The issue of repudiation is concerned with a user denying that he or she performed an action or initiated a transaction. You need defense mechanisms in place to ensure that all user activity can be tracked and recorded.

Countermeasures to help prevent repudiation threats include:

• Audit and log activity on the Web server and database server, and on the application server as well, if you use one.
• Log key events such as transactions and login and logout events.
• Do not use shared accounts since the original source cannot be determined.

Attackers Exploit an Application Without Leaving a Trace

System and application-level auditing is required to ensure that suspicious activity does not go undetected.

Countermeasures to detect suspicious activity include:

• Log critical application level operations.
• Use platform-level auditing to audit login and logout events, access to the file system, and failed object access attempts.
• Back up log files and regularly analyze them for signs of suspicious activity.

Attackers Cover Their Tracks

Your log files must be well-protected to ensure that attackers are not able to cover their tracks.

Countermeasures to help prevent attackers from covering their tracks include:

• Secure log files by using restricted ACLs.
• Relocate system log files away from their default locations.

Summary

By being aware of the typical approach used by attackers as well as their goals, you can be more effective when applying countermeasures. It also helps to use a goal-based approach when considering and identifying threats, and to use the STRIDE model to categorize threats based on the goals of the attacker, for example, to spoof identity, tamper with data, deny service, elevate privileges, and so on. This allows you to focus more on the general approaches that should be used for risk mitigation, rather than focusing on the identification of every possible attack, which can be a time-consuming and potentially fruitless exercise.

This chapter has shown you the top threats that have the potential to compromise your network, host infrastructure, and applications. Knowledge of these threats, together with the appropriate countermeasures, provides essential information for the threat modeling process It enables you to identify the threats that are specific to your particular scenario and prioritize them based on the degree of risk they pose to your system. This structured process for identifying and prioritizing threats is referred to as threat modeling. For more information, see Chapter 3, "Threat Modeling."

Additional Resources

For further related reading, see the following resources:

• For more information about network threats and countermeasures, see Chapter 15, "Securing Your Network."
• For more information about host threats and countermeasures, see Chapter 16, "Securing Your Web Server," Chapter 17, "Securing Your Application Server," Chapter 18, "Securing Your Database Server," and Chapter 19, "Securing Your ASP.NET Application."
• For more information about addressing the application level threats presented in this chapter, see the Building chapters in Part III, "Building Secure Web Applications" of this guide.
• Michael Howard and David LeBlanc, Writing Secure Code 2nd Edition. Microsoft Press, Redmond, WA, 2002
• For more information about tracking and fixing buffer overruns, see the MSDN article, "Fix Those Buffer Overruns," at [Content link no longer available, original URL:"https://msdn.microsoft.com/library/en-us/dncode/html/secure05202002.asp"]

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.