CAPEC - CAPEC-22: Exploiting Trust in Client (Version 3.9)


Common Attack Pattern Enumeration and Classification A Community Resource for Identifying and Understanding Attacks

Home > CAPEC List > CAPEC-22: Exploiting Trust in Client (Version 3.9)

CAPEC-22: Exploiting Trust in Client

Attack Pattern ID: 22

Abstraction: Meta

View customized information:

Description

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

Likelihood Of Attack

High

Typical Severity

High

Relationships

This table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.

Nature	Type	ID	Name
ParentOf	Standard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.	39	Manipulating Opaque Client-based Data Tokens
ParentOf	Standard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.	77	Manipulating User-Controlled Variables
ParentOf	Standard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.	202	Create Malicious Client
ParentOf	Standard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.	207	Removing Important Client Functionality

This table shows the views that this attack pattern belongs to and top level categories within that view.

View Name	Top Level Categories
Domains of Attack	Software, Communications
Mechanisms of Attack	Subvert Access Control

Prerequisites

Server software must rely on client side formatted and validated values, and not reinforce these checks on the server side.

Skills Required

[Level: Medium]

The attacker must have fairly detailed knowledge of the syntax and semantics of client/server communications protocols and grammars

Resources Required

Ability to communicate synchronously or asynchronously with server

Consequences

This table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
Confidentiality Integrity Availability	Execute Unauthorized Commands
Confidentiality Access Control Authorization	Gain Privileges
Confidentiality	Read Data

Mitigations

Design: Ensure that client process and/or message is authenticated so that anonymous communications and/or messages are not accepted by the system.

Design: Do not rely on client validation or encoding for security purposes.

Design: Utilize digital signatures to increase authentication assurance.

Design: Utilize two factor authentication to increase authentication assurance.

Implementation: Perform input validation for all remote content.

Example Instances

Web applications may use JavaScript to perform client side validation, request encoding/formatting, and other security functions, which provides some usability benefits and eliminates some client-server round-tripping. However, the web server cannot assume that the requests it receives have been subject to those validations, because an attacker can use an alternate method for crafting the HTTP Request and submit data that contains poisoned values designed to spoof a user and/or get the web server to disclose information.

Web 2.0 style applications may be particularly vulnerable because they in large part rely on existing infrastructure which provides scalability without the ability to govern the clients. Attackers identify vulnerabilities that either assume the client side is responsible for some security services (without the requisite ability to ensure enforcement of these checks) and/or the lack of a hardened, default deny server configuration that allows for an attacker probing for weaknesses in unexpected ways. Client side validation, request formatting and other services may be performed, but these are strictly usability enhancements not security enhancements.

Many web applications use client side scripting like JavaScript to enforce authentication, authorization, session state and other variables, but at the end of day they all make requests to the server. These client side checks may provide usability and performance gains, but they lack integrity in terms of the http request. It is possible for an attacker to post variables directly to the server without using any of the client script security checks and customize the patterns to impersonate other users or probe for more information.

Many message oriented middleware systems like MQ Series are rely on information that is passed along with the message request for making authorization decisions, for example what group or role the request should be passed. However, if the message server does not or cannot authenticate the authorization information in the request then the server's policy decisions about authorization are trivial to subvert because the client process can simply elevate privilege by passing in elevated group or role information which the message server accepts and acts on.

Related Weaknesses

A Related Weakness relationship associates a weakness with this attack pattern. Each association implies a weakness that must exist for a given attack to be successful. If multiple weaknesses are associated with the attack pattern, then any of the weaknesses (but not necessarily all) may be present for the attack to be successful. Each related weakness is identified by a CWE identifier.

CWE-ID	Weakness Name
290	Authentication Bypass by Spoofing
287	Improper Authentication
20	Improper Input Validation
200	Exposure of Sensitive Information to an Unauthorized Actor
693	Protection Mechanism Failure

References

[REF-1] G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. 2004-02.

Content History

Submissions
Submission Date	Submitter	Organization
2014-06-23 (Version 2.6)	CAPEC Content Team	The MITRE Corporation
2014-06-23 (Version 2.6)
Modifications
Modification Date	Modifier	Organization
2015-12-07 (Version 2.8)	CAPEC Content Team	The MITRE Corporation
2015-12-07 (Version 2.8)	Updated Description Summary, Related_Attack_Patterns
2019-09-30 (Version 3.2)	CAPEC Content Team	The MITRE Corporation
2019-09-30 (Version 3.2)	Updated Description
Previous Entry Names
Change Date	Previous Entry Name
2015-12-07 (Version 2.8)	Exploiting Trust in Client (aka Make the Client Invisible)

More information is available — Please select a different filter.

Page Last Updated or Reviewed: July 31, 2018


	Site Map \| Terms of Use \| Manage Cookies \| Cookie Notice \| Privacy Policy \| Contact Us \| Use of the Common Attack Pattern Enumeration and Classification (CAPEC), and the associated references from this website are subject to the Terms of Use. Copyright © 2007–2024, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.