Share via

Chapter 1- Web Application Security Fundamentals


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.

patterns & practices Developer Center

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

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 introduces Web application security, explains common security terminology and presents a set of proven security principles upon which many of the recommendations throughout this guide are based. It presents an overview of the security process and explains why a holistic approach to security that covers multiple layers including the network, host and application, is required to achieve the goal of hack-resilient Web applications. This chapter also introduces and defines host configuration categories and application vulnerability categories, which are used throughout the remainder of this guide.


We Are Secure -- We Have a Firewall
What Do We Mean By Security?
Threats, Vulnerabilities, and Attacks Defined
How Do You Build a Secure Web Application?
Secure Your Network, Host, and Application
Securing Your Network
Securing Your Host
Securing Your Application
Security Principles
Additional Resources

When you hear talk about Web application security, there is a tendency to immediately think about attackers defacing Web sites, stealing credit card numbers, and bombarding Web sites with denial of service attacks. You might also think about viruses, Trojan horses, and worms. These are the types of problems that receive the most press because they represent some of the most significant threats faced by today's Web applications.

These are only some of the problems. Other significant problems are frequently overlooked. Internal threats posed by rogue administrators, disgruntled employees, and the casual user who mistakenly stumbles across sensitive data pose significant risk. The biggest problem of all may be ignorance.

The solution to Web application security is more than technology. It is an ongoing process involving people and practices.

We Are Secure — We Have a Firewall

This is a common misconception; it depends on the threat. For example, a firewall may not detect malicious input sent to your Web application. Also, consider the scenario where a rogue administrator has direct access to your application.

Do firewalls have their place? Of course they do. Firewalls are great at blocking ports. Some firewall applications examine communications and can provide very advanced protection. Firewalls are an integral part of your security, but they are not a complete solution by themselves.

The same holds true for Secure Sockets Layer (SSL). SSL is great at encrypting traffic over the network. However, it does not validate your application's input or protect you from a poorly configured server.

What Do We Mean By Security?

Security is fundamentally about protecting assets. Assets may be tangible items, such as a Web page or your customer database — or they may be less tangible, such as your company's reputation.

Security is a path, not a destination. As you analyze your infrastructure and applications, you identify potential threats and understand that each threat presents a degree of risk. Security is about risk management and implementing effective countermeasures.

The Foundations of Security

Security relies on the following elements:

  • Authentication

    Authentication addresses the question: who are you? It is the process of uniquely identifying the clients of your applications and services. These might be end users, other services, processes, or computers. In security parlance, authenticated clients are referred to as principals.

  • Authorization

    Authorization addresses the question: what can you do? It is the process that governs the resources and operations that the authenticated client is permitted to access. Resources include files, databases, tables, rows, and so on, together with system-level resources such as registry keys and configuration data. Operations include performing transactions such as purchasing a product, transferring money from one account to another, or increasing a customer's credit rating.

  • Auditing

    Effective auditing and logging is the key to non-repudiation. Non-repudiation guarantees that a user cannot deny performing an operation or initiating a transaction. For example, in an e-commerce system, non-repudiation mechanisms are required to make sure that a consumer cannot deny ordering 100 copies of a particular book.

  • Confidentiality

    Confidentiality, also referred to as privacy, is the process of making sure that data remains private and confidential, and that it cannot be viewed by unauthorized users or eavesdroppers who monitor the flow of traffic across a network. Encryption is frequently used to enforce confidentiality. Access control lists (ACLs) are another means of enforcing confidentiality.

  • Integrity

    Integrity is the guarantee that data is protected from accidental or deliberate (malicious) modification. Like privacy, integrity is a key concern, particularly for data passed across networks. Integrity for data in transit is typically provided by using hashing techniques and message authentication codes.

  • Availability

    From a security perspective, availability means that systems remain available for legitimate users. The goal for many attackers with denial of service attacks is to crash an application or to make sure that it is sufficiently overwhelmed so that other users cannot access the application.

Threats, Vulnerabilities, and Attacks Defined

A threat is any potential occurrence, malicious or otherwise, that could harm an asset. In other words, a threat is any bad thing that can happen to your assets.

A vulnerability is a weakness that makes a threat possible. This may be because of poor design, configuration mistakes, or inappropriate and insecure coding techniques. Weak input validation is an example of an application layer vulnerability, which can result in input attacks.

An attack is an action that exploits a vulnerability or enacts a threat. Examples of attacks include sending malicious input to an application or flooding a network in an attempt to deny service.

To summarize, a threat is a potential event that can adversely affect an asset, whereas a successful attack exploits vulnerabilities in your system.

How Do You Build a Secure Web Application?

It is not possible to design and build a secure Web application until you know your threats. An increasingly important discipline and one that is recommended to form part of your application's design phase is threat modeling. The purpose of threat modeling is to analyze your application's architecture and design and identify potentially vulnerable areas that may allow a user, perhaps mistakenly, or an attacker with malicious intent, to compromise your system's security.

After you know your threats, design with security in mind by applying timeworn and proven security principles. As developers, you must follow secure coding techniques to develop secure, robust, and hack-resilient solutions. The design and development of application layer software must be supported by a secure network, host, and application configuration on the servers where the application software is to be deployed.

Secure Your Network, Host, and Application

"A vulnerability in a network will allow a malicious user to exploit a host or an application. A vulnerability in a host will allow a malicious user to exploit a network or an application. A vulnerability in an application will allow a malicious user to exploit a network or a host."

Carlos Lyons, Corporate Security, Microsoft

To build secure Web applications, a holistic approach to application security is required and security must be applied at all three layers. This approach is shown in Figure 1.1.


Figure 1.1

A holistic approach to security

Securing Your Network

A secure Web application relies upon a secure network infrastructure. The network infrastructure consists of routers, firewalls, and switches. The role of the secure network is not only to protect itself from TCP/IP-based attacks, but also to implement countermeasures such as secure administrative interfaces and strong passwords. The secure network is also responsible for ensuring the integrity of the traffic that it is forwarding. If you know at the network layer about ports, protocols, or communication that may be harmful, counter those potential threats at that layer.

Network Component Categories

This guide divides network security into separate component categories as shown in Table 1.1.

Table 1.1: Network Component Categories

Component Description
Router Routers are your outermost network ring. They channel packets to ports and protocols that your application needs. Common TCP/IP vulnerabilities are blocked at this ring.
Firewall The firewall blocks those protocols and ports that the application does not use. Additionally, firewalls enforce secure network traffic by providing application-specific filtering to block malicious communications.
Switch Switches are used to separate network segments. They are frequently overlooked or overtrusted.

Securing Your Host

When you secure a host, whether it is your Web server, application server, or database server, this guide breaks down the various secure configuration settings into separate categories. With this approach, you can focus on a specific category and review security, or apply security settings that relate to that specific category. When you install new software on your servers with this approach, you can evaluate the impact on your security settings. For example, you may address the following questions: Does the software create new accounts? Does the software add any default services? Who are the services running as? Are any new script mappings created?

Host Configuration Categories

Figure 1.2 shows the various categories used in Part IV of this guide, "Securing Your Network, Host, and Application."


Figure 1.2

Host security categories

With the framework that these categories provide, you can systematically evaluate or secure your server's configuration instead of applying security settings on an ad-hoc basis. The rationale for these particular categories is shown in Table 1.2.

Table 1.2: Rationale for Host Configuration Categories

Category Description
Patches and Updates Many top security risks exist because of vulnerabilities that are widely published and well known. When new vulnerabilities are discovered, exploit code is frequently posted on Internet bulletin boards within hours of the first successful attack. Patching and updating your server's software is the first step toward securing the server. If you do not patch and update your server, you are providing more potential opportunities for attackers and malicious code.
Services The service set is determined by the server role and the applications it hosts. By disabling unnecessary and unused services, you quickly and easily reduce the attack surface area.
Protocols To reduce the attack surface area and the avenues open to attackers, disable any unnecessary or unused network protocols.
Accounts The number of accounts accessible from a server should be restricted to the necessary set of service and user accounts. Additionally, you should enforce appropriate account policies, such as mandating strong passwords.
Files and Directories Files and directories should be secured with restricted NTFS permissions that allow access only to the necessary Microsoft Windows service and user accounts.
Shares All unnecessary file shares, including the default administration shares if they are not required, should be removed. Secure the remaining shares with restricted NTFS permissions.
Ports Services running on a server listen on specific ports to serve incoming requests. Open ports on a server must be known and audited regularly to make sure that an insecure service is not listening and available for communication. In the worst-case scenario, a listening port is detected that was not opened by an administrator.
Auditing and Logging Auditing is a vital aid in identifying intruders or attacks in progress. Logging proves particularly useful as forensic information when determining how an intrusion or attack was performed.
Registry Many security related settings are maintained in the registry. Secure the registry itself by applying restricted Windows ACLs and blocking remote registry administration.

Securing Your Application

If you were to review and analyze the top security issues across many Web applications, you would see a pattern of problems. By organizing these problems into categories, you can systematically tackle them. These problem areas are your application's vulnerability categories.

Application Vulnerability Categories

What better way to measure the security of a system than to evaluate its potential weak points? To measure the security resilience of your application, you can evaluate the application vulnerability categories. When you do this, you can create application security profiles, and then use these profiles to determine the security strength of an application.

These categories are used as a framework throughout this guide. Because the categories represent the areas where security mistakes are most frequently made, they are used to illustrate guidance for application developers and architects. The categories are also used as a framework when evaluating the security of a Web application. With these categories, you can focus consistently on the key design and implementation choices that most affect your application's security. Application vulnerability categories are described in Table 1.3.

Table 1.3: Application Vulnerability Categories

Category Description
Input Validation How do you know that the input that your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing.
Authentication "Who are you?" Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password.
Authorization "What can you do?" Authorization is how your application provides access controls for resources and operations.
Configuration Management Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Configuration management refers to how your application handles these operational issues.
Sensitive Data Sensitive data refers to how your application handles any data that must be protected either in memory, over the wire, or in persistent stores.
Session Management A session refers to a series of related interactions between a user and your Web application. Session management refers to how your application handles and protects these interactions.
Cryptography How are you keeping secrets, secret (confidentiality)? How are you tamperproofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity.
Parameter Manipulation Form fields, query string arguments, and cookie values are frequently used as parameters for your application. Parameter manipulation refers to both how your application safeguards tampering of these values and how your application processes input parameters.
Exception Management When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?
Auditing and Logging Who did what and when? Auditing and logging refer to how your application records security-related events.

Security Principles

Recommendations used throughout this guide are based on security principles that have proven themselves over time. Security, like many aspects of software engineering, lends itself to a principle-based approach, where core principles can be applied regardless of implementation technology or application scenario. The major security principles used throughout this guide are summarized in Table 1.4.

Table 1.4: Summary of Core Security Principles

Principle Concepts
Compartmentalize Reduce the surface area of attack. Ask yourself how you will contain a problem. If an attacker takes over your application, what resources can he or she access? Can an attacker access network resources? How are you restricting potential damage? Firewalls, least privileged accounts, and least privileged code are examples of compartmentalizing.
Use least privilege By running processes using accounts with minimal privileges and access rights, you significantly reduce the capabilities of an attacker if the attacker manages to compromise security and run code.
Apply defense in depth Use multiple gatekeepers to keep attackers at bay. Defense in depth means you do not rely on a single layer of security, or you consider that one of your layers may be bypassed or compromised.
Do not trust user input Your application's user input is the attacker's primary weapon when targeting your application. Assume all input is malicious until proven otherwise, and apply a defense in depth strategy to input validation, taking particular precautions to make sure that input is validated whenever a trust boundary in your application is crossed.
Check at the gate Authenticate and authorize callers early — at the first gate.
Fail securely If an application fails, do not leave sensitive data accessible. Return friendly errors to end users that do not expose internal system details. Do not include details that may help an attacker exploit vulnerabilities in your application.
Secure the weakest link Is there a vulnerability at the network layer that an attacker can exploit? What about the host? Is your application secure? Any weak link in the chain is an opportunity for breached security.
Create secure defaults Is the default account set up with least privilege? Is the default account disabled by default and then explicitly enabled when required? Does the configuration use a password in plaintext? When an error occurs, does sensitive information leak back to the client to be used potentially against the system?
Reduce your attack surface If you do not use it, remove it or disable it. Reduce the surface area of attack by disabling or removing unused services, protocols, and functionality. Does your server need all those services and ports? Does your application need all those features?


An ever-increasing number of attacks target your application. They pass straight through your environment's front door using HTTP. The conventional fortress model and the reliance on firewall and host defenses are not sufficient when used in isolation. Securing your application involves applying security at three layers: the network layer, host layer, and the application layer. A secure network and host platform infrastructure is a must. Additionally, your applications must be designed and built using secure design and development guidelines following timeworn security principles.

Additional Resources

For more information, see the following resources:

  • For more information on the Open Hack Web application, see the MSDN article, "Open Hack: Building and Configuring More Secure Web Sites," at
  • This is Volume II in a series dedicated to helping customers improve Web application security. For more information on designing and implementing authentication, authorization, and secure communication across the tiers of a distributed Web application, see "Microsoft patterns & practices Volume I, Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication" at

patterns & practices Developer Center

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.