Home > CAPEC List > CAPEC-109: Object Relational Mapping Injection (Version 3.0)  

CAPEC-109: Object Relational Mapping Injection

Attack Pattern ID: 109
Abstraction: Detailed
Status: Draft
Presentation Filter:
+ Description
An attacker leverages a weakness present in the database access layer code generated with an Object Relational Mapping (ORM) tool or a weakness in the way that a developer used a persistence framework to inject his or her own SQL commands to be executed against the underlying database. The attack here is similar to plain SQL injection, except that the application does not use JDBC to directly talk to the database, but instead it uses a data access layer generated by an ORM tool or framework (e.g. Hibernate). While most of the time code generated by an ORM tool contains safe access methods that are immune to SQL injection, sometimes either due to some weakness in the generated code or due to the fact that the developer failed to use the generated access methods properly, SQL injection is still possible.
+ Likelihood Of Attack

Low

+ Typical Severity

High

+ Relationships

The table(s) below shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf, ParentOf, MemberOf 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.

+ Relevant to the view "Mechanisms of Attack" (CAPEC-1000)
NatureTypeIDName
ChildOfStandard Attack PatternStandard 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.66SQL Injection
+ Execution Flow
Explore
  1. Determine Persistence Framework Used: An attacker tries to determine what persistence framework is used by the application in order to leverage a weakness in the generated data access layer code or a weakness in a way that the data access layer may have been used by the developer. An attacker provides input to the application in an attempt to induce an error screen that reveals a stack trace that gives an indication of the automated data access layer used. Or an attacker may simply make some educated guesses and assume, for instance, that Hibernate is used and try to craft an attack from there.

    Techniques
    An attacker provides input to the application in an attempt to induce an error screen that reveals a stack trace that gives an indication of the automated data access layer used. Or an attacker may simply make some educated guesses and assume, for instance, that Hibernate is used and try to craft an attack from there.
  2. Probe for ORM Injection vulnerabilities: The attacker injects ORM syntax into user-controllable data inputs of the application to determine if it is possible modify data query structure and content.

Exploit
  1. Perform SQL Injection through the generated data access layer: An attacker proceeds to exploit a weakness in the generated data access methods that does not properly separate control plane from the data plan, or potentially a particular way in which developer might have misused the generated code, to modify the structure of the executed SQL queries and/or inject entirely new SQL queries. An attacker uses normal SQL injection techniques and adjusts them to reflect the type of data access layer generation framework used by the application.

    Techniques
    An attacker uses normal SQL injection techniques and adjusts them to reflect the type of data access layer generation framework used by the application.
+ Prerequisites
An application uses data access layer generated by an ORM tool or framework
An application uses user supplied data in queries executed against the database
The separation between data plane and control plane is not ensured, through either developer error or an underlying weakness in the data access layer code generation framework
+ Skills Required
[Level: Medium]
Knowledge of general SQL injection techniques and subtleties of the ORM framework is needed
+ Resources Required
None: No specialized resources are required to execute this type of attack.
+ Consequences

The table below 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.

ScopeImpactLikelihood
Integrity
Modify Data
Availability
Unreliable Execution
Confidentiality
Read Data
Confidentiality
Access Control
Authorization
Gain Privileges
Confidentiality
Integrity
Availability
Execute Unauthorized Commands
+ Mitigations
Remember to understand how to use the data access methods generated by the ORM tool / framework properly in a way that would leverage the built-in security mechanisms of the framework
Ensure to keep up to date with security relevant updates to the persistence framework used within your application.
+ Example Instances
When using Hibernate, it is possible to use the session.find() method to run queries against the database. This is an overloaded method that provides facilities to perform binding between the supplied user data and place holders in the statically defined query. However, it is also possible to use the session.find() method without using any of these query binding overloads, hence effectively concatenating the user supplied data with rest of the SQL query, resulting in a possibility for SQL injection. While the framework may provide mechanisms to use methods immune to SQL injections, it may also contain ways that are not immune that may be chosen by the developer.
+ References
[REF-4] "OWASP Testing Guide". Testing for ORM Injection (OWASP-DV-007). v4 [DRAFT]. The Open Web Application Security Project (OWASP). <http://www.owasp.org/index.php/Testing_for_ORM_Injection>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2014-06-23CAPEC Content TeamThe MITRE Corporation
Modifications
Modification DateModifierOrganization
2017-08-04CAPEC Content TeamThe MITRE Corporation
Updated Resources_Required

More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018