Home > CAPEC List > CAPEC-48: Passing Local Filenames to Functions That Expect a URL (Version 3.4)  

CAPEC-48: Passing Local Filenames to Functions That Expect a URL

Attack Pattern ID: 48
Abstraction: Standard
Status: Draft
Presentation Filter:
+ Description
This attack relies on client side code to access local files and resources instead of URLs. When the client browser is expecting a URL string, but instead receives a request for a local file, that execution is likely to occur in the browser process space with the browser's authority to local files. The attacker can send the results of this request to the local files out to a site that they control. This attack may be used to steal sensitive authentication data (either local or remote), or to gain system profile information to launch further attacks.
+ Likelihood Of Attack


+ Typical Severity


+ Relationships
Section HelpThis 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.
ChildOfMeta Attack PatternMeta Attack Pattern - A meta level attack pattern in CAPEC is a decidedly abstract characterization of a specific methodology or technique used in an attack. A meta attack pattern is often void of a specific technology or implementation and is meant to provide an understanding of a high level approach. A meta level attack pattern is a generalization of related group of standard level attack patterns. Meta level attack patterns are particularly useful for architecture and design level threat modeling exercises.212Functionality Misuse
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
+ Execution Flow
  1. Identify web application URL inputs: Review application inputs to find those that are designed to be URLs.

    Manually navigate web site pages to identify URLs.
    Use automated tools to identify URLs.
  1. Identify URL inputs allowing local access.: Execute test local commands via each URL input to determine which are successful.

    Manually execute a local command (such as 'pwd') via the URL inputs.
    Using an automated tool, test each URL input for weakness.
  1. Execute malicious commands: Using the identified URL inputs that allow local command execution, execute malicious commands.

    Execute local commands via the URL input.
+ Prerequisites
The victim's software must not differentiate between the location and type of reference passed the client software, e.g. browser
+ Skills Required
[Level: Medium]
Attacker identifies known local files to exploit
+ Consequences
Section HelpThis 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.
Read Data
Modify Data
+ Mitigations
Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.
Implementation: Ensure all configuration files and resource are either removed or protected when promoting code into production.
Design: Use browser technologies that do not allow client side scripting.
Implementation: Perform input validation for all remote content.
Implementation: Perform output validation for all remote content.
Implementation: Disable scripting languages such as JavaScript in browser
+ Example Instances

J2EE applications frequently use .properties files to store configuration information including JDBC connections, LDAP connection strings, proxy information, system passwords and other system metadata that is valuable to attackers looking to probe the system or bypass policy enforcement points. When these files are stored in publicly accessible directories and are allowed to be read by the public user, then an attacker can list the directory identify a .properties file and simply load its contents in the browser listing its contents. A standard Hibernate properties file contains

hibernate.connection.driver_class = org.postgresql.Driver hibernate.connection.url = jdbc:postgresql://localhost/mydatabase hibernate.connection.username = username hibernate.connection.password = password hibernate.c3p0.min_size=5 hibernate.c3p0.max_size=20

Even if the attacker cannot write this file, there is plenty of information to leverage to gain further access.

+ References
[REF-1] G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. 2004-02.
[REF-416] "Core Concepts: Attack Patterns". <https://websec.io/2012/11/26/Core-Concepts-Attack-Patterns.html>.
+ Content History
Submission DateSubmitterOrganization
2014-06-23CAPEC Content TeamThe MITRE Corporation
Modification DateModifierOrganization
2015-12-07CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns
2017-08-04CAPEC Content TeamThe MITRE Corporation
Updated Attack_Phases, Description, Description Summary, References
2018-07-31CAPEC Content TeamThe MITRE Corporation
Updated Attack_Phases
2020-07-30CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns
2020-12-17CAPEC Content TeamThe MITRE Corporation
Updated @Abstraction
More information is available — Please select a different filter.
Page Last Updated or Reviewed: December 17, 2020