Home > CAPEC List > CAPEC-22: Exploiting Trust in Client (aka Make the Client Invisible) (Version 2.4)  

CAPEC-22: Exploiting Trust in Client (aka Make the Client Invisible)

 
Exploiting Trust in Client (aka Make the Client Invisible)
Definition in a New Window Definition in a New Window
Attack Pattern ID: 22
Abstraction: Meta
Status: Draft
Completeness: Complete
+ Description

Summary

An attack of this type exploits a programs' 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 placing themselves in the communication channel between client and server such that communication directly to the server is possible where the server believes it is communicating only with a valid client.

There are numerous variations of this type of attack.

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

+ Typical Severity

High

+ Typical Likelihood of Exploit

Likelihood: High

+ Methods of Attack
  • Spoofing
  • Protocol Manipulation
+ Examples-Instances

Description

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.

Description

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.

Description

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.

Description

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.

+ Attacker Skills or Knowledge Required

Skill or Knowledge 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

+ Solutions and 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.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Confidentiality
Integrity
Availability
Execute unauthorized code or commands
Run Arbitrary Code
Confidentiality
Access_Control
Authorization
Gain privileges / assume identity
Confidentiality
Read application data
+ Purposes
  • Penetration
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: Low
+ Technical Context
Architectural Paradigms
Client-Server
n-Tier
Frameworks
All
Platforms
All
Languages
All
+ References
[R.22.1] [REF-2] G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. February 2004.
+ Content History
Submissions
SubmitterOrganizationDate
[R.22.1][REF-2] Cigital, Inc2007-01-01
Modifications
ModifierOrganizationDateCommentsSource
Gunnar PetersonCigital, Inc2007-02-28Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"
Sean BarnumCigital, Inc2007-03-09Review and revise
CAPEC Content TeamThe MITRE Corporation2013-12-18Updated Related_Attack_PatternsInternal
CAPEC Content TeamThe MITRE Corporation2014-02-06Updated Attack_Prerequisites, Examples-InstancesInternal

Page Last Updated: April 10, 2014