Chapter 1 – Security Fundamentals for Web Services
- J.D. Meier, Carlos Farre, Jason Taylor,
Prashant Bansode, Steve Gregersen, Madhu Sundararajan, Rob Boucher
- Learn the key security requirements
- Understand the difference between threats, attacks, vulnerabilities and countermeasures
- Learn the key distinctions for Service-Oriented Architecture (SOA)
- Learn the Web Services Security Frame
- Learn the key principles and patterns for building secure services
Building secure services includes knowing your threats, making effective trade-offs, and integrating security throughout your software development life cycle. One of the most effective ways for dealing with security is to leverage proven principles, patterns,
and practices. The key is to know which principles, patterns, and practices are effective for your situation. Techniques such as threat modeling and security inspections can you help you shape your software to meet your security objectives.
What Do We Mean By Security?
Security is fundamentally about protecting assets. Assets may be tangible items, such as operations 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.
One of the most important concepts in security is that effective security is a combination of people, process, and technology.
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
When thinking about security, it’s helpful to think in terms of assets, threats, vulnerabilities, and attacks.
- Asset. An asset is something related to your application that is worth protecting. Sensitive data, intellectual property, and access to critical operations are all assets. For example, user credit card numbers are an asset worth protecting in your
- Threat. 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.
- Vulnerability. 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.
- Attack. An attack is an action that exploits 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.
What Is a Service
A service is a public interface that provides access to a unit of functionality. Services literally provide some programmatic ‘service’ to the caller who consumes them. Services are loosely coupled and can be combined from within a client or within other services
to provide more complex functionality. Services are distributable and can be accessed from a remote machine as well as from the local machine on which they are running. Services are message oriented, meaning that service interfaces are defined by a WSDL file
and operations are called using xml-based message schemas that are passed over a transport. Services support a heterogeneous environment by focusing interoperability at the message/interface definition. If components can understand the message and interface
definition they can use the service regardless of their base technology.
Common Services Scenarios
Services are, by nature, flexible and can be used in a wide variety of scenarios and combinations. The following are key scenarios that we will return to many times over the course of this guide:
- Service exposed over the Internet. This scenario describes a service that is consumed by web applications or smart client applications over the Internet. Authentication and authorization decisions have to be made based upon Internet trust boundaries
and credentials options. For example, username authentication is more likely in the Internet scenario than the intranet scenario. This scenario includes business-to-business as well as consumer focused services. For example, a web site that allows scheduling
of your family’s doctor visits could be included in this scenario.
- Service exposed over the Intranet. This scenario describes a service that is consumed by web applications or smart client applications over the intranet. Authentication and authorization decisions have to be made based upon intranet trust boundaries
and credentials options. For example, Active Directory user store is more likely in the intranet scenario than in the Internet scenario. For example, an enterprise web-mail application could be included in this scenario.
- Service exposed on the local machine. This scenario describes a service that is consumed by an application on the local machine. Transport and message protection decisions have to be made based upon local machine trust boundaries and users.
- Mixed scenario. This scenario describes a service that is consumed by multiple applications over the Internet, the intranet and/or the local machine. For example a line-of-business application that is consumed internally by a thick client application
and over the Internet by a web application could be included in this scenario.
Service Oriented Architecture (SOA)
Service Oriented Architecture (SOA) is architecture of loosely coupled components that can be distributed across platform, technology and physical topology. Service components can be combined to provide a business process or provide more complex services for
a client application. Services are the preferred communication technique across application boundaries, including platform, deployment, and trust boundaries.
The key attributes of service oriented architecture are:
- Interoperable. Components can be interoperable across platform and technology boundaries.
- Componentized. Services are exposed as autonomous components that can be versioned and managed independently.
- Composable. Services can be composed by an application to perform more complex operations or to enact a business process.
- Message-based interfaces. Interfaces are defined by message contracts and schemas. Operation calls and parameters are passed in XML message envelopes.
- Distributable. Service components can be consumed from the same machine or can be distributed to remote machines. The service interface and logic is independent of the transport and protocol used to access the service.
- Discoverable. Services publish their metadata as WSDL so that client applications can discover the interfaces, schemas, and generate a client-side proxy to consume the service.
You can further define the SOA attributes by a set of four SOA tenets. Don Box was the first to provide this set of design tenets that govern a service-oriented architecture:
- Boundaries are Explicit. Operations are called over well defined boundaries passing explicitly defined messages.
- Services are Autonomous. Each service is maintained, developed, deployed and versioned autonomously.
- Services share schema and contract, not class. Services share contracts and schemas to communicate
- Compatibility is based upon policy. Policy in this case means definition of transport, protocol, security, etc.
Service-Orientation vs. Object Orientation
Services are the preferred communication technique to use across application boundaries, including platform, deployment, and trust boundaries. If you are building a distributed application, consider using a service oriented approach. Although object orientation
provides a pure view of what a system should look like and is effective for producing logical models, an object-based approach can fail to consider real-world factors, such as physical distribution, trust boundaries, and network communication, as well as nonfunctional
requirements, such as performance and security.
|Assumes a homogeneous platform and execution environment.
||Assumes a heterogeneous platform and execution environment.
|Shares types, not schemas.
||Shares schemas, not types.
|Assumes cheap, transparent communication.
||Assumes variable cost, explicit communication.
|Objects are linked: object identity and lifetime are maintained by the infrastructure.
||Services are autonomous: security and failure isolation are a must.
|Typically requires synchronized deployment of both client and server.
||Allows continuous, separate deployment of client and server.
|Is easy to conceptualize and thus provides a natural model to follow.
||Builds on ideas from component software and distributed objects. Dominant theme is to manage/reduce sharing between services.
|Provides no explicit guidelines for state management and ownership.
||Owns and maintains state or uses the reference state.
|Assumes a predictable sequence, timeframe, and outcome of invocations.
||Assumes message-oriented, potentially asynchronous, and long-running communications.
|Goal is to transparently use functions and types remotely.
||Goal is to provide inter-service isolation and wire interoperability based on standards.
Common application boundaries include platform, deployment, trust, and evolution. (Evolution refers to whether or not you develop and upgrade applications together.) When you evaluate architecture and design decisions that affect your application boundaries,
consider the following:
- Objects and remote procedure calls (RPC) are appropriate within boundaries.
- Services are appropriate across and within boundaries.
Enterprise SOA vs. Application SOA
Because SOA is an architectural style, it can be helpful to think in terms of SOA in terms of two different scopes. For the purposes of this guide, we factor SOA in terms of individual application scenarios and larger Enterprise scenarios.
At the enterprise level, you consider SOA from the standpoint of your Enterprise architecture. This is where your Enterprise architects come into play. At enterprise-level SOA, these are some of your key considerations:
- How can you compose application services to create a business process?
- What is your portfolio of capabilities that are candidates for services?
- How can you push common application features to a common services infrastructure?
- How can you provide common services across your portfolio of applications?
- How can you connect your heterogeneous systems through common services?
- How can you provide common security infrastructure for your services?
At the application level, you consider SOA from the standpoint of your application's architecture and architecture style. This is where your application architects come into play. At application-level SOA, these are some of the key considerations:
- How can you design, create and consume services within your application?
- How can you leverage service-oriented approaches within your application's architecture?
- How can you design for effective message-oriented communication?
This guides focuses on application-level SOA.
SOA Security in Practice
Effective SOA security in practice includes the following:
- Coordinating people, process, and technology.
- Integrating and leveraging various levels of standards (general security standards, XML security standards, and Web Services security standards.)
- Integrating and leveraging various user stores and role stores.
- Making trade-offs between user experience, technical, and business perspectives.
WS-Security Standards / Web Services Security Concepts
The WS-* architecture is a set of standards-based protocols designed to secure web service communication. The ws-* security standards include:
- WS-Policy. WS-Policy allows web services to define policy requirements for endpoints. These requirements include privacy rules, encryption rules, and security tokens.
- WS-Security. WS-Security allows web services to apply security to SOAP messages through encryption and integrity checks on all or part of the message.
- WS-Trust. WS-Trust allows web services to use security tokens to establish trust in a brokered security environment.
- WS-SecureConversation. WS-Secure conversation builds on top of WS-Policy, WS-Security and WS-Trust to enable secure communications between client and service.
- WS-ReliableMessaging. WS-Reliable messaging allows web services and clients to trust that when a message is sent it will be delivered to the intended party.
- WS-AtomicTransactions. WS-AtomicTransactions allows transaction-based web services in which transactions can be rolled back in the event of a failure.
How Do You Build Secure Services?
The keys to building secure services include:
- Identify your security objectives. This includes identifying your security requirements.
- Know your threats. Know which threats are relevant for your scenarios and context. Threat modeling is an effective technique for helping you identify relevant threats and vulnerabilities. Your objectives will help you prioritize your threats and
vulnerabilities. From the threat model, developers address vulnerabilities, and testers verify that the developers closed the issues.
- Apply proven principles, patterns, and practices. Principles, patterns, and practices are a good starting point. By using proven principles, patterns, and practices, you can eliminate classes of security problems. You can also leverage lessons learned.
Patterns are effectively reusable solutions and typically encapsulate underlying principles. While principles, patterns, and practices are a good starting point, you should never blindly adopt them. You need to evaluate whether they make sense for your scenario.
- Apply effective security engineering throughout the life cycle. You should consider security throughout your application life cycle. You should start with security objectives. Threat modeling will help shape your design and make key trade-offs. Security
design, code, and deployment inspections, along with testing, will improve your overall security posture.
patterns & practices Security Engineering
The patterns & practices Security Engineering approach includes specific security-related activities that help you meet your application security objectives.
Summary of Key Security Engineering Activities
This patterns & practices Security Engineering approach extends these proven core activities to create security specific activities. These activities include:
- Security Objectives. Setting objectives helps you scope and prioritize your work by setting boundaries and constraints. Setting security objectives helps you identify where to start, how to proceed, and when you are done.
- Threat Modeling. Threat modeling is an engineering technique that can help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application's design,
meet your company's security objectives, and reduce risk.
- Security Design Guidelines. Creating design guidelines is a common practice at the start of an application project to guide development and share knowledge across the team. Effective design guidelines for security organize security principles, practices,
and patterns by actionable categories.
- Security Design Inspection. Security design inspections are an effective way to identify problems in your application design. By using pattern-based categories and a question-driven approach, you simplify evaluating your design against root cause
- Security Code Inspection. Many security defects are found during code reviews. Analyzing code for security defects includes knowing what to look for and how to look for it. Security code inspections optimize inspecting code for common security issues.
- Security Testing. Use a risk-based approach and use the output from the threat modeling activity to help establish the scope of your testing activities and define your test plans.
- Security Deployment Inspection. When you deploy your application during your build process or staging process, you have an opportunity to evaluate runtime characteristics of your application in the context of your infrastructure. Deployment reviews
for security focus on evaluating your security design and configuration of your application, host, and network.
For more information on security engineering, see patterns & practices Security Engineering Explained -
Web Services Security Principles
Recommendations made throughout this guide are based upon a core set of security principles. These principles have proven effective across many different technologies and scenarios including web services in service oriented architecture. Use this list to apply
a principle-based approach to web service security when building your WCF application.
|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.
|Check at the gate
||Authenticate and authorize callers early — at the first gate.
||Isolate and contain a problem. Apply the principle of separation of concerns. If an attacker takes over your application, what resources can they access? Can attacker access network resources? How are you restricting potential damage? Firewalls, least privileged
accounts, and least privileged code are examples of compartmentalizing.
|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?
|Do not trust user input
||Keep user input out of the control path. 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. You need to validate input at both entry points and exit points in your application.
|Establish trust boundaries
||Trust boundaries indicate where trust levels change. You can think of trust from the perspective of confidentiality and integrity. For example, a change in access control levels in your application where a specific role or privilege level is required to
access a resource or operation would be a change in trust level. Another example would be at an entry point in your application where you might not fully trust the data passed to the entry point. Identify trust boundaries from a data flow perspective. For
each subsystem, consider whether the upstream data flow or user input is trusted, and if it is not, consider how the data flow and input can be authenticated and authorized. Knowing which entry points exist between trust boundaries allows you to focus your
threat identification on these key entry points. For example, you are likely to have to perform more validation on data passed through an entry point at a trust boundary.
||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 attacker exploit vulnerabilities in your application.
|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?
|Secure the weakest link
||Is there 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.
|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.
Web Services Security Frame
The following key security concepts provide a frame for thinking about security when designing and architecting services. This helps you turn core security features such as authentication, authorization, auditing, confidentiality, integrity, and availability
|Auditing and Logging
||Auditing and logging refers to how security-related events are recorded, monitored, and audited.
||Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password.
||Authorization is how your service provides access controls for resources and operations.
||Configuration management refers to how your service handles database connections, administration and other configuration settings.
||Exception management refers to how you handle exceptions within your application, including fault contracts.
||Impersonation and delegation refers to how your service impersonates users and passes identity information downstream for authorization purposes.
||Message encryption refers to protecting a message by converting the contents to cipher-text using cryptographic methods.
|Message Replay Detection
||Message replay detection refers to identifying and rejecting messages that are re-submitted.
||Message signing refers to signing a message with a digital signature using cryptographic methods, to confirm the source of the message and detect if the contents have been tampered with (i.e. authentication and integrity of the message.)
||Message validation refers to how you verify the message payload against schema, as well as message size, content and character sets. This includes how your service filters, scrubs and rejects input and output before additional processing. Input and output
includes input from clients consuming the service as well as file-system input, as well as input from network resources, such as databases. Output typically includes the return values from your service or disk / database writes among others.
||Sensitive data includes data integrity and confidentiality of your user and application data that you need to protect. This includes how you protect sensitive data from being stolen from memory, from configuration files or when transmitted over the network.
||A session refers to a series of related interactions between a client and your service.
Using the Web Services Security Frame
The web services security frame serves as a foundation for the rest of this guide. Guidelines, checklists and other guidance are all organized around the categories represented in this frame. You can use this frame to help wrap your mind around WCF security
and better organize the key decisions you need to make when considering security for your application. Through practice and experience we’ve learned that the frame is most useful when combined with a question-driven approach to security. This approach will
help you transition from security understanding to actionable steps you can take to improve the security stance of your application.
|Auditing and Logging
||What events are important for the security of your application? In the event of an attack, what trail of evidence would you want left behind for your investigation? What user management or sensitive business operations do you want to keep track of?
||What credentials will your users present to your service? From what types of clients and locations (Internet vs. intranet) will they be calling from? How do you want to store user account information? Do you want to map authentication to pre-existing Windows
accounts in your domain?
||What roles will be defined for your service? What operations in your service should require explicit authorization? Do you want to authorize the original caller in your service, before your service, or in the business layers called by your service? Do you
need to use the original caller to access resources on the backend? Where do you want to store roles information? Do you already have roles defined, such as Windows groups, that you want your service to interact with
||Under what security context does your application run? Which databases does it connect to and under what security context? How is your application administered? What settings are sensitive and should be secured?
||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?
||What tiers and layers of your application need access to the original caller’s identity and credentials? Do you need to flow the original caller to backend resources? Do you need to authorize the original caller at the service-level or in a down-stream
component? Do you need to access the database using the original caller’s security context? Which operations in your service will need to use impersonation to flow the original caller’s identity?
||Is there sensitive data transmitted in your messages that needs to be protected from exposure to an attacker?
|Message Replay Detection
||How do you protect a service from an attacker who replays an intercepted message?
||Is it important that the message source can be verified and that the contents have not been modified?
||How will you validate incoming SOAP messages on your service? How will you validate input parameters on your service? How will you validate information that is returned to your client? How will you validate data that comes from other sources such as your
database or the file system? How will you make your outbound data safe?
||How does your application handle sensitive data? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores. How are you keeping secrets (confidentiality)? How are you
tamper-proofing 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.
||How does your application handle and protect client sessions?
Web Services Security Patterns
The following Web services security patterns from the patterns & practicesWeb Services Security guide (http://msdn.microsoft.com/en-us/library/aa480545.aspx
) are helpful for addressing
various security concerns, such as authentication, authorization, etc.
- Brokered Authentication
- Brokered Authentication: Kerberos
- Brokered Authentication: X509 PKI
- Brokered Authentication: STS
- Data Confidentiality
- Data Origin Authentication
- Direct Authentication
- Exception Shielding
- Message Replay Detection
- Message Validator
- Perimeter Service Router
- Protocol Transition with Constrained Delegation
- Trusted Subsystem
Web Services Security Patterns Organized By the Web Services Security Frame
This is a summary table of the Web Services Security patterns organized by the Web Services Security Frame
||The Web service acts as an authentication service to validate credentials from the client. The credentials, which include proof-of-possession that is based on shared secrets, are verified against an identity store.
||The Web service validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then
present credentials, including the security token, to the Web service.
|Brokered Authentication: Kerberos
||Use the Kerberos protocol to broker authentication between clients and Web services.
|Brokered Authentication: X509 PKI
||Use brokered authentication with X.509 certificates issued by a certificate authority (CA) in a public key infrastructure (PKI) to verify the credentials presented by the requesting application.
|Brokered Authentication: STS
||Use brokered authentication with a security token issued by a Security Token Service (STS). The STS is trusted by both the client and the Web service to provide interoperable security tokens.
|Protocol Transition with Constrained Delegation
||Use the Kerberos protocol extensions in Windows Server. The extensions require the user ID but not the password. You still need to establish trust between the client application and the Web service; however, the application is not required to store or send
||The Web service acts as a trusted subsystem to access additional resources. It uses its own credentials instead of the user's credentials to access the resource.
||Sanitize unsafe exceptions by replacing them with exceptions that are safe by design. Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive
information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service's inner workings.
||Use encryption to protect sensitive data that is contained in a message. Unencrypted data, which is known as plaintext, is converted to encrypted data, which is known as cipher-text. Data is encrypted with an algorithm and a cryptographic key. Cipher-text
is then converted back to plaintext at its destination.
|Message Replay Detection
|Message Replay Detection
||Cache an identifier for incoming messages, and use message replay detection to identify and reject messages that match an entry in the replay detection cache.
|Data Origin Authentication
||Use data origin authentication, which enables the recipient to verify that messages have not been tampered with in transit (data integrity) and that they originate from the expected sender (authenticity).
||The message validation logic enforces a well-defined policy that specifies which parts of a request message are required for the service to successfully process it. It validates the XML message payloads against an XML schema (XSD) to ensure that they are
well-formed and consistent with what the service expects to process. The validation logic also measures the messages against certain criteria by examining the message size, the message content, and the character sets that are used. Any message that does not
meet the criteria is rejected.
|Perimeter Service Router
||Design a Web service intermediary that acts as a perimeter service router. The perimeter service router provides an external interface on the perimeter network for internal Web services. It accepts messages from external applications and routes them to
the appropriate Web service on the private network.
The foundations of WCF security include authentication, authorization, auditing, confidentiality, integrity, and availability. When you think about security in your service, you should first understand the distinctions between threats, attacks, vulnerabilities
and countermeasures. To build secure services you will identify your security objectives, identify your threats and vulnerabilities, apply principles, patterns, and practices and use security engineering techniques throughout your application life cycle. By
using the Web Services Security Frame, you can better organize and use your security knowledge.
For more information, see the following resources: