Chapter 2: Threats and Countermeasures for Web Services

Contents

• Threats, Attacks, Vulnerabilities, and Countermeasures
• Web Services Security Frame
• Auditing and Logging
• Authentication
• Authorization
• Configuration Management
• Exception Management
• Impersonation/Delegation
• Message Encryption
• Message Replay Detection
• Message Signing
• Message Validation
• Sensitive Data
• Session Management
• Threats and Attacks Explained

Objectives

• Understand the difference between a threat, an attack, a vulnerability, and a countermeasure.
• Understand common vulnerabilities in Web services.
• Understand how to implement effective countermeasures for dealing with common Web services threats and attacks.

Overview

It is important to think like an attacker when designing and implementing your service. Putting yourself in the attacker's mindset will make you more effective at designing mitigations for vulnerabilities and coding defensively.

Threats, Attacks, Vulnerabilities, and Countermeasures

This chapter analyzes security for Web services from the perspectives of threats, vulnerabilities, attacks, and countermeasures. These terms are defined as follows:

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

Web Services Security Frame

The following key security concepts provide a frame for thinking about security when designing and architecting services. Understanding these concepts helps you put core security features such as authentication, authorization, auditing, confidentiality, integrity, and availability in action.

Category	Description
Auditing and logging	Auditing and logging refers to how security-related events are recorded, monitored, and audited.
Authentication	Authentication is the process in which an entity proves the identity of another entity, typically through credentials, such as a username and password.
Authorization	Authorization is the means by which your service provides access controls for resources and operations.
Configuration Management	Configuration management refers to how your service handles database connections, administration, and other configuration settings.
Exception management	Exception management refers to how you handle exceptions within your application, including fault contracts.
Impersonation/delegation	Impersonation and delegation refers to how your service impersonates users and passes identity information downstream for authorization purposes.
Message encryption	Message encryption refers to protecting a message by converting the contents to ciphertext using cryptographic methods.
Message replay detection	Message replay detection refers to identifying and rejecting messages that are resubmitted.
Message signing	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	Message validation refers to how you verify the message payload against a 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, in addition to input from network resources, such as databases. Output typically includes the return values from your service or disk/database writes among others.
Sensitive data	Sensitive data refers to user and application data whose integrity and confidentiality you need to protect. You need to protect sensitive data from being stolen from memory or configuration files, or when it is transmitted over the network.
Session management	A session refers to a series of related interactions between a client and your service.

Auditing and Logging

Auditing and logging is used to monitor and record important activity, such as transactions or user management events, on both the client and the service. Logged information should be recorded and stored to enable efficient auditing of events in the case of an attack or a suspected attack.

Threats and attacks include:

• Repudiation. An attacker denies performing an operation, exploits an application without trace, or covers his or her tracks.
• Denial of service (DoS). An attacker overwhelms logs with excessive entries or very large log entries.
• Disclosure of confidential information. An attacker gathers sensitive information from log files.

Vulnerabilities include:

• Failing to audit failed logons.
• Failing to secure log files.
• Storing sensitive information in log files.
• Failing to audit across application tiers.
• Failure to throttle log files.

Countermeasures include:

• Identify malicious behavior.
• Know your baseline. (Know what good traffic looks like.)
• Use application instrumentation to expose behavior that can be monitored.
• Throttle logging.
• Strip sensitive data before logging.

Authentication

Authentication is the mechanism by which your clients can establish their identity with your service, using a set of credentials that prove that identity. A username is an example of an identity, while a password is an example of a credential.

Threats and attacks include:

• Network eavesdropping. An attacker steals identity and/or credentials off the network by reading network traffic not intended for them.
• Brute force attacks. An attacker guesses identity and/or credentials through the use of brute force.
• Dictionary attacks. An attacker guesses identity and/or credentials through the use of common terms in a dictionary designed for that purpose.
• Cookie replay attacks. An attacker gains access to an authenticated session through the reuse of a stolen cookie containing session information.
• Credential theft. An attacker gains access to credentials through data theft; for instance, phishing or social engineering.

Vulnerabilities:

• Using weak passwords.
• Storing clear text credentials in configuration files.
• Passing clear text credentials over the network.
• Permitting prolonged session lifetime.
• Mixing personalization with authentication.
• Using weak authentication mechanisms (e.g., using Basic authentication over an untrusted network).

Countermeasures include:

• Use strong password policies.
• Do not store credentials in an insecure manner.
• Use authentication mechanisms that do not require clear text credentials to be passed over the network.
• Encrypt communication channels to secure authentication tokens.
• Use Secure HTTP (HTTPS) only with Forms authentication cookies.
• Separate anonymous from authenticated pages.
• Use cryptographic random number generators to generate session IDs.

Authorization

Authorization is the mechanism by which you control the operations and resources an authenticated client can access. Authorization controls may be enforced at the class level, the method level, or in fine-grained business logic if needed.

Threats and attacks include:

• Elevation of privilege. An attacker enters a system as a lower-level user, but is able to obtain higher-level access.
• Disclosure of confidential data. An attacker accesses confidential information because of authorization failure on a resource or operation.
• Data tampering. An attacker modifies sensitive data because of authorization failure on a resource or operation.
• Luring attacks. An attacker lures a higher-privileged user into taking an action on their behalf. This is not an authorization failure but rather a failure of the system to properly inform the user.
• Token stealing. An attacker steals the credentials or token of another user in order to gain authorization to resources or operations they would not otherwise be able to access.

Vulnerabilities include:

• Relying on a single gatekeeper (e.g., relying on client-side validation only).
• Failing to lock down system resources against application identities.
• Failing to limit database access to specified stored procedures.
• Using inadequate separation of privileges.
• Connection pooling.
• Permitting overprivileged accounts.

Countermeasures include:

• Use least-privileged accounts.
• Tie authentication to authorization on the same tier.
• Consider granularity of access.
• Enforce separation of privileges.
• Use multiple gatekeepers.
• Secure system resources against system identities.

Configuration Management

Security settings, authentication, authorization, logging, and other parameters can usually be set in configuration files. Improper configuration can lead to security vulnerabilities, as can a lack of protection on the files themselves, which can lead to improper modification or theft of connection strings and other sensitive information.

Threats and attacks include:

• Unauthorized access to configuration stores. An attacker gains access to configuration files and is able to modify binding settings, etc.
• Retrieval of clear text configuration secrets. An attacker gains access to configuration files and is able to retrieve sensitive information such as database connection strings.

Vulnerabilities include:

• Using insecure custom administration interfaces.
• Failing to secure configuration files on the server.
• Storing sensitive information in the clear text.
• Having too many administrators.
• Using overprivileged process accounts and service accounts.

Countermeasures include:

• Use access control lists (ACLs).
• Encrypt sensitive sections of configuration files.
• Use secure settings for various operations of Web services using configuration files.

Exception Management

Exception management is the means by which you expose and consume exception information within your service and send it back to your clients. In most cases, exceptions should be shielded from the client entirely and handled with a sanitized error message. In addition, fault contracts should be negotiated beforehand so that the client and the Web service agree on a course of action when a failure occurs.

Threats and attacks include:

• Information disclosure. Sensitive system or application details are revealed through exception information.
• Denial of Service (DoS). An attacker uses error conditions to stop your service or place it in an unrecoverable error state.
• Elevation of privilege. Your service encounters an error and fails to an insecure state; for instance, failing to revert impersonation.

Vulnerabilities include:

• Failure to use structured exception handling (try/catch).
• Revealing too much information to the client.
• Failure to specify fault contracts with the client.
• Failure to use a global exception handler.

Countermeasures include:

• Use structured exception handling (by using try/catch blocks).
• Catch and wrap exceptions only if the operation adds value/information.
• Do not reveal sensitive system or application information.
• Implement a global exception handler.
• Do not log private data such as passwords.

Impersonation/Delegation

Impersonation and delegation are techniques used to flow the original caller to back-end resources. Impersonation is used to access resources on the same machine where the service code is running. Delegation is used to access network resources on other machines.

Threats and attacks include:

• Elevation of privilege. An attacker is able to run in the context of a higher-privileged user.
• Disclosure of confidential information. An attacker gains access to data that should only be available to another user.

Vulnerabilities include:

• Failure to revert to a lower privilege after using impersonation.
• Improper use of global impersonation across the entire service.

Countermeasures include:

• Use a Using statement to automatically revert impersonation.
• Granularly impersonate only those operations that need it.

Message Encryption

Message encryption is used to protect sensitive data in-transport over the network. Encryption does not protect the integrity of the data, but only its confidentiality. Message encryption can be provided by either message security or transport security. Message security encrypts each message individually, while transport security encrypts the entire communication channel (e.g., with SSL).

Threats and attacks include:

• Failure to encrypt messages. An attacker is able to read message content off the network because it is not encrypted.
• Theft of encryption keys. An attacker is able to decrypt sensitive data because he or she has the keys.
• Man-in-the-middle attack. An attacker can read and then modify messages between the client and the service.

Vulnerabilities include:

• Not encrypting messages.
• Using custom cryptography.
• Distributing keys insecurely.
• Managing or storing keys insecurely.

Countermeasures include:

• Use message security or transport security to encrypt your messages.
• Use proven platform-provided cryptography.
• Periodically change your keys.

Message Replay Detection

Message replay detection is a feature that allows your code to detect some instances in which an attacker is trying to replay messages in order to steal a session from one of your clients.

Threats and attacks include:

• Session replay. An attacker steals messages off the network and replays them in order to steal a user's session.

Vulnerabilities include:

• Failure to use a mechanism to detect message replays.

Countermeasures include:

• Use any platform-provided replay detection features.
• Consider creating custom code if the platform does not provide a detection mechanism.

Message Signing

Message signing is used to protect the integrity of messages in transit over the network and to provide proof of the original sender. Signing does not protect the confidentiality of the data, but only its integrity and confidence in the original sender. Message signing can be provided by either message security or transport security. Message security signs each message individually, while transport security protects the entire communication channel (e.g., with SSL).

Threats and attacks include:

• Data tampering. An attacker modifies the data in a message in order to attack the client or the service.

Vulnerabilities include:

• Not using either message or transport security.

Countermeasures include:

• Turn on message or transport security.

Message Validation

Message validation is used to protect your service from malformed messages and message parameters. Message schemas can be used to validate incoming messages, while custom validators can be used to validate parameter data before your service consumes it.

Threats and attacks include:

• Canonicalization attacks. Canonicalization attacks can occur anytime validation is performed on a different form of the input than that which is used for later processing. For instance, a validation check may be performed on an encoded string, which is later decoded and used as a file path or URL.
• Cross-site scripting. Cross-site scripting can occur if you fail to encode user input before echoing back to a client that will render it as HTML.
• SQL injection. Failure to validate input can result in SQL injection if the input is used to construct a SQL statement, or if it will modify the construction of a SQL statement in some way.
• XPath injection. XPath injection can result if the input sent to the Web service is used to influence or construct an XPath statement. The input can also introduce unintended results if the XPath statement is used by the Web service as part of some larger operation, such as applying an XQuery or an XSLT transformation to an XML document.
• XML bomb. XML bomb attacks occur when specific, small XML messages are parsed by a service resulting in data that feeds on itself and grows exponentially. An attacker sends an XML bomb with the intent of overwhelming a Web service's XML parser, thus resulting in a denial of service (DoS) attack.

Vulnerabilities include:

• Using non-validated input used to generate SQL queries.
• Relying only on client-side validation.
• Using input file names, URLs, or usernames for security decisions.
• Using application-only filters for malicious input.
• Looking for known bad patterns of input.
• Trusting data read from databases, file shares, and other network resources.
• Failing to validate input from all sources including cookies, Simple Object Access Protocol (SOAP) headers, SOAP parameters, databases, and network resources.

Countermeasures include:

• Do not trust client input.
• Validate input: length, range, format, and type.
• Validate XML streams.
• Constrain, reject, and sanitize input.
• Encode output.
• Restrict the size, length, and depth of parsed XML messages.

Sensitive Data

Sensitive data refers to any confidential information that your service processes or transmits. Protection of sensitive data includes protecting the information over the network, in configuration files, in local memory or file storage, or in databases and log files. Sensitive information includes user identity and credentials as well as any personally identifiable information such as social security number.

A more complete definition of sensitive data is:

• Information that either contains personally identifiable information or can be used to derive personally identifiable information that should not be shared with users.
• Information that a user provides that they would not want shared with other users of the application.
• Information that comes from an external trusted source that is not designed to be shared with users.

Threats and attacks include:

• Memory dumping. An attacker is able to read sensitive data out of memory or from local files.
• Network eavesdropping. An attacker listens to and intercepts unencrypted sensitive data off the network.
• Configuration file sniffing. An attacker steals sensitive information, such as connection strings, out of configuration files.

Vulnerabilities include:

• Storing secrets when you do not need to.
• Storing secrets in code.
• Storing secrets in clear text in files, registry, or configuration.
• Passing sensitive data in clear text over networks.

Countermeasures include:

• Do not store secrets in software.
• Encrypt sensitive data over the network.
• Secure the channel.
• Encrypt sensitive data in configuration files.

Session Management

Sessions are the means by which an application maintains stateful communication with a client over time. This is usually supported through the use of a session ID, token, or cookie. If a session is supported in such a way that credentials are not required for every interaction, an attacker could potentially steal the session and act on the original user's behalf.

Threats and attacks include:

• Session hijacking. An attacker steals the session ID of another user in order to gain access to resources or operations they would not otherwise be able to access.
• Session replay. An attacker steals messages off the network and replays them in order to steal a user's session.
• Man-in-the-middle attack. An attacker can read and then modify messages between the client and the service.
• Inability to log out successfully. An application leaves a communication channel open rather than completely closing the connection and destroying any server objects in memory relating to the session.
• Cross-site request forgery. Cross-site request forgery (CSRF) is where an attacker tricks a user into performing an action on a site where the user actually has a legitimate authorized account.
• Session fixation. An attacker uses CSRF to set another person's session identifier and thus hijack the session after the attacker tricks a user into initiating it.
• Load balancing and session affinity. When sessions are transferred from one server to balance traffic among the various servers, an attacker can hijack the session during the handoff.

Vulnerabilities include:

• Passing session IDs over unencrypted channels.
• Permitting prolonged session lifetime.
• Having insecure session state stores.
• Placing session identifiers in query strings.

Countermeasures include:

• Partition the site by anonymous, identified, and authenticated users.
• Reduce session timeouts.
• Avoid storing sensitive data in session stores.
• Secure the channel to the session store.
• Authenticate and authorize access to the session store.

Threats and Attacks Explained

The following explanations briefly describe some of the threats and attacks mentioned above:

• Brute force attacks. Attacks that use the raw computer processing power to try different permutations of any variable that could expose a security hole. For example, if an attacker knew that access required an 8-character username and a 10-character password, the attacker could iterate through every possible combination (256 multiplied by itself 18 times) in order to attempt to gain access to a system. No intelligence is used to shape or filter likely combinations.
• Buffer overflows. The maximum size of a given variable (string or otherwise) is exceeded, forcing unintended program processing. In this case, the attacker uses this behavior to cause insertion and execution of code in such a way that the attacker gains control of the program in which the buffer overflow occurs. Depending on the program's privileges, the seriousness of the security breach will vary.
• Canonicalization attacks. There are multiple ways to access the same object and an attacker uses a method to bypass any security measures instituted on the primary intended methods of access. Often, the unintended methods of access can be less secure deprecated methods.
• Cookie manipulation. Through various methods, an attacker will alter the cookies stored in the browser. Attackers will then use the cookie to fraudulently authenticate themselves to a service or Web site.
• Cookie replay attacks. Reusing a previously valid cookie to deceive the server into believing that a previously authenticated session is still in progress and valid.
• Credential theft. Stealing the verification part of an authentication pair (identity + credentials = authentication). Passwords are a common credential.
• Cross-site scripting. An attacker is able to inject executable code (script) into a stream of data that will be rendered in a browser. The code will be executed in the context of the user's current session and will gain privileges to the site and information that it would not otherwise have.
• Connection pooling. The practice of creating and then reusing a connection resource as a performance optimization. In a security context, this can result in either the client or server using a connection previously used by a highly privileged user being used for a lower-privileged user or purpose. This can potentially expose vulnerabilities if the connection is not reauthorized when used by a new identity.
• Data tampering. An attacker violates the integrity of data by modifying it in local memory, in a data-store, or on the network. Modification of this data could provide the attacker with access to a service through a number of the different methods listed in this document.
• Denial of service. Denial of service (DoS) is the process of making a system or application unavailable. For example, a DoS attack might be accomplished by bombarding a server with requests to consume all available system resources, or by passing the server malformed input data that can crash an application process.
• Dictionary attack. Use of a list of likely access methods (usernames, passwords, coding methods) to try and gain access to a system. This approach is more focused and intelligent than the “brute force” attack method, so as to increase the likelihood of success in a shorter amount of time.
• Disclosure of sensitive/confidential data. Sensitive data is exposed in some unintended way to users who do not have the proper privileges to see it. This can often be done through parameterized error messages, where an attacker will force an error and the program will pass sensitive information up through the layers of the program without filtering it. This can be personally identifiable information (PII) or system data.
• Elevation of privilege. 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.
• Encryption. The process of taking sensitive data and changing it in such a way that it is unrecognizable to anyone but those who know how to decode it. Different encryption methods have different strengths based on how easy it is for an attacker to obtain the original information through whatever methods are available.
• Information disclosure. Unwanted exposure of private data. For example, a user views the contents of a table or file that 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.
• Luring attacks. An attacker lures a higher-privileged user into taking an action on his or her behalf. This is not an authorization failure but rather a failure of the system to properly inform the user.
• Man-in-the-middle attacks. A person intercepts both the client and server communications and then acts as an intermediary between the two without each ever knowing. This gives the “middle man” the ability to read and potentially modify messages from either party in order to implement another type of attack listed here.
• Network eavesdropping. Listening to network packets and reassembling the messages being sent back and forth between one or more parties on the network. While not an attack itself, network eavesdropping can easily intercept information for use in specific attacks listed in this document.
• 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.
• Repudiation. 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.
• 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.
• Session replay. An attacker steals messages off of the network and replays them in order to steal a user's session.
• Session fixation. An attacker sets (fixates) another person's session identifier artificially. The attacker must know that a particular Web service accepts any session ID that is set externally; for example, the attacker sets up a URL such as http://unsecurewebservice.com/?sessionID=1234567. The attacker then sends this URL to a valid user, who clicks on it. At this point, a valid session with the ID 1234567 is created on the server. Because the attacker determines this ID, he or she can now hijack the session, which has been authenticated using the valid user's credentials.
• Spoofing. An attempt to gain access to a system by using a false identity. This can be accomplished by 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.
• SQL injection. Failure to validate input in cases where the input is used to construct a SQL statement or will modify the construction of a SQL statement in some way. If the attacker can influence the creation of a SQL statement, he or she can gain access to the database with privileges otherwise unavailable and use this in order to steal or modify information or destroy data.
• Throttling. The process of limiting resource usage to keep a particular process from bogging down and/or crashing a system. Relevant as a countermeasure in DoS attacks, where an attacker attempts to crash the system by overloading it with input.