Passing Local Filenames to Functions That Expect a URL
Attack Pattern ID: 48 (Detailed Attack Pattern Completeness: Complete)Typical Severity: HighStatus: Draft
+ 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.

+ Attack Prerequisites

The victim's software must not differentiate between the location and type of reference passed the client software, e.g. browser

+ Typical Likelihood of Exploit

Likelihood: High

+ Methods of Attack
  • API Abuse
  • Modification of Resources
  • Protocol Manipulation
+ Examples-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

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

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Medium

Attacker identifies known local files to exploit

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

+ Attack Motivation-Consequences
  • Information Leakage
  • Data Modification
+ Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
241Improper Handling of Unexpected Data TypeTargeted
706Use of Incorrectly-Resolved Name or ReferenceTargeted
+ Related Attack Patterns
NatureTypeIDNameDescriptionView(s) this relationship pertains toView\(s\)
ChildOfCategoryCategory210Abuse of Functionality 
Mechanism of Attack (primary)1000
+ Purposes
  • Exploitation
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: Low
+ Technical Context
Architectural Paradigms
+ References
G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. February 2004.
+ Content History
G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison-Wesley, February 2004.Cigital, Inc2007-01-01
Gunnar PetersonCigital, Inc2007-02-28Fleshed out content to CAPEC schema from the original descriptions in "Exploiting Software"
Sean BarnumCigital, Inc2007-03-09Review and revise