Use of Less Trusted Source

Draft Base

Structure: Simple

Description

This vulnerability occurs when a system has access to multiple sources for the same critical data, but it chooses to rely on the less secure or less trustworthy one. This creates a security gap because the system ignores better-protected alternatives that offer stronger verification or are harder for attackers to compromise.

Extended Description

Think of this flaw as a developer choosing to trust a rumor from an anonymous tip line over an official, signed document from a verified authority—even though both claim to state the same fact. The core issue isn't about missing data, but about making a poor choice between available sources. This often happens in code that fetches configuration, license keys, or critical parameters from multiple locations (like a local file, a network service, and a hardware security module) but defaults to the most convenient, rather than the most secure, option. To prevent this, your code should implement a clear trust hierarchy. Always design your system to prefer and require the most authoritative source—the one with the strongest cryptographic verification, integrity checks, or tamper resistance. This means explicitly validating the source before trusting its data and failing securely if the high-trust source is unavailable, rather than silently falling back to a weaker alternative that an attacker could easily manipulate.

Common Consequences 1

Scope: Access Control

Impact: Bypass Protection MechanismGain Privileges or Assume Identity

An attacker could utilize the untrusted data source to bypass protection mechanisms and gain access to sensitive data.

Demonstrative Examples 1

This code attempts to limit the access of a page to certain IP Addresses. It checks the 'HTTP_X_FORWARDED_FOR' header in case an authorized user is sending the request through a proxy.

Code Example:Bad
PHP
php

The 'HTTP_X_FORWARDED_FOR' header can be user controlled and so should never be trusted. An attacker can falsify the header to gain access to the page.

This fixed code only trusts the 'REMOTE_ADDR' header and so avoids the issue:

Code Example:

Good

PHP

php

...*

Be aware that 'REMOTE_ADDR' can still be spoofed. This may seem useless because the server will send the response to the fake address and not the attacker, but this may still be enough to conduct an attack. For example, if the generatePage() function in this code is resource intensive, an attacker could flood the server with fake requests using an authorized IP and consume significant resources. This could be a serious DoS attack even though the attacker would never see the page's sensitive content.

Observed Examples 4

CVE-2001-0860Product uses IP address provided by a client, instead of obtaining it from the packet headers, allowing easier spoofing.

CVE-2004-1950Web product uses the IP address in the X-Forwarded-For HTTP header instead of a server variable that uses the connecting IP address, allowing filter bypass.

CVE-2001-0908Product logs IP address specified by the client instead of obtaining it from the packet headers, allowing information hiding.

CVE-2006-1126PHP application uses IP address from X-Forwarded-For HTTP header, instead of REMOTE_ADDR.

Applicable Platforms

Languages:

Not Language-Specific : Undetermined

Modes of Introduction

Architecture and Design

Implementation

Related Attack Patterns

Related Weaknesses

ChildOf:

Insufficient Verification of Data Authenticity (CWE-345)

Taxonomy Mapping

PLOVER