This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit


Revision as of 15:39, 5 June 2008 by Tehmina (talk | contribs) (New page: == Before you begin == Since ORM architecture isn't obvious, this document will explain some important things you need to know in order to analyze a Hibernate application in a security con...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Before you begin

Since ORM architecture isn't obvious, this document will explain some important things you need to know in order to analyze a Hibernate application in a security context. This document assumes some SQL and database knowledge.

A note about SQL injection

Since it is the hot topic.

  • Hibernate does not grant immunity to SQL Injection, one can misuse the api as they please.
  • There is nothing special about HQL (Hibernates subset of SQL) that makes it any more or less susceptible.
  • Functions such as createQuery(String query) and createSQLQuery(String query) create a Query object that will be executed when the call to commit() is made. If the query string is tainted you have sql injection. The details of these functions are covered later.
  • StatelessSession?'s insert(), update(), and delete() methods do NOT wait for a call to commit(), they are equated with direct database communication.

Architecture Overview

The problem Hibernate addresses

  • In object oriented systems, we represent entities as objects, and use a database to persist those objects. Generally these objects are considered non-scalar values (non-primitive types).
  • But many databases can only store and manipulate scalar values such as integers and strings organized in tables.
  • The crux of the problem is translating those objects to forms which can be stored in the database, and which can later be retrieved easily, while preserving the properties of the objects and their relationships; these objects are then said to be persistent.
  • Hibernate attempts to address this problem with Object/Relational Mapping (O/R M) by mapping attributes of objects we wish to persist to columns of a database.

See original article.

Le Nutshell

  • Generally Hibernate applications use POJOs to represent objects we want to persist in a database.
  • They are usually implemented in the style of JavaBeans.
  • These objects should have an identifier property used to represent it's primary key value in the database.
  • This identifier will be mapped in a hibernate mapping file which defaults to the extension .hbm.xml, you will see this mapping in later examples with the <id> element.
  • This mapping file will also map all other object properties we wish to preserve to columns in a database table, along with their data types and other optional metadata.
  • There are ways to map object properties programmatically, but this will not be covered until I find reason to include.
  • Once objects are mapped, Hibernate provides the mechanism for you to store and access them via org.hibernate.Session and org.hibernate.Transaction objects.
  • The Session object has methods to save() or associate objects with a session, load() objects from a database and createQuery()s to be executed against the database.
  • The Transaction object often wraps a transaction, allowing one to begin() transactions, commit() changes, and rollback() to a previous state.
  • Other classes worth mentioning: SessionFactory, TransactionFactory, and Query.
  • Hibernate's main configuration file, extension .cfg.xml, provides basic setup for things like datasource, dialect, mapping files, etc. See the example below.