OWASP - User contributions [en]

Hibernate-Guidelines

2008-06-05T18:41:18Z

Tehmina:

== Status ==
'''In progress'''

== Important ==
=== SQL Injection ===

It is commonly thought that ORM layers, like Hibernate are immune to SQL injection. This is not the case as Hibernate includes a subset of SQL called HQL, and allows "native" SQL queries. Often the ORM layer only minimally manipulates the inbound query before handing it off to the database for processing.

=== Transaction Scope ===

All database communication should occur within the scope of a Transaction.

=== Persisting Tainted Data ===

If an application sets tainted properties in an object, then makes that object persistent, it is highly likely that data will be accessed at some point and displayed. If database values are never displayed to the user then obviously this is nullified. Better yet if we could figure out which values from the db are tainted but I have a feeling it's not a feasible scan.

=== Rollback ===

When an exception occurs, roll back the Transaction and close the Session. If you don't, Hibernate can't guarantee that in-memory state accurately represents persistent state.
If your Session is bound to the application, you have to stop the application. Rolling back the database transaction doesn't put your business objects back into the state they were at the start of the transaction, so the database state and the business objects do get out of sync. Objects that are manipulated after a rollback as if they were synchronized.

----

== Simple ==

=== Don't use load() to determine existence ===
Do not use Session.load() to determine if an instance with the given identifier exists on the database; use Session.get() or a query instead. This is a poss

=== Constructing Query Strings ===
Hibernate has a set of functions that are used internally to construct their query strings, but there is no limit to using them in application code - what if they were used with tainted data? This is pretty self explanatory.

=== Place each class mapping in its own file ===
Don't use a single monolithic mapping document. Map com.eg.Foo in the file com/eg/Foo.hbm.xml. This makes particularly good sense in a team environment. Nothing more than a app dev good practice.

=== Use bind variables ===
As in JDBC, always replace non-constant values by "?". Never use string manipulation to bind a nonconstant value in a query! Even better, consider using named parameters in queries.

=== Load mappings as resources ===
Deploy the mappings along with the classes they map.

----

== Detailed ==

=== Transaction Timeout ===
*Transaction timeouts ensure that no misbehaving transaction can indefinitely tie up resources while returning no response to the user.
*Outside a managed (JTA) environment, Hibernate cannot fully provide this functionality. However, Hibernate can at least control data access operations, ensuring that database level deadlocks and queries with huge result sets are limited by a defined timeout.
*In a managed environment, Hibernate can delegate transaction timeout to JTA.

<pre>
Session sess = factory.openSession();
try {
//set transaction timeout to 3 seconds
sess.getTransaction().setTimeout(3);
sess.getTransaction().begin();
// do some work
...
sess.getTransaction().commit()
}
catch (RuntimeException e) {
sess.getTransaction().rollback();
throw e; // or display error message
}
finally {
sess.close();
}
</pre>

===Identify natural keys ===
*Even though we recommend the use of surrogate keys as primary keys, you should still try to identify natural keys for all entities.
*A natural key is a property or combination of properties that is unique and non-null. If it is also immutable, even better.
*Map the properties of the natural key inside the <natural-id> element. Hibernate will generate the necessary unique key and nullability constraints, and your mapping will be more selfdocumenting.
*We strongly recommend that you implement equals() and hashCode() to compare the natural key properties of the entity.
*This mapping is not intended for use with entities with natural primary keys..

Example in hbm.xml:
<pre>
<natural-id mutable="true|false"/>
<property ... />
<many-to-one ... />
......
</natural-id>
</pre>

=== Parameter Binding ===

Hibernate parameter binding works like prepared statements. An edge case it is, but say you had an already tainted string, and then used Query setters to bind more parameters to the "?" placeholders.

Example of proper use:
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();
</pre>

Improper use:
<pre>
Insert insert = new Insert(dialect);
insert.setComment(taint);
insert.addSelectColumn(columnName, alias);
String sql = insert.toQueryString();
....
Query query = sess.createQuery(sql); /*B00*///creating a Query with an already tainted string
query.setString(position, val); //this doesn't cleanse the damage that's been done.
....
transaction.commit(); //sink the ship
</pre>

=== Declare identifier properties on persistent classes ===

Hibernate makes identifier properties optional. There are all sorts of reasons why you should use them. Mapped classes must declare the primary key column of the database table. Most classes will also have a Java-Beans-style property holding the unique identifier of an instance. This is the easiest and most recommended route.
{{{
<class name="Summary">
<subselect>
select item.name, max(bid.amount), count(*)
from item
join bid on bid.item_id = item.id
group by item.name
</subselect>
<synchronize table="item"/>
<synchronize table="bid"/>
<id
name="propertyName" (1)
type="typename" (2)
column="column_name" (3)
unsaved-value="null|any|none|undefined|id_value" (4)
access="field|property|ClassName"> (5)
node="element-name|@attribute-name|element/@attribute|."
<generator class="generatorClass"/>
</id>
</class>
}}}

=== Don't use session.find() ===
This pretty much looks like a duplicate of sql injection but using the deprecated method find() instead. This rule was pulled straight from the best practice list from the reference manual.

If using Hibernate, do not use the depreciated session.find() method without using one of the query binding overloads. Using session.find() with direct user input allows the user input to be passed directly to the underlying SQL engine and will result in SQL injections on all supported RDBMS.

<pre>

Payment payment = (Payment) session.
find("from com.example.Payment as payment where payment.id = " + paymentIds.get(i));
</pre>

The above Hibernate HQL will allow SQL injection from paymentIds, which are obtained from the user. A safer way to express this is:

<pre>

int pId = paymentIds.get(i);

TsPayment payment = (TsPayment) session.
find("from com.example.Payment as payment where payment.id = ?", pId, StringType);

</pre>

=== Cache Management and !OutOfMemoryException ===

*The Session caches every object that is in persistent state (watched and checked for dirty state by Hibernate).
*Whenever you pass an object to save(), update() or saveOrUpdate() and whenever you retrieve an object using load(), get(), list(), iterate() or scroll(), that object is added to the internal cache of the Session.
*When flush() or commit() is subsequently called, the state of that object will be synchronized with the database.
*Otherwise it grows endlessly until you get an OutOfMemoryException, if you keep it open for a long time or simply load too much data.
*One solution for this is to call clear() and evict() to manage the Session cache, but you most likely should consider a Stored Procedure if you need mass data operations.
*Some solutions are shown in Chapter 13, Batch processing. Keeping a Session open for the duration of a user session also means a high probability of stale data.

In this example, it would fall over with an OutOfMemoryException somewhere around the 50 000th row. That's because Hibernate caches all the newly inserted Customer instances in the session-level cache.
<pre>
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
}
tx.commit();
session.close();
</pre>
When making new objects persistent, you must flush() and then clear() the session regularly, to control the

<pre>
size of the first-level cache.
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
if ( i % 20 == 0 ) { //20, same as the JDBC batch size
//flush a batch of inserts and release memory:
session.flush();
session.clear();
}
}
tx.commit();
session.close();
</pre>

=== About StatelessSession ===
*A StatelessSession has no persistence context associated with it and does not provide many of the higher-level life cycle semantics. In particular, a stateless session does not implement a first-level cache nor interact with any second-level or query cache.
*This may be used as a solution for the cache out of memory problem.
*Operations performed using a stateless session do not ever cascade to associated instances. Collections are ignored by a stateless session.
*The insert(), update() and delete() operations defined by the StatelessSession interface are considered
to be direct database row-level operations, which result in immediate execution of a SQL INSERT, UPDATE or
DELETE respectively.

Example of proper use:
<pre>
StatelessSession session = sessionFactory.openStatelessSession();
Transaction tx = session.beginTransaction();

ScrollableResults customers = session.getNamedQuery("GetCustomers")
.scroll(ScrollMode.FORWARD_ONLY);
while ( customers.next() ) {
Customer customer = (Customer) customers.get(0);
customer.updateStuff(...);
session.update(customer);
}
tx.commit();
session.close();
</pre>

=== Aboot POJOs ===
* You can tell what objects are the persistent ones by looking at the xxx.hbm.xml files.
* Persistent objects are usually POJO's with a default no-arg constructor so that Hibernate can instantiate them using Constructor.newInstance().
* It is recommended that these POJO's have a property that is explicitly mapped as a primary key.

<pre>
<hibernate-mapping>
<class entity-name="Customer">
<id name="id"
type="long"
column="ID">
<generator class="sequence"/>
</id>
......
</pre>

* Accessors and mutators should be declared for persistent fields - it is optional but is good practice because Hibernate persists JavaBeans style properties.

=== Session and Concurrency issues ===

*A Session is not thread-safe.
*Things which are supposed to work concurrently, like HTTP requests, session beans, or Swing workers, will cause race conditions if a Session instance would be shared.
*If you keep your Hibernate Session in your HttpSession, you should consider synchronizing access to your Http session.
*Otherwise, a user that clicks reload fast enough may use the same Session in two concurrently running threads.

=== The equals() and hashCode() problem: ===

*Most Java objects provide a built-in equals() and hashCode() based on the object's identity; so each new() object will be different from all others.
*If all your objects are in memory, this is a fine model, but Hibernate's whole job, of course, is to move your objects out of memory.
* Hibernate uses the Hibernate session to manage this uniqueness. When you create an object with new(), and then save it into a session, Hibernate now knows that whenever you query for an object and find that particular object, Hibernate should return you that instance of the object.
* However, once you close the Hibernate session, all bets are off. If you keep holding onto an object that you either created or loaded in a Hibernate session that you have now closed, Hibernate has no way to know about those objects.
* So if you open another session and query for "the same" object, Hibernate will return you a new instance. Hence, if you keep collections of objects around between sessions, you will start to experience odd behavior (duplicate objects in collections, mainly).
* '''Long story short equals() and hashCode() should be implemented to compare object properties and not just compare on the basis of identifier (the property mapped as the primary key see the above example). The problem is discussed in detail [http://www.hibernate.org/109.html here].'''

<pre>
public class Cat {
...
public boolean equals(Object other) {
if (this == other) return true;
if ( !(other instanceof Cat) ) return false;
final Cat cat = (Cat) other;
if ( !cat.getLitterId().equals( getLitterId() ) ) return false;
if ( !cat.getMother().equals( getMother() ) ) return false;
return true;
}
public int hashCode() {
int result;
result = getMother().hashCode();
result = 29 * result + getLitterId();
return result;
}
}
</pre>

=== Using Detached Objects ===
*In a three tiered architecture, consider using detached objects.
*When using a servlet / session bean architecture, you could pass persistent objects loaded in the session
bean to and from the servlet / JSP layer.
*Use a new session to service each request.
*Use Session.merge() or Session.saveOrUpdate() to synchronize objects with the database.
Usually update() or saveOrUpdate() are used in the following scenario:
*the application loads an object in the first session
*the object is passed up to the UI tier
*some modifications are made to the object
*the object is passed back down to the business logic tier
*the application persists these modifications by calling update() in a second session

<pre>
// in the first session
Cat cat = (Cat) firstSession.load(Cat.class, catID);
// in a higher tier of the application
Cat mate = new Cat();
cat.setMate(mate);
// later, in a new session
secondSession.saveOrUpdate(cat); // update existing state (cat has a non-null id)
secondSession.saveOrUpdate(mate); // save the new instance (mate has a null id)
</pre>

=== Consider externalising query strings ===

This is a good practice if your queries call non-ANSI-standard SQL functions. Externalising the query
strings to mapping files will make the application more portable.
It also decreases the likelihood of injection because the Query objects let you set individual parameters but not the entire query string - you can only do that when you pass the string into the Query implementation constructor or call Session.createQuery.
==== Edge cases are still possibilities! ====
*Basically the application would have to be messy enough to be binding parameters here, and concatenating variables there to the same query string.
*You can extract the query string using Query.getQueryString(), and although you can't manipulate the string and 'add' it back to the Query object, you could theoretically taint it and use it in another instance of Query. Dumb? yes. Possible? Yes.

==== So how to externalize? ====
You may define named queries in the mapping document.

<pre>
<query name="ByNameAndMaximumWeight"><![CDATA[
from eg.DomesticCat as cat
where cat.name = ?
and cat.weight > ?
] ]></query>
</pre>

Parameter binding and executing is done programatically:

<pre>
Query q = sess.getNamedQuery("ByNameAndMaximumWeight");
q.setString(0, name);
q.setInt(1, minWeight);
List cats = q.list();
</pre>

*Note that the actual program code is independent of the query language that is used, you may also define native
SQL queries in metadata, or migrate existing queries to Hibernate by placing them in mapping files.
*Also note that a query declaration inside a <hibernate-mapping> element requires a global unique name for the
query, while a query declaration inside a <class> element is made unique automatically by prepending the
fully qualified name of the class, for example eg.Cat.ByNameAndMaximumWeight.

[[Category:Hibernate]]
[[Category:OWASP Java Project]]
[[Category:Java]]

Hibernate-Guidelines

2008-06-05T18:37:43Z

Tehmina:

== Status ==
'''In progress'''

== Important ==
=== SQL Injection ===

It is commonly thought that ORM layers, like Hibernate are immune to SQL injection. This is not the case as Hibernate includes a subset of SQL called HQL, and allows "native" SQL queries. Often the ORM layer only minimally manipulates the inbound query before handing it off to the database for processing.

=== Transaction Scope ===

All database communication should occur within the scope of a Transaction. Although we can't anticipate all design patterns, it would be an easy scan to flag jdbc and hibernate calls outside of transactions in a Hibernate application.

=== Persisting Tainted Data ===

If an application sets tainted properties in an object, then makes that object persistent, it is highly likely that data will be accessed at some point and displayed. If database values are never displayed to the user then obviously this is nullified. Better yet if we could figure out which values from the db are tainted but I have a feeling it's not a feasible scan. Long story short - saves, updates, inserts, whatever that are made with tainted objects should be flagged.

=== Rollback ===

When an exception occurs, roll back the Transaction and close the Session. If you don't, Hibernate can't guarantee that in-memory state accurately represents persistent state.
If your Session is bound to the application, you have to stop the application. Rolling back the database transaction doesn't put your business objects back into the state they were at the start of the transaction, so the database state and the business objects do get out of sync. Objects that are manipulated after a rollback as if they were synchronized.

----

== Simple ==

=== Don't use load() to determine existence ===
Do not use Session.load() to determine if an instance with the given identifier exists on the database; use Session.get() or a query instead. This is a poss

=== Constructing Query Strings ===
Hibernate has a set of functions that are used internally to construct their query strings, but there is no limit to using them in application code - what if they were used with tainted data? This is pretty self explanatory.

=== Place each class mapping in its own file ===
Don't use a single monolithic mapping document. Map com.eg.Foo in the file com/eg/Foo.hbm.xml. This makes particularly good sense in a team environment. Nothing more than a app dev good practice.

=== Use bind variables ===
As in JDBC, always replace non-constant values by "?". Never use string manipulation to bind a nonconstant value in a query! Even better, consider using named parameters in queries.

=== Load mappings as resources ===
Deploy the mappings along with the classes they map.

----

== Detailed ==

=== Transaction Timeout ===
*Transaction timeouts ensure that no misbehaving transaction can indefinitely tie up resources while returning no response to the user.
*Outside a managed (JTA) environment, Hibernate cannot fully provide this functionality. However, Hibernate can at least control data access operations, ensuring that database level deadlocks and queries with huge result sets are limited by a defined timeout.
*In a managed environment, Hibernate can delegate transaction timeout to JTA.

<pre>
Session sess = factory.openSession();
try {
//set transaction timeout to 3 seconds
sess.getTransaction().setTimeout(3);
sess.getTransaction().begin();
// do some work
...
sess.getTransaction().commit()
}
catch (RuntimeException e) {
sess.getTransaction().rollback();
throw e; // or display error message
}
finally {
sess.close();
}
</pre>

===Identify natural keys ===
*Even though we recommend the use of surrogate keys as primary keys, you should still try to identify natural keys for all entities.
*A natural key is a property or combination of properties that is unique and non-null. If it is also immutable, even better.
*Map the properties of the natural key inside the <natural-id> element. Hibernate will generate the necessary unique key and nullability constraints, and your mapping will be more selfdocumenting.
*We strongly recommend that you implement equals() and hashCode() to compare the natural key properties of the entity.
*This mapping is not intended for use with entities with natural primary keys..

Example in hbm.xml:
<pre>
<natural-id mutable="true|false"/>
<property ... />
<many-to-one ... />
......
</natural-id>
</pre>

=== Parameter Binding ===

Hibernate parameter binding works like prepared statements. An edge case it is, but say you had an already tainted string, and then used Query setters to bind more parameters to the "?" placeholders.

Example of proper use:
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();
</pre>

Improper use:
<pre>
Insert insert = new Insert(dialect);
insert.setComment(taint);
insert.addSelectColumn(columnName, alias);
String sql = insert.toQueryString();
....
Query query = sess.createQuery(sql); /*B00*///creating a Query with an already tainted string
query.setString(position, val); //this doesn't cleanse the damage that's been done.
....
transaction.commit(); //sink the ship
</pre>

=== Declare identifier properties on persistent classes ===

Hibernate makes identifier properties optional. There are all sorts of reasons why you should use them. Mapped classes must declare the primary key column of the database table. Most classes will also have a Java-Beans-style property holding the unique identifier of an instance. This is the easiest and most recommended route.
{{{
<class name="Summary">
<subselect>
select item.name, max(bid.amount), count(*)
from item
join bid on bid.item_id = item.id
group by item.name
</subselect>
<synchronize table="item"/>
<synchronize table="bid"/>
<id
name="propertyName" (1)
type="typename" (2)
column="column_name" (3)
unsaved-value="null|any|none|undefined|id_value" (4)
access="field|property|ClassName"> (5)
node="element-name|@attribute-name|element/@attribute|."
<generator class="generatorClass"/>
</id>
</class>
}}}

=== Don't use session.find() ===
This pretty much looks like a duplicate of sql injection but using the deprecated method find() instead. This rule was pulled straight from the best practice list from the reference manual.

If using Hibernate, do not use the depreciated session.find() method without using one of the query binding overloads. Using session.find() with direct user input allows the user input to be passed directly to the underlying SQL engine and will result in SQL injections on all supported RDBMS.

<pre>

Payment payment = (Payment) session.
find("from com.example.Payment as payment where payment.id = " + paymentIds.get(i));
</pre>

The above Hibernate HQL will allow SQL injection from paymentIds, which are obtained from the user. A safer way to express this is:

<pre>

int pId = paymentIds.get(i);

TsPayment payment = (TsPayment) session.
find("from com.example.Payment as payment where payment.id = ?", pId, StringType);

</pre>

=== Cache Management and !OutOfMemoryException ===

*The Session caches every object that is in persistent state (watched and checked for dirty state by Hibernate).
*Whenever you pass an object to save(), update() or saveOrUpdate() and whenever you retrieve an object using load(), get(), list(), iterate() or scroll(), that object is added to the internal cache of the Session.
*When flush() or commit() is subsequently called, the state of that object will be synchronized with the database.
*Otherwise it grows endlessly until you get an OutOfMemoryException, if you keep it open for a long time or simply load too much data.
*One solution for this is to call clear() and evict() to manage the Session cache, but you most likely should consider a Stored Procedure if you need mass data operations.
*Some solutions are shown in Chapter 13, Batch processing. Keeping a Session open for the duration of a user session also means a high probability of stale data.

In this example, it would fall over with an OutOfMemoryException somewhere around the 50 000th row. That's because Hibernate caches all the newly inserted Customer instances in the session-level cache.
<pre>
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
}
tx.commit();
session.close();
</pre>
When making new objects persistent, you must flush() and then clear() the session regularly, to control the

<pre>
size of the first-level cache.
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
if ( i % 20 == 0 ) { //20, same as the JDBC batch size
//flush a batch of inserts and release memory:
session.flush();
session.clear();
}
}
tx.commit();
session.close();
</pre>

=== About StatelessSession ===
*A StatelessSession has no persistence context associated with it and does not provide many of the higher-level life cycle semantics. In particular, a stateless session does not implement a first-level cache nor interact with any second-level or query cache.
*This may be used as a solution for the cache out of memory problem.
*Operations performed using a stateless session do not ever cascade to associated instances. Collections are ignored by a stateless session.
*The insert(), update() and delete() operations defined by the StatelessSession interface are considered
to be direct database row-level operations, which result in immediate execution of a SQL INSERT, UPDATE or
DELETE respectively.

Example of proper use:
<pre>
StatelessSession session = sessionFactory.openStatelessSession();
Transaction tx = session.beginTransaction();

ScrollableResults customers = session.getNamedQuery("GetCustomers")
.scroll(ScrollMode.FORWARD_ONLY);
while ( customers.next() ) {
Customer customer = (Customer) customers.get(0);
customer.updateStuff(...);
session.update(customer);
}
tx.commit();
session.close();
</pre>

=== Aboot POJOs ===
* You can tell what objects are the persistent ones by looking at the xxx.hbm.xml files.
* Persistent objects are usually POJO's with a default no-arg constructor so that Hibernate can instantiate them using Constructor.newInstance().
* It is recommended that these POJO's have a property that is explicitly mapped as a primary key.

<pre>
<hibernate-mapping>
<class entity-name="Customer">
<id name="id"
type="long"
column="ID">
<generator class="sequence"/>
</id>
......
</pre>

* Accessors and mutators should be declared for persistent fields - it is optional but is good practice because Hibernate persists JavaBeans style properties.

=== Session and Concurrency issues ===

*A Session is not thread-safe.
*Things which are supposed to work concurrently, like HTTP requests, session beans, or Swing workers, will cause race conditions if a Session instance would be shared.
*If you keep your Hibernate Session in your HttpSession, you should consider synchronizing access to your Http session.
*Otherwise, a user that clicks reload fast enough may use the same Session in two concurrently running threads.

=== The equals() and hashCode() problem: ===

*Most Java objects provide a built-in equals() and hashCode() based on the object's identity; so each new() object will be different from all others.
*If all your objects are in memory, this is a fine model, but Hibernate's whole job, of course, is to move your objects out of memory.
* Hibernate uses the Hibernate session to manage this uniqueness. When you create an object with new(), and then save it into a session, Hibernate now knows that whenever you query for an object and find that particular object, Hibernate should return you that instance of the object.
* However, once you close the Hibernate session, all bets are off. If you keep holding onto an object that you either created or loaded in a Hibernate session that you have now closed, Hibernate has no way to know about those objects.
* So if you open another session and query for "the same" object, Hibernate will return you a new instance. Hence, if you keep collections of objects around between sessions, you will start to experience odd behavior (duplicate objects in collections, mainly).
* '''Long story short equals() and hashCode() should be implemented to compare object properties and not just compare on the basis of identifier (the property mapped as the primary key see the above example). The problem is discussed in detail [http://www.hibernate.org/109.html here].'''

<pre>
public class Cat {
...
public boolean equals(Object other) {
if (this == other) return true;
if ( !(other instanceof Cat) ) return false;
final Cat cat = (Cat) other;
if ( !cat.getLitterId().equals( getLitterId() ) ) return false;
if ( !cat.getMother().equals( getMother() ) ) return false;
return true;
}
public int hashCode() {
int result;
result = getMother().hashCode();
result = 29 * result + getLitterId();
return result;
}
}
</pre>

=== Using Detached Objects ===
*In a three tiered architecture, consider using detached objects.
*When using a servlet / session bean architecture, you could pass persistent objects loaded in the session
bean to and from the servlet / JSP layer.
*Use a new session to service each request.
*Use Session.merge() or Session.saveOrUpdate() to synchronize objects with the database.
Usually update() or saveOrUpdate() are used in the following scenario:
*the application loads an object in the first session
*the object is passed up to the UI tier
*some modifications are made to the object
*the object is passed back down to the business logic tier
*the application persists these modifications by calling update() in a second session

<pre>
// in the first session
Cat cat = (Cat) firstSession.load(Cat.class, catID);
// in a higher tier of the application
Cat mate = new Cat();
cat.setMate(mate);
// later, in a new session
secondSession.saveOrUpdate(cat); // update existing state (cat has a non-null id)
secondSession.saveOrUpdate(mate); // save the new instance (mate has a null id)
</pre>

=== Consider externalising query strings ===

This is a good practice if your queries call non-ANSI-standard SQL functions. Externalising the query
strings to mapping files will make the application more portable.
It also decreases the likelihood of injection because the Query objects let you set individual parameters but not the entire query string - you can only do that when you pass the string into the Query implementation constructor or call Session.createQuery.
==== Edge cases are still possibilities! ====
*Basically the application would have to be messy enough to be binding parameters here, and concatenating variables there to the same query string.
*You can extract the query string using Query.getQueryString(), and although you can't manipulate the string and 'add' it back to the Query object, you could theoretically taint it and use it in another instance of Query. Dumb? yes. Possible? Yes.

==== So how to externalize? ====
You may define named queries in the mapping document.

<pre>
<query name="ByNameAndMaximumWeight"><![CDATA[
from eg.DomesticCat as cat
where cat.name = ?
and cat.weight > ?
] ]></query>
</pre>

Parameter binding and executing is done programatically:

<pre>
Query q = sess.getNamedQuery("ByNameAndMaximumWeight");
q.setString(0, name);
q.setInt(1, minWeight);
List cats = q.list();
</pre>

*Note that the actual program code is independent of the query language that is used, you may also define native
SQL queries in metadata, or migrate existing queries to Hibernate by placing them in mapping files.
*Also note that a query declaration inside a <hibernate-mapping> element requires a global unique name for the
query, while a query declaration inside a <class> element is made unique automatically by prepending the
fully qualified name of the class, for example eg.Cat.ByNameAndMaximumWeight.

[[Category:Hibernate]]
[[Category:OWASP Java Project]]
[[Category:Java]]

Hibernate

2008-06-05T18:37:28Z

Tehmina: /* Persisting tainted data */

== Status ==
'''In progress'''

== 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, I will address it now but discuss in detail later.
* 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.

== 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 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.

[http://en.wikipedia.org/wiki/Object-relational_mapping See original article. ]

=== How it works ===
* Usually Hibernate applications use [http://en.wikipedia.org/wiki/JavaBean JavaBeans] style [http://en.wikipedia.org/wiki/Plain_Old_Java_Object POJOs] to represent objects we want to persist in a database.
* These objects should have an identifier property (i.e private class variable) used to represent it's primary key value in the database.
* This identifier will be mapped in a hibernate mapping file, usually with the default extension .hbm.xml, you will see this mapping in the <id> element. This 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 stuff.
* 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() objects to a session, load() objects from a database and createQuery()s to be executed against the database.
* The Transaction object often wraps a database 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.
[http://www.owasp.org/index.php/Hibernate/config-example See this configuration example]

=== Jargon ===
*'''Transient''' - The instance is not associated with a Session, has no persistent representation in the database and no identifier assigned. An object that has just been instantiated with the new operator is said to be transient.
*'''Persistent''' - Is associated with a Session, has a representation in the database and has been assigned an identifier. Hibernate synchronizes changes on a persistent object with its representation in the database when it completes a unit of work.
*'''Detatched''' - was once in a persistent state, but its session has been closed. The reference is still valid and the object may be modified and even reattached to a new session later.

=== Hitting the database ===
The Session object represents the main interface or ''conversation'' between Java and Hibernate. A Session is used for a single request, or unit of work. To make an object persistent, it must first be associated with a Session. But where does the session come from? Hibernate's Configuration object instantiates a SessionFactory (Configuration.buildSessionFactory()) which is an expensive, immutable, thread safe object intended to be shared by all application threads. Threads that service client requests must obtain a Session from the factory by calling SessionFactory.getCurrentSession() or SessionFactory.openSession().

Anyways, a Session is NOT thread safe and there are associated concurrency issues discussed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Session_and_Concurrency_issues this section] of the Hibernate Guidelines page. Once an object is associated with a Session we can begin a transaction. All database communication must occur within the scope of a transaction. A transaction starts with a call to Transaction.begin() or Session.beginTransaction() and ends with a call to Transaction.commit().

To actually build queries, store and retrieve data we mostly use methods in the Session class. For example, load() will instantiate a class object, and load the state from the database into the instance. Session.createQuery() will return a Query object which has many methods with which to operate on this query string. Query.setParameter(), setFloat(), and others act similar to prepared statements. You can also simply call Query.executeUpdate() to execute the query.

''Ok, why don't we just see what it looks like.''
Example1
<pre>
Session sess = factory.openSession();
Transaction tx;
try {
tx = sess.beginTransaction();
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
tx.commit();
}
catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
finally {
sess.close();
}
</pre>
''Another simple example using HQL and named parameters...this time we have a helper class to obtain a Session''
<pre>
Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction(); //All database communication occurs within the scope of a transaction

Person aPerson = (Person) session
.createQuery("select p from Person p left join fetch p.events where p.id = :pid")
.setParameter("pid", personId);

session.getTransaction().commit();
</pre>

== Security Implications ==
These issues are discussed in context on this page and are also listed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Important this section] of Hibernate Guidelines.

* No communication with the database should occur outside of a database transaction. Doing so will probably result in synchronization issues. Transactions should also not encompass user think time. Details are of how it's done is discussed in the [http://www.owasp.org/index.php/Hibernate#Defining_Transaction_Bounds Defining Transaction Bounds section] of this page.

* createQuery() can easily be passed a tainted SQL or HQL string, dialect is irrelevant. The proper way to construct a sql string hibernate style is to use Query and SQLQuery's setParameter(), setString(), setXXX() methods for named parameter and placeholder binding. Just like prepared statements. Details are discussed in the [http://www.owasp.org/index.php/Hibernate#Creating_Queries Creating Queries section] of this page.

* Persisting tainted objects is stored xss. Since stored XSS is generally hard to find with static tools, it is best to sanitize all data going in rather than waiting for it to show up on a jsp somewhere. Details of these functions are discussed in the [http://www.owasp.org/index.php/Hibernate#Persisting_Tainted_Data Persisting Tainted Data section] of this page.

* An application should rollback and discard Session instance on error. So if the Session throws an exception, the catch block should have rollback() and finally should call Session.close(). This applies to any SQLException. Pretty cut and dry, see Example1 above.

* You may not mix and match JDBC-style parameters ("?") and named parameters (:namedparam) in the same query.
<pre>
Person aPerson = (Person) session
.createQuery("select :somenamedparameter from ? where x = :someothernamedparameter");
</pre>
* Transaction.setTimeout(int) should be called to ensure that misbehaving transactions do not tie up resources in definitely.
<pre>
Session sess = factory.openSession();
try {
//set transaction timeout to 3 seconds
sess.getTransaction().setTimeout(3);
sess.getTransaction().begin();
// do some work
...
</pre>

== Defining Transaction Bounds ==
Usually, ending a Session involves four distinct phases:

* flush the session
* commit the transaction
* close the session
* handle exceptions

Note:
* If commit() is present, no need to call flush() as it does this already.
* Most database communication methods only propagate exceptions if they're outside the scope of the session. (this is an assumption based on the many functions whose source I've examined, I won't be perusing the entire api source to back this assumption)

Consider this example:
<pre>
// Non-managed environment idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
tx = sess.beginTransaction();
// do some work
...
tx.commit();
}
catch (RuntimeException e) {
if (tx != null) tx.rollback();
throw e; // or display error message
}
finally {
sess.close();
}
</pre>
Most Common Functions:

* Session.beginTransaction() - begin transaction (doh)
* Session.getTransaction() - begin transaction
* Session.flush() - end transaction
* Session.close() - end session
* Transaction.begin() - begin transaction
* Transaction.commit() - end transaction
* Transaction.rollback() -

== Creating, manipulating and executing queries ==
* The Session interface defines methods that create Query and SQLQuery objects - these are the methods we care about because they allow the developer to construct query strings (as opposed to letting Hibernate perform the sql operations).
* The Query/SQLQuery objects are mutable and executable, but are not actually SUNK until Transaction.commit(), or Query.executeUpdate() is called. However, I think it is best that we flag functions that create and construct Query objects as they would be in direct contact with tainted data.
* Once a Query or SQLQuery object is obtained from the Session, the parameters of it's sql string should be set using the setter functions like setParameter(), the setters are listed here. These setters check for type mismatch, or guess the type, then check for positional mismatch and named parameter mismatch so they're pretty safe me thinks. Concatenating tainted parameters using the '+' operator, on the other hand, would be equivalent to mis-using a prepared-statement.

Consider this example:
<pre>
String table = (String) req.getParameter("table");//obviously retarded
String parameter1 = request.getParameter("param1");

Session session = sessionFactory.getCurrentSession();
try{
session.beginTransaction();
SQLQuery query = session.createSQLQuery("SELECT * FROM " + table + "WHERE stuff= ?"); /*B00*/
query.setParameter(0, parameter1); /*YAY*/
session.getTransaction().commit();
} catch (Exception e) {}
session.close();//omfg no rollback?
</pre>
Most Common Functions:

* Session.createSQLQuery(String queryString) - creates a Query with given SQL string - technically executed on commit() or flush() but this function is more directly related to the taint source.
* Session.createQuery(String queryString) - creates Query with given HQL string.
* Session.createFilter(Object collection, String queryString) - creates a Query with filter string.
* Query.setParameter() - variations on this binds parameters to "?" and ":namedparams"
* Query.executeUpdate() -
* Query.getQueryString() -

==== More Examples ====

Using queries from other Query's:
<pre>
String sql;

session.beginTransaction();
Query q1 = session.createQuery(taintSQL); //pretend taintSQL came from unchecked input
sql = q1.getQueryString(); //get taintSQL
session.getTransaction.commit();

session.beginTransaction();
Query q2 = new QueryImpl(sql, session, parameterMetadata); //reuse taintSQL w/o validation
session.getTransaction.commit(); //evil prevails
session.close();
</pre>
Using executeUpdate()
<pre>
public void executeUpdateHQL(Session session, String evil)//a few calls deep from where evil became tainted
{
Query query = session.createQuery(evil); /*B00*/
query.setString("name","Evil");
query.setString("newName","EEvil"); //these don't matter if the sql is already evil
int rowCount = query.executeUpdate(); /*B00*/
System.out.println("Rows affected: " + rowCount);

//See the results of the update and some other random stuff
query = session.createQuery("from Supplier");
List results = query.list();

displaySupplierList(results);
}
</pre>
named parameter (preferred)
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = :name");
q.setString("name", "Fritz");
Iterator cats = q.iterate();
</pre>
positional parameter
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();
</pre>
named parameter list
<pre>
List names = new ArrayList();
names.add("Izi");
names.add("Fritz");
Query q = sess.createQuery("from DomesticCat cat where cat.name in (:namesList)");
q.setParameterList("namesList", names);
List cats = q.list();
</pre>
Executing a bunch of actions (relevant fns listed in the excel sheet)
<pre>
private List executions;
....
executions = new LinkedList();
....
private void executeActions(List list) throws HibernateException {
for ( Iterator execItr = list.iterator(); execItr.hasNext(); ) {
execute( (Executable) execItr.next() );
}
list.clear();
session.getBatcher().executeBatch();
}
public void execute(Executable executable) {
final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
if (lockQueryCache) {
session.getFactory()
.getUpdateTimestampsCache()
.preinvalidate( executable.getPropertySpaces() );
}
executable.execute();
}
</pre>

== Persisting tainted data ==

* Assume persistent objects have JavaBeans style setter methods as this is most common practice. When these setters are called with tainted parameters consider this object to be tainted.
* We should flag all functions where tainted objects are made persistent. Although most documents will define Session.save() or Session.persist() as making an object persistent, it is actually PENDING until a call to Transaction.commit() is made. Whether or not we want to flag the saves, or the commits is up to scan dev - keep in mind that if we're flagging commit() we must first decide that the code between Transaction.begin() or Session.beginTransaction() and Transaction.commit() contains eevil.
* The only associated cwe I can think of right now is stored xss.

Consider this example:
<pre>
Session session = sessionFactory.getCurrentSession();
String firstname = req.getParameter("firstname");
String lastname = request.getParameter("lastname");

try{
Transaction tx = session.beginTransaction();

Person thePerson = session.load(Person.class, new Long(69));//loading an already persistent object
thePerson.setFirstname(firstname);// then adding tainted data to it
thePerson.setLastname(lastname);
session.save(thePerson); //persisting our changes

session.getTransaction().commit();
} catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
session.close();
</pre>
Most Common Functions:

* Session.save(Object object) - save object to the session, object should not contain tainted data.
* Session.persist(Object object) -
* Session.void replicate(Object object, ReplicationMode?? replicationMode) -
* Session.void saveOrUpdate(Object object) -
* Session.update(Object object)() -
* Session.evict(Object object)() - remove instance from session cache
* Session.clear() - evict all loaded instances
* Session.load(Class theClass, Serializable id) - gets an object from the db for you to manipulate.

[[Category:Hibernate]]
[[Category:OWASP Java Project]]
[[Category:Java]]

Hibernate

2008-06-05T18:35:16Z

Tehmina:

Hibernate

2008-06-05T17:31:00Z

Tehmina: /* Creating, manipulating and executing queries */

== Status ==
== Headline text ==

'''In progress'''
== 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, I will address it now but discuss in detail later.
* 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.

== 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 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.

[http://en.wikipedia.org/wiki/Object-relational_mapping See original article. ]

=== How it works ===
* Usually Hibernate applications use [http://en.wikipedia.org/wiki/JavaBean JavaBeans] style [http://en.wikipedia.org/wiki/Plain_Old_Java_Object POJOs] to represent objects we want to persist in a database.
* These objects should have an identifier property (i.e private class variable) used to represent it's primary key value in the database.
* This identifier will be mapped in a hibernate mapping file, usually with the default extension .hbm.xml, you will see this mapping in the <id> element. This 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 stuff.
* 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() objects to a session, load() objects from a database and createQuery()s to be executed against the database.
* The Transaction object often wraps a database 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.
[http://www.owasp.org/index.php/Hibernate/config-example See this configuration example]

=== Jargon ===
*'''Transient''' - The instance is not associated with a Session, has no persistent representation in the database and no identifier assigned. An object that has just been instantiated with the new operator is said to be transient.
*'''Persistent''' - Is associated with a Session, has a representation in the database and has been assigned an identifier. Hibernate synchronizes changes on a persistent object with its representation in the database when it completes a unit of work.
*'''Detatched''' - was once in a persistent state, but its session has been closed. The reference is still valid and the object may be modified and even reattached to a new session later.

=== Hitting the database ===
The Session object represents the main interface or ''conversation'' between Java and Hibernate. A Session is used for a single request, or unit of work. To make an object persistent, it must first be associated with a Session. But where does the session come from? Hibernate's Configuration object instantiates a SessionFactory (Configuration.buildSessionFactory()) which is an expensive, immutable, thread safe object intended to be shared by all application threads. Threads that service client requests must obtain a Session from the factory by calling SessionFactory.getCurrentSession() or SessionFactory.openSession().

Anyways, a Session is NOT thread safe and there are associated concurrency issues discussed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Session_and_Concurrency_issues this section] of the Hibernate Guidelines page. Once an object is associated with a Session we can begin a transaction. All database communication must occur within the scope of a transaction. A transaction starts with a call to Transaction.begin() or Session.beginTransaction() and ends with a call to Transaction.commit().

To actually build queries, store and retrieve data we mostly use methods in the Session class. For example, load() will instantiate a class object, and load the state from the database into the instance. Session.createQuery() will return a Query object which has many methods with which to operate on this query string. Query.setParameter(), setFloat(), and others act similar to prepared statements. You can also simply call Query.executeUpdate() to execute the query.

''Ok, why don't we just see what it looks like.''
Example1
<pre>
Session sess = factory.openSession();
Transaction tx;
try {
tx = sess.beginTransaction();
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
tx.commit();
}
catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
finally {
sess.close();
}
</pre>
''Another simple example using HQL and named parameters...this time we have a helper class to obtain a Session''
<pre>
Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction(); //All database communication occurs within the scope of a transaction

Person aPerson = (Person) session
.createQuery("select p from Person p left join fetch p.events where p.id = :pid")
.setParameter("pid", personId);

session.getTransaction().commit();
</pre>

== Security Implications ==
These issues are discussed in context on this page and are also listed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Important this section] of Hibernate Guidelines.

* No communication with the database should occur outside of a database transaction. Doing so will probably result in synchronization issues. Transactions should also not encompass user think time. Details are of how it's done is discussed in the [http://www.owasp.org/index.php/Hibernate#Defining_Transaction_Bounds Defining Transaction Bounds section] of this page.

* createQuery() can easily be passed a tainted SQL or HQL string, dialect is irrelevant. The proper way to construct a sql string hibernate style is to use Query and SQLQuery's setParameter(), setString(), setXXX() methods for named parameter and placeholder binding. Just like prepared statements. Details are discussed in the [http://www.owasp.org/index.php/Hibernate#Creating_Queries Creating Queries section] of this page.

* Persisting tainted objects is stored xss. Since stored XSS is generally hard to find with static tools, it is best to sanitize all data going in rather than waiting for it to show up on a jsp somewhere. Details of these functions are discussed in the [http://www.owasp.org/index.php/Hibernate#Persisting_Tainted_Data Persisting Tainted Data section] of this page.

* An application should rollback and discard Session instance on error. So if the Session throws an exception, the catch block should have rollback() and finally should call Session.close(). This applies to any SQLException. Pretty cut and dry, see Example1 above.

* You may not mix and match JDBC-style parameters ("?") and named parameters (:namedparam) in the same query.
<pre>
Person aPerson = (Person) session
.createQuery("select :somenamedparameter from ? where x = :someothernamedparameter");
</pre>
* Transaction.setTimeout(int) should be called to ensure that misbehaving transactions do not tie up resources in definitely.
<pre>
Session sess = factory.openSession();
try {
//set transaction timeout to 3 seconds
sess.getTransaction().setTimeout(3);
sess.getTransaction().begin();
// do some work
...
</pre>

== Defining Transaction Bounds ==
Usually, ending a Session involves four distinct phases:

* flush the session
* commit the transaction
* close the session
* handle exceptions

Note:
* If commit() is present, no need to call flush() as it does this already.
* Most database communication methods only propagate exceptions if they're outside the scope of the session. (this is an assumption based on the many functions whose source I've examined, I won't be perusing the entire api source to back this assumption)

Consider this example:
<pre>
// Non-managed environment idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
tx = sess.beginTransaction();
// do some work
...
tx.commit();
}
catch (RuntimeException e) {
if (tx != null) tx.rollback();
throw e; // or display error message
}
finally {
sess.close();
}
</pre>
Most Common Functions:

* Session.beginTransaction() - begin transaction (doh)
* Session.getTransaction() - begin transaction
* Session.flush() - end transaction
* Session.close() - end session
* Transaction.begin() - begin transaction
* Transaction.commit() - end transaction
* Transaction.rollback() -

== Creating, manipulating and executing queries ==
* The Session interface defines methods that create Query and SQLQuery objects - these are the methods we care about because they allow the developer to construct query strings (as opposed to letting Hibernate perform the sql operations).
* The Query/SQLQuery objects are mutable and executable, but are not actually SUNK until Transaction.commit(), or Query.executeUpdate() is called. However, I think it is best that we flag functions that create and construct Query objects as they would be in direct contact with tainted data.
* Once a Query or SQLQuery object is obtained from the Session, the parameters of it's sql string should be set using the setter functions like setParameter(), the setters are listed here. These setters check for type mismatch, or guess the type, then check for positional mismatch and named parameter mismatch so they're pretty safe me thinks. Concatenating tainted parameters using the '+' operator, on the other hand, would be equivalent to mis-using a prepared-statement.

Consider this example:
<pre>
String table = (String) req.getParameter("table");//obviously retarded
String parameter1 = request.getParameter("param1");

Session session = sessionFactory.getCurrentSession();
try{
session.beginTransaction();
SQLQuery query = session.createSQLQuery("SELECT * FROM " + table + "WHERE stuff= ?"); /*B00*/
query.setParameter(0, parameter1); /*YAY*/
session.getTransaction().commit();
} catch (Exception e) {}
session.close();//omfg no rollback?
</pre>
Most Common Functions:

* Session.createSQLQuery(String queryString) - creates a Query with given SQL string - technically executed on commit() or flush() but this function is more directly related to the taint source.
* Session.createQuery(String queryString) - creates Query with given HQL string.
* Session.createFilter(Object collection, String queryString) - creates a Query with filter string.
* Query.setParameter() - variations on this binds parameters to "?" and ":namedparams"
* Query.executeUpdate() -
* Query.getQueryString() -

==== More Examples ====

Using queries from other Query's:
<pre>
String sql;

session.beginTransaction();
Query q1 = session.createQuery(taintSQL); //pretend taintSQL came from unchecked input
sql = q1.getQueryString(); //get taintSQL
session.getTransaction.commit();

session.beginTransaction();
Query q2 = new QueryImpl(sql, session, parameterMetadata); //reuse taintSQL w/o validation
session.getTransaction.commit(); //evil prevails
session.close();
</pre>
Using executeUpdate()
<pre>
public void executeUpdateHQL(Session session, String evil)//a few calls deep from where evil became tainted
{
Query query = session.createQuery(evil); /*B00*/
query.setString("name","Evil");
query.setString("newName","EEvil"); //these don't matter if the sql is already evil
int rowCount = query.executeUpdate(); /*B00*/
System.out.println("Rows affected: " + rowCount);

//See the results of the update and some other random stuff
query = session.createQuery("from Supplier");
List results = query.list();

displaySupplierList(results);
}
</pre>
named parameter (preferred)
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = :name");
q.setString("name", "Fritz");
Iterator cats = q.iterate();
</pre>
positional parameter
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();
</pre>
named parameter list
<pre>
List names = new ArrayList();
names.add("Izi");
names.add("Fritz");
Query q = sess.createQuery("from DomesticCat cat where cat.name in (:namesList)");
q.setParameterList("namesList", names);
List cats = q.list();
</pre>
Executing a bunch of actions (relevant fns listed in the excel sheet)
<pre>
private List executions;
....
executions = new LinkedList();
....
private void executeActions(List list) throws HibernateException {
for ( Iterator execItr = list.iterator(); execItr.hasNext(); ) {
execute( (Executable) execItr.next() );
}
list.clear();
session.getBatcher().executeBatch();
}
public void execute(Executable executable) {
final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
if (lockQueryCache) {
session.getFactory()
.getUpdateTimestampsCache()
.preinvalidate( executable.getPropertySpaces() );
}
executable.execute();
}
</pre>

== Persisting tainted data ==

* Assume persistent objects have JavaBeans style setter methods as this is most common practice. When these setters are called with tainted parameters consider this object to be tainted.
* We should flag all functions where tainted objects are made persistent. Although most documents will define Session.save() or Session.persist() as making an object persistent, it is actually PENDING until a call to Transaction.commit() is made. Whether or not we want to flag the saves, or the commits is up to scan dev - keep in mind that if we're flagging commit() we must first decide that the code between Transaction.begin() or Session.beginTransaction() and Transaction.commit() contains eevil.
* The only associated cwe I can think of right now is stored xss.

Consider this example:
<pre>
Session session = sessionFactory.getCurrentSession();
String firstname = req.getParameter("firstname");
String lastname = request.getParameter("lastname");

try{
Transaction tx = session.beginTransaction();

Person thePerson = session.load(Person.class, new Long(69));//loading an already persistent object
thePerson.setFirstname(firstname);// then adding tainted data to it
thePerson.setLastname(lastname);
session.save(thePerson); //persisting our changes

session.getTransaction().commit();
} catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
session.close();
</pre>
Most Common Functions:

* Session.save(Object object) - save object to the session, object should not contain tainted data.
* Session.persist(Object object) -
* Session.void replicate(Object object, ReplicationMode?? replicationMode) -
* Session.void saveOrUpdate(Object object) -
* Session.update(Object object)() -
* Session.evict(Object object)() - remove instance from session cache
* Session.clear() - evict all loaded instances
* Session.load(Class theClass, Serializable id) - gets an object from the db for you to manipulate.

[[Category:Hibernate]]

Hibernate

2008-06-05T17:28:37Z

Tehmina: /* Persisting tainted data */

== Status ==
== Headline text ==

'''In progress'''
== 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, I will address it now but discuss in detail later.
* 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.

== 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 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.

[http://en.wikipedia.org/wiki/Object-relational_mapping See original article. ]

=== How it works ===
* Usually Hibernate applications use [http://en.wikipedia.org/wiki/JavaBean JavaBeans] style [http://en.wikipedia.org/wiki/Plain_Old_Java_Object POJOs] to represent objects we want to persist in a database.
* These objects should have an identifier property (i.e private class variable) used to represent it's primary key value in the database.
* This identifier will be mapped in a hibernate mapping file, usually with the default extension .hbm.xml, you will see this mapping in the <id> element. This 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 stuff.
* 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() objects to a session, load() objects from a database and createQuery()s to be executed against the database.
* The Transaction object often wraps a database 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.
[http://www.owasp.org/index.php/Hibernate/config-example See this configuration example]

=== Jargon ===
*'''Transient''' - The instance is not associated with a Session, has no persistent representation in the database and no identifier assigned. An object that has just been instantiated with the new operator is said to be transient.
*'''Persistent''' - Is associated with a Session, has a representation in the database and has been assigned an identifier. Hibernate synchronizes changes on a persistent object with its representation in the database when it completes a unit of work.
*'''Detatched''' - was once in a persistent state, but its session has been closed. The reference is still valid and the object may be modified and even reattached to a new session later.

=== Hitting the database ===
The Session object represents the main interface or ''conversation'' between Java and Hibernate. A Session is used for a single request, or unit of work. To make an object persistent, it must first be associated with a Session. But where does the session come from? Hibernate's Configuration object instantiates a SessionFactory (Configuration.buildSessionFactory()) which is an expensive, immutable, thread safe object intended to be shared by all application threads. Threads that service client requests must obtain a Session from the factory by calling SessionFactory.getCurrentSession() or SessionFactory.openSession().

Anyways, a Session is NOT thread safe and there are associated concurrency issues discussed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Session_and_Concurrency_issues this section] of the Hibernate Guidelines page. Once an object is associated with a Session we can begin a transaction. All database communication must occur within the scope of a transaction. A transaction starts with a call to Transaction.begin() or Session.beginTransaction() and ends with a call to Transaction.commit().

To actually build queries, store and retrieve data we mostly use methods in the Session class. For example, load() will instantiate a class object, and load the state from the database into the instance. Session.createQuery() will return a Query object which has many methods with which to operate on this query string. Query.setParameter(), setFloat(), and others act similar to prepared statements. You can also simply call Query.executeUpdate() to execute the query.

''Ok, why don't we just see what it looks like.''
Example1
<pre>
Session sess = factory.openSession();
Transaction tx;
try {
tx = sess.beginTransaction();
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
tx.commit();
}
catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
finally {
sess.close();
}
</pre>
''Another simple example using HQL and named parameters...this time we have a helper class to obtain a Session''
<pre>
Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction(); //All database communication occurs within the scope of a transaction

Person aPerson = (Person) session
.createQuery("select p from Person p left join fetch p.events where p.id = :pid")
.setParameter("pid", personId);

session.getTransaction().commit();
</pre>

== Security Implications ==
These issues are discussed in context on this page and are also listed in [https://www.owasp.org/index.php/Hibernate-Guidelines#Important this section] of Hibernate Guidelines.

* No communication with the database should occur outside of a database transaction. Doing so will probably result in synchronization issues. Transactions should also not encompass user think time. Details are of how it's done is discussed in the [http://www.owasp.org/index.php/Hibernate#Defining_Transaction_Bounds Defining Transaction Bounds section] of this page.

* createQuery() can easily be passed a tainted SQL or HQL string, dialect is irrelevant. The proper way to construct a sql string hibernate style is to use Query and SQLQuery's setParameter(), setString(), setXXX() methods for named parameter and placeholder binding. Just like prepared statements. Details are discussed in the [http://www.owasp.org/index.php/Hibernate#Creating_Queries Creating Queries section] of this page.

* Persisting tainted objects is stored xss. Since stored XSS is generally hard to find with static tools, it is best to sanitize all data going in rather than waiting for it to show up on a jsp somewhere. Details of these functions are discussed in the [http://www.owasp.org/index.php/Hibernate#Persisting_Tainted_Data Persisting Tainted Data section] of this page.

* An application should rollback and discard Session instance on error. So if the Session throws an exception, the catch block should have rollback() and finally should call Session.close(). This applies to any SQLException. Pretty cut and dry, see Example1 above.

* You may not mix and match JDBC-style parameters ("?") and named parameters (:namedparam) in the same query.
<pre>
Person aPerson = (Person) session
.createQuery("select :somenamedparameter from ? where x = :someothernamedparameter");
</pre>
* Transaction.setTimeout(int) should be called to ensure that misbehaving transactions do not tie up resources in definitely.
<pre>
Session sess = factory.openSession();
try {
//set transaction timeout to 3 seconds
sess.getTransaction().setTimeout(3);
sess.getTransaction().begin();
// do some work
...
</pre>

== Defining Transaction Bounds ==
Usually, ending a Session involves four distinct phases:

* flush the session
* commit the transaction
* close the session
* handle exceptions

Note:
* If commit() is present, no need to call flush() as it does this already.
* Most database communication methods only propagate exceptions if they're outside the scope of the session. (this is an assumption based on the many functions whose source I've examined, I won't be perusing the entire api source to back this assumption)

Consider this example:
<pre>
// Non-managed environment idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
tx = sess.beginTransaction();
// do some work
...
tx.commit();
}
catch (RuntimeException e) {
if (tx != null) tx.rollback();
throw e; // or display error message
}
finally {
sess.close();
}
</pre>
Most Common Functions:

* Session.beginTransaction() - begin transaction (doh)
* Session.getTransaction() - begin transaction
* Session.flush() - end transaction
* Session.close() - end session
* Transaction.begin() - begin transaction
* Transaction.commit() - end transaction
* Transaction.rollback() -

== Creating, manipulating and executing queries ==
* The Session interface defines methods that create Query and SQLQuery objects - these are the methods we care about because they allow the developer to construct query strings (as opposed to letting Hibernate perform the sql operations).
* The Query/SQLQuery objects are mutable and executable, but are not actually SUNK until Transaction.commit(), or Query.executeUpdate() is called. However, I think it is best that we flag functions that create and construct Query objects as they would be in direct contact with tainted data.
* Once a Query or SQLQuery object is obtained from the Session, the parameters of it's sql string should be set using the setter functions like setParameter(), the setters are listed here. These setters check for type mismatch, or guess the type, then check for positional mismatch and named parameter mismatch so they're pretty safe me thinks. Concatenating tainted parameters using the '+' operator, on the other hand, would be equivalent to mis-using a prepared-statement.

Consider this example:
<pre>
String table = (String) req.getParameter("table");//obviously retarded
String parameter1 = request.getParameter("param1");

Session session = sessionFactory.getCurrentSession();
try{
session.beginTransaction();
SQLQuery query = session.createSQLQuery("SELECT * FROM " + table + "WHERE stuff= ?"); /*B00*/
query.setParameter(0, parameter1); /*YAY*/
session.getTransaction().commit();
} catch (Exception e) {}
session.close();//omfg no rollback?
</pre>
Most Common Functions:

* Session.createSQLQuery(String queryString) - creates a Query with given SQL string - technically executed on commit() or flush() but this function is more directly related to the taint source.
* Session.createQuery(String queryString) - creates Query with given HQL string.
* Session.createFilter(Object collection, String queryString) - creates a Query with filter string.
* Query.setParameter() - variations on this binds parameters to "?" and ":namedparams"
* Query.executeUpdate() -
* Query.getQueryString() -

== Persisting tainted data ==

* Assume persistent objects have JavaBeans style setter methods as this is most common practice. When these setters are called with tainted parameters consider this object to be tainted.
* We should flag all functions where tainted objects are made persistent. Although most documents will define Session.save() or Session.persist() as making an object persistent, it is actually PENDING until a call to Transaction.commit() is made. Whether or not we want to flag the saves, or the commits is up to scan dev - keep in mind that if we're flagging commit() we must first decide that the code between Transaction.begin() or Session.beginTransaction() and Transaction.commit() contains eevil.
* The only associated cwe I can think of right now is stored xss.

Consider this example:
<pre>
Session session = sessionFactory.getCurrentSession();
String firstname = req.getParameter("firstname");
String lastname = request.getParameter("lastname");

try{
Transaction tx = session.beginTransaction();

Person thePerson = session.load(Person.class, new Long(69));//loading an already persistent object
thePerson.setFirstname(firstname);// then adding tainted data to it
thePerson.setLastname(lastname);
session.save(thePerson); //persisting our changes

session.getTransaction().commit();
} catch (Exception e) {
if (tx!=null) tx.rollback();
throw e;
}
session.close();
</pre>
Most Common Functions:

* Session.save(Object object) - save object to the session, object should not contain tainted data.
* Session.persist(Object object) -
* Session.void replicate(Object object, ReplicationMode?? replicationMode) -
* Session.void saveOrUpdate(Object object) -
* Session.update(Object object)() -
* Session.evict(Object object)() - remove instance from session cache
* Session.clear() - evict all loaded instances
* Session.load(Class theClass, Serializable id) - gets an object from the db for you to manipulate.

[[Category:Hibernate]]

Hibernate

Hibernate-Guidelines

2008-06-05T16:32:37Z

Tehmina: /* Status */

== Status ==
'''In progress'''

== Important ==
=== SQL Injection ===

It is commonly thought that ORM layers, like Hibernate are immune to SQL injection. This is not the case as Hibernate includes a subset of SQL called HQL, and allows "native" SQL queries. Often the ORM layer only minimally manipulates the inbound query before handing it off to the database for processing.

=== Transaction Scope ===

All database communication should occur within the scope of a Transaction. Although we can't anticipate all design patterns, it would be an easy scan to flag jdbc and hibernate calls outside of transactions in a Hibernate application.

=== Persisting Tainted Data ===

If an application sets tainted properties in an object, then makes that object persistent, it is highly likely that data will be accessed at some point and displayed. If database values are never displayed to the user then obviously this is nullified. Better yet if we could figure out which values from the db are tainted but I have a feeling it's not a feasible scan. Long story short - saves, updates, inserts, whatever that are made with tainted objects should be flagged.

=== Rollback ===

When an exception occurs, roll back the Transaction and close the Session. If you don't, Hibernate can't guarantee that in-memory state accurately represents persistent state.
If your Session is bound to the application, you have to stop the application. Rolling back the database transaction doesn't put your business objects back into the state they were at the start of the transaction, so the database state and the business objects do get out of sync. Objects that are manipulated after a rollback as if they were synchronized.

----

== Simple ==

=== Don't use load() to determine existence ===
Do not use Session.load() to determine if an instance with the given identifier exists on the database; use Session.get() or a query instead. This is a poss

=== Constructing Query Strings ===
Hibernate has a set of functions that are used internally to construct their query strings, but there is no limit to using them in application code - what if they were used with tainted data? This is pretty self explanatory.

=== Place each class mapping in its own file ===
Don't use a single monolithic mapping document. Map com.eg.Foo in the file com/eg/Foo.hbm.xml. This makes particularly good sense in a team environment. Nothing more than a app dev good practice.

=== Use bind variables ===
As in JDBC, always replace non-constant values by "?". Never use string manipulation to bind a nonconstant value in a query! Even better, consider using named parameters in queries.

=== Load mappings as resources ===
Deploy the mappings along with the classes they map.

----

== Detailed ==

=== Transaction Timeout ===
*Transaction timeouts ensure that no misbehaving transaction can indefinitely tie up resources while returning no response to the user.
*Outside a managed (JTA) environment, Hibernate cannot fully provide this functionality. However, Hibernate can at least control data access operations, ensuring that database level deadlocks and queries with huge result sets are limited by a defined timeout.
*In a managed environment, Hibernate can delegate transaction timeout to JTA.

<pre>
Session sess = factory.openSession();
try {
//set transaction timeout to 3 seconds
sess.getTransaction().setTimeout(3);
sess.getTransaction().begin();
// do some work
...
sess.getTransaction().commit()
}
catch (RuntimeException e) {
sess.getTransaction().rollback();
throw e; // or display error message
}
finally {
sess.close();
}
</pre>

===Identify natural keys ===
*Even though we recommend the use of surrogate keys as primary keys, you should still try to identify natural keys for all entities.
*A natural key is a property or combination of properties that is unique and non-null. If it is also immutable, even better.
*Map the properties of the natural key inside the <natural-id> element. Hibernate will generate the necessary unique key and nullability constraints, and your mapping will be more selfdocumenting.
*We strongly recommend that you implement equals() and hashCode() to compare the natural key properties of the entity.
*This mapping is not intended for use with entities with natural primary keys..

Example in hbm.xml:
<pre>
<natural-id mutable="true|false"/>
<property ... />
<many-to-one ... />
......
</natural-id>
</pre>

=== Parameter Binding ===

Hibernate parameter binding works like prepared statements. An edge case it is, but say you had an already tainted string, and then used Query setters to bind more parameters to the "?" placeholders.

Example of proper use:
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();
</pre>

Improper use:
<pre>
Insert insert = new Insert(dialect);
insert.setComment(taint);
insert.addSelectColumn(columnName, alias);
String sql = insert.toQueryString();
....
Query query = sess.createQuery(sql); /*B00*///creating a Query with an already tainted string
query.setString(position, val); //this doesn't cleanse the damage that's been done.
....
transaction.commit(); //sink the ship
</pre>

=== Declare identifier properties on persistent classes ===

Hibernate makes identifier properties optional. There are all sorts of reasons why you should use them. Mapped classes must declare the primary key column of the database table. Most classes will also have a Java-Beans-style property holding the unique identifier of an instance. This is the easiest and most recommended route.
{{{
<class name="Summary">
<subselect>
select item.name, max(bid.amount), count(*)
from item
join bid on bid.item_id = item.id
group by item.name
</subselect>
<synchronize table="item"/>
<synchronize table="bid"/>
<id
name="propertyName" (1)
type="typename" (2)
column="column_name" (3)
unsaved-value="null|any|none|undefined|id_value" (4)
access="field|property|ClassName"> (5)
node="element-name|@attribute-name|element/@attribute|."
<generator class="generatorClass"/>
</id>
</class>
}}}

=== Don't use session.find() ===
This pretty much looks like a duplicate of sql injection but using the deprecated method find() instead. This rule was pulled straight from the best practice list from the reference manual.

If using Hibernate, do not use the depreciated session.find() method without using one of the query binding overloads. Using session.find() with direct user input allows the user input to be passed directly to the underlying SQL engine and will result in SQL injections on all supported RDBMS.

<pre>

Payment payment = (Payment) session.
find("from com.example.Payment as payment where payment.id = " + paymentIds.get(i));
</pre>

The above Hibernate HQL will allow SQL injection from paymentIds, which are obtained from the user. A safer way to express this is:

<pre>

int pId = paymentIds.get(i);

TsPayment payment = (TsPayment) session.
find("from com.example.Payment as payment where payment.id = ?", pId, StringType);

</pre>

=== Cache Management and !OutOfMemoryException ===

*The Session caches every object that is in persistent state (watched and checked for dirty state by Hibernate).
*Whenever you pass an object to save(), update() or saveOrUpdate() and whenever you retrieve an object using load(), get(), list(), iterate() or scroll(), that object is added to the internal cache of the Session.
*When flush() or commit() is subsequently called, the state of that object will be synchronized with the database.
*Otherwise it grows endlessly until you get an OutOfMemoryException, if you keep it open for a long time or simply load too much data.
*One solution for this is to call clear() and evict() to manage the Session cache, but you most likely should consider a Stored Procedure if you need mass data operations.
*Some solutions are shown in Chapter 13, Batch processing. Keeping a Session open for the duration of a user session also means a high probability of stale data.

In this example, it would fall over with an OutOfMemoryException somewhere around the 50 000th row. That's because Hibernate caches all the newly inserted Customer instances in the session-level cache.
<pre>
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
}
tx.commit();
session.close();
</pre>
When making new objects persistent, you must flush() and then clear() the session regularly, to control the

<pre>
size of the first-level cache.
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
if ( i % 20 == 0 ) { //20, same as the JDBC batch size
//flush a batch of inserts and release memory:
session.flush();
session.clear();
}
}
tx.commit();
session.close();
</pre>

=== About StatelessSession ===
*A StatelessSession has no persistence context associated with it and does not provide many of the higher-level life cycle semantics. In particular, a stateless session does not implement a first-level cache nor interact with any second-level or query cache.
*This may be used as a solution for the cache out of memory problem.
*Operations performed using a stateless session do not ever cascade to associated instances. Collections are ignored by a stateless session.
*The insert(), update() and delete() operations defined by the StatelessSession interface are considered
to be direct database row-level operations, which result in immediate execution of a SQL INSERT, UPDATE or
DELETE respectively.

Example of proper use:
<pre>
StatelessSession session = sessionFactory.openStatelessSession();
Transaction tx = session.beginTransaction();

ScrollableResults customers = session.getNamedQuery("GetCustomers")
.scroll(ScrollMode.FORWARD_ONLY);
while ( customers.next() ) {
Customer customer = (Customer) customers.get(0);
customer.updateStuff(...);
session.update(customer);
}
tx.commit();
session.close();
</pre>

=== Aboot POJOs ===
* You can tell what objects are the persistent ones by looking at the xxx.hbm.xml files.
* Persistent objects are usually POJO's with a default no-arg constructor so that Hibernate can instantiate them using Constructor.newInstance().
* It is recommended that these POJO's have a property that is explicitly mapped as a primary key.

<pre>
<hibernate-mapping>
<class entity-name="Customer">
<id name="id"
type="long"
column="ID">
<generator class="sequence"/>
</id>
......
</pre>

* Accessors and mutators should be declared for persistent fields - it is optional but is good practice because Hibernate persists JavaBeans style properties.

=== Session and Concurrency issues ===

*A Session is not thread-safe.
*Things which are supposed to work concurrently, like HTTP requests, session beans, or Swing workers, will cause race conditions if a Session instance would be shared.
*If you keep your Hibernate Session in your HttpSession, you should consider synchronizing access to your Http session.
*Otherwise, a user that clicks reload fast enough may use the same Session in two concurrently running threads.

=== The equals() and hashCode() problem: ===

*Most Java objects provide a built-in equals() and hashCode() based on the object's identity; so each new() object will be different from all others.
*If all your objects are in memory, this is a fine model, but Hibernate's whole job, of course, is to move your objects out of memory.
* Hibernate uses the Hibernate session to manage this uniqueness. When you create an object with new(), and then save it into a session, Hibernate now knows that whenever you query for an object and find that particular object, Hibernate should return you that instance of the object.
* However, once you close the Hibernate session, all bets are off. If you keep holding onto an object that you either created or loaded in a Hibernate session that you have now closed, Hibernate has no way to know about those objects.
* So if you open another session and query for "the same" object, Hibernate will return you a new instance. Hence, if you keep collections of objects around between sessions, you will start to experience odd behavior (duplicate objects in collections, mainly).
* '''Long story short equals() and hashCode() should be implemented to compare object properties and not just compare on the basis of identifier (the property mapped as the primary key see the above example). The problem is discussed in detail [http://www.hibernate.org/109.html here].'''

<pre>
public class Cat {
...
public boolean equals(Object other) {
if (this == other) return true;
if ( !(other instanceof Cat) ) return false;
final Cat cat = (Cat) other;
if ( !cat.getLitterId().equals( getLitterId() ) ) return false;
if ( !cat.getMother().equals( getMother() ) ) return false;
return true;
}
public int hashCode() {
int result;
result = getMother().hashCode();
result = 29 * result + getLitterId();
return result;
}
}
</pre>

=== Using Detached Objects ===
*In a three tiered architecture, consider using detached objects.
*When using a servlet / session bean architecture, you could pass persistent objects loaded in the session
bean to and from the servlet / JSP layer.
*Use a new session to service each request.
*Use Session.merge() or Session.saveOrUpdate() to synchronize objects with the database.
Usually update() or saveOrUpdate() are used in the following scenario:
*the application loads an object in the first session
*the object is passed up to the UI tier
*some modifications are made to the object
*the object is passed back down to the business logic tier
*the application persists these modifications by calling update() in a second session

<pre>
// in the first session
Cat cat = (Cat) firstSession.load(Cat.class, catID);
// in a higher tier of the application
Cat mate = new Cat();
cat.setMate(mate);
// later, in a new session
secondSession.saveOrUpdate(cat); // update existing state (cat has a non-null id)
secondSession.saveOrUpdate(mate); // save the new instance (mate has a null id)
</pre>

=== Consider externalising query strings ===

This is a good practice if your queries call non-ANSI-standard SQL functions. Externalising the query
strings to mapping files will make the application more portable.
It also decreases the likelihood of injection because the Query objects let you set individual parameters but not the entire query string - you can only do that when you pass the string into the Query implementation constructor or call Session.createQuery.
==== Edge cases are still possibilities! ====
*Basically the application would have to be messy enough to be binding parameters here, and concatenating variables there to the same query string.
*You can extract the query string using Query.getQueryString(), and although you can't manipulate the string and 'add' it back to the Query object, you could theoretically taint it and use it in another instance of Query. Dumb? yes. Possible? Yes.

==== So how to externalize? ====
You may define named queries in the mapping document.

<pre>
<query name="ByNameAndMaximumWeight"><![CDATA[
from eg.DomesticCat as cat
where cat.name = ?
and cat.weight > ?
] ]></query>
</pre>

Parameter binding and executing is done programatically:

<pre>
Query q = sess.getNamedQuery("ByNameAndMaximumWeight");
q.setString(0, name);
q.setInt(1, minWeight);
List cats = q.list();
</pre>

*Note that the actual program code is independent of the query language that is used, you may also define native
SQL queries in metadata, or migrate existing queries to Hibernate by placing them in mapping files.
*Also note that a query declaration inside a <hibernate-mapping> element requires a global unique name for the
query, while a query declaration inside a <class> element is made unique automatically by prepending the
fully qualified name of the class, for example eg.Cat.ByNameAndMaximumWeight.

[[Category:Hibernate]]

Hibernate-Guidelines

2008-06-05T16:31:45Z

Tehmina:

== Status ==

== Important ==
=== SQL Injection ===

It is commonly thought that ORM layers, like Hibernate are immune to SQL injection. This is not the case as Hibernate includes a subset of SQL called HQL, and allows "native" SQL queries. Often the ORM layer only minimally manipulates the inbound query before handing it off to the database for processing.

=== Transaction Scope ===

All database communication should occur within the scope of a Transaction. Although we can't anticipate all design patterns, it would be an easy scan to flag jdbc and hibernate calls outside of transactions in a Hibernate application.

=== Persisting Tainted Data ===

If an application sets tainted properties in an object, then makes that object persistent, it is highly likely that data will be accessed at some point and displayed. If database values are never displayed to the user then obviously this is nullified. Better yet if we could figure out which values from the db are tainted but I have a feeling it's not a feasible scan. Long story short - saves, updates, inserts, whatever that are made with tainted objects should be flagged.

=== Rollback ===

When an exception occurs, roll back the Transaction and close the Session. If you don't, Hibernate can't guarantee that in-memory state accurately represents persistent state.
If your Session is bound to the application, you have to stop the application. Rolling back the database transaction doesn't put your business objects back into the state they were at the start of the transaction, so the database state and the business objects do get out of sync. Objects that are manipulated after a rollback as if they were synchronized.

----

== Simple ==

=== Don't use load() to determine existence ===
Do not use Session.load() to determine if an instance with the given identifier exists on the database; use Session.get() or a query instead. This is a poss

=== Constructing Query Strings ===
Hibernate has a set of functions that are used internally to construct their query strings, but there is no limit to using them in application code - what if they were used with tainted data? This is pretty self explanatory.

=== Place each class mapping in its own file ===
Don't use a single monolithic mapping document. Map com.eg.Foo in the file com/eg/Foo.hbm.xml. This makes particularly good sense in a team environment. Nothing more than a app dev good practice.

=== Use bind variables ===
As in JDBC, always replace non-constant values by "?". Never use string manipulation to bind a nonconstant value in a query! Even better, consider using named parameters in queries.

=== Load mappings as resources ===
Deploy the mappings along with the classes they map.

----

== Detailed ==

=== Transaction Timeout ===
*Transaction timeouts ensure that no misbehaving transaction can indefinitely tie up resources while returning no response to the user.
*Outside a managed (JTA) environment, Hibernate cannot fully provide this functionality. However, Hibernate can at least control data access operations, ensuring that database level deadlocks and queries with huge result sets are limited by a defined timeout.
*In a managed environment, Hibernate can delegate transaction timeout to JTA.

<pre>
Session sess = factory.openSession();
try {
//set transaction timeout to 3 seconds
sess.getTransaction().setTimeout(3);
sess.getTransaction().begin();
// do some work
...
sess.getTransaction().commit()
}
catch (RuntimeException e) {
sess.getTransaction().rollback();
throw e; // or display error message
}
finally {
sess.close();
}
</pre>

===Identify natural keys ===
*Even though we recommend the use of surrogate keys as primary keys, you should still try to identify natural keys for all entities.
*A natural key is a property or combination of properties that is unique and non-null. If it is also immutable, even better.
*Map the properties of the natural key inside the <natural-id> element. Hibernate will generate the necessary unique key and nullability constraints, and your mapping will be more selfdocumenting.
*We strongly recommend that you implement equals() and hashCode() to compare the natural key properties of the entity.
*This mapping is not intended for use with entities with natural primary keys..

Example in hbm.xml:
<pre>
<natural-id mutable="true|false"/>
<property ... />
<many-to-one ... />
......
</natural-id>
</pre>

=== Parameter Binding ===

Hibernate parameter binding works like prepared statements. An edge case it is, but say you had an already tainted string, and then used Query setters to bind more parameters to the "?" placeholders.

Example of proper use:
<pre>
Query q = sess.createQuery("from DomesticCat cat where cat.name = ?");
q.setString(0, "Izi");
Iterator cats = q.iterate();
</pre>

Improper use:
<pre>
Insert insert = new Insert(dialect);
insert.setComment(taint);
insert.addSelectColumn(columnName, alias);
String sql = insert.toQueryString();
....
Query query = sess.createQuery(sql); /*B00*///creating a Query with an already tainted string
query.setString(position, val); //this doesn't cleanse the damage that's been done.
....
transaction.commit(); //sink the ship
</pre>

=== Declare identifier properties on persistent classes ===

Hibernate makes identifier properties optional. There are all sorts of reasons why you should use them. Mapped classes must declare the primary key column of the database table. Most classes will also have a Java-Beans-style property holding the unique identifier of an instance. This is the easiest and most recommended route.
{{{
<class name="Summary">
<subselect>
select item.name, max(bid.amount), count(*)
from item
join bid on bid.item_id = item.id
group by item.name
</subselect>
<synchronize table="item"/>
<synchronize table="bid"/>
<id
name="propertyName" (1)
type="typename" (2)
column="column_name" (3)
unsaved-value="null|any|none|undefined|id_value" (4)
access="field|property|ClassName"> (5)
node="element-name|@attribute-name|element/@attribute|."
<generator class="generatorClass"/>
</id>
</class>
}}}

=== Don't use session.find() ===
This pretty much looks like a duplicate of sql injection but using the deprecated method find() instead. This rule was pulled straight from the best practice list from the reference manual.

If using Hibernate, do not use the depreciated session.find() method without using one of the query binding overloads. Using session.find() with direct user input allows the user input to be passed directly to the underlying SQL engine and will result in SQL injections on all supported RDBMS.

<pre>

Payment payment = (Payment) session.
find("from com.example.Payment as payment where payment.id = " + paymentIds.get(i));
</pre>

The above Hibernate HQL will allow SQL injection from paymentIds, which are obtained from the user. A safer way to express this is:

<pre>

int pId = paymentIds.get(i);

TsPayment payment = (TsPayment) session.
find("from com.example.Payment as payment where payment.id = ?", pId, StringType);

</pre>

=== Cache Management and !OutOfMemoryException ===

*The Session caches every object that is in persistent state (watched and checked for dirty state by Hibernate).
*Whenever you pass an object to save(), update() or saveOrUpdate() and whenever you retrieve an object using load(), get(), list(), iterate() or scroll(), that object is added to the internal cache of the Session.
*When flush() or commit() is subsequently called, the state of that object will be synchronized with the database.
*Otherwise it grows endlessly until you get an OutOfMemoryException, if you keep it open for a long time or simply load too much data.
*One solution for this is to call clear() and evict() to manage the Session cache, but you most likely should consider a Stored Procedure if you need mass data operations.
*Some solutions are shown in Chapter 13, Batch processing. Keeping a Session open for the duration of a user session also means a high probability of stale data.

In this example, it would fall over with an OutOfMemoryException somewhere around the 50 000th row. That's because Hibernate caches all the newly inserted Customer instances in the session-level cache.
<pre>
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
}
tx.commit();
session.close();
</pre>
When making new objects persistent, you must flush() and then clear() the session regularly, to control the

<pre>
size of the first-level cache.
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Customer customer = new Customer(.....);
session.save(customer);
if ( i % 20 == 0 ) { //20, same as the JDBC batch size
//flush a batch of inserts and release memory:
session.flush();
session.clear();
}
}
tx.commit();
session.close();
</pre>

=== About StatelessSession ===
*A StatelessSession has no persistence context associated with it and does not provide many of the higher-level life cycle semantics. In particular, a stateless session does not implement a first-level cache nor interact with any second-level or query cache.
*This may be used as a solution for the cache out of memory problem.
*Operations performed using a stateless session do not ever cascade to associated instances. Collections are ignored by a stateless session.
*The insert(), update() and delete() operations defined by the StatelessSession interface are considered
to be direct database row-level operations, which result in immediate execution of a SQL INSERT, UPDATE or
DELETE respectively.

Example of proper use:
<pre>
StatelessSession session = sessionFactory.openStatelessSession();
Transaction tx = session.beginTransaction();

ScrollableResults customers = session.getNamedQuery("GetCustomers")
.scroll(ScrollMode.FORWARD_ONLY);
while ( customers.next() ) {
Customer customer = (Customer) customers.get(0);
customer.updateStuff(...);
session.update(customer);
}
tx.commit();
session.close();
</pre>

=== Aboot POJOs ===
* You can tell what objects are the persistent ones by looking at the xxx.hbm.xml files.
* Persistent objects are usually POJO's with a default no-arg constructor so that Hibernate can instantiate them using Constructor.newInstance().
* It is recommended that these POJO's have a property that is explicitly mapped as a primary key.

<pre>
<hibernate-mapping>
<class entity-name="Customer">
<id name="id"
type="long"
column="ID">
<generator class="sequence"/>
</id>
......
</pre>

* Accessors and mutators should be declared for persistent fields - it is optional but is good practice because Hibernate persists JavaBeans style properties.

=== Session and Concurrency issues ===

*A Session is not thread-safe.
*Things which are supposed to work concurrently, like HTTP requests, session beans, or Swing workers, will cause race conditions if a Session instance would be shared.
*If you keep your Hibernate Session in your HttpSession, you should consider synchronizing access to your Http session.
*Otherwise, a user that clicks reload fast enough may use the same Session in two concurrently running threads.

=== The equals() and hashCode() problem: ===

*Most Java objects provide a built-in equals() and hashCode() based on the object's identity; so each new() object will be different from all others.
*If all your objects are in memory, this is a fine model, but Hibernate's whole job, of course, is to move your objects out of memory.
* Hibernate uses the Hibernate session to manage this uniqueness. When you create an object with new(), and then save it into a session, Hibernate now knows that whenever you query for an object and find that particular object, Hibernate should return you that instance of the object.
* However, once you close the Hibernate session, all bets are off. If you keep holding onto an object that you either created or loaded in a Hibernate session that you have now closed, Hibernate has no way to know about those objects.
* So if you open another session and query for "the same" object, Hibernate will return you a new instance. Hence, if you keep collections of objects around between sessions, you will start to experience odd behavior (duplicate objects in collections, mainly).
* '''Long story short equals() and hashCode() should be implemented to compare object properties and not just compare on the basis of identifier (the property mapped as the primary key see the above example). The problem is discussed in detail [http://www.hibernate.org/109.html here].'''

<pre>
public class Cat {
...
public boolean equals(Object other) {
if (this == other) return true;
if ( !(other instanceof Cat) ) return false;
final Cat cat = (Cat) other;
if ( !cat.getLitterId().equals( getLitterId() ) ) return false;
if ( !cat.getMother().equals( getMother() ) ) return false;
return true;
}
public int hashCode() {
int result;
result = getMother().hashCode();
result = 29 * result + getLitterId();
return result;
}
}
</pre>

=== Using Detached Objects ===
*In a three tiered architecture, consider using detached objects.
*When using a servlet / session bean architecture, you could pass persistent objects loaded in the session
bean to and from the servlet / JSP layer.
*Use a new session to service each request.
*Use Session.merge() or Session.saveOrUpdate() to synchronize objects with the database.
Usually update() or saveOrUpdate() are used in the following scenario:
*the application loads an object in the first session
*the object is passed up to the UI tier
*some modifications are made to the object
*the object is passed back down to the business logic tier
*the application persists these modifications by calling update() in a second session

<pre>
// in the first session
Cat cat = (Cat) firstSession.load(Cat.class, catID);
// in a higher tier of the application
Cat mate = new Cat();
cat.setMate(mate);
// later, in a new session
secondSession.saveOrUpdate(cat); // update existing state (cat has a non-null id)
secondSession.saveOrUpdate(mate); // save the new instance (mate has a null id)
</pre>

=== Consider externalising query strings ===

This is a good practice if your queries call non-ANSI-standard SQL functions. Externalising the query
strings to mapping files will make the application more portable.
It also decreases the likelihood of injection because the Query objects let you set individual parameters but not the entire query string - you can only do that when you pass the string into the Query implementation constructor or call Session.createQuery.
==== Edge cases are still possibilities! ====
*Basically the application would have to be messy enough to be binding parameters here, and concatenating variables there to the same query string.
*You can extract the query string using Query.getQueryString(), and although you can't manipulate the string and 'add' it back to the Query object, you could theoretically taint it and use it in another instance of Query. Dumb? yes. Possible? Yes.

==== So how to externalize? ====
You may define named queries in the mapping document.

<pre>
<query name="ByNameAndMaximumWeight"><![CDATA[
from eg.DomesticCat as cat
where cat.name = ?
and cat.weight > ?
] ]></query>
</pre>

Parameter binding and executing is done programatically:

<pre>
Query q = sess.getNamedQuery("ByNameAndMaximumWeight");
q.setString(0, name);
q.setInt(1, minWeight);
List cats = q.list();
</pre>

*Note that the actual program code is independent of the query language that is used, you may also define native
SQL queries in metadata, or migrate existing queries to Hibernate by placing them in mapping files.
*Also note that a query declaration inside a <hibernate-mapping> element requires a global unique name for the
query, while a query declaration inside a <class> element is made unique automatically by prepending the
fully qualified name of the class, for example eg.Cat.ByNameAndMaximumWeight.

[[Category:Hibernate]]

2008-06-05T16:11:56Z

Tehmina:

Hibernate

2008-06-05T16:11:39Z

Tehmina:

Hibernate

2008-06-05T15:57:13Z

Tehmina:

Hibernate

2008-06-05T15:54:48Z

Tehmina:

Hibernate/config-example

2008-06-05T15:53:52Z

Tehmina: New page: '''Person.java''' <pre> package events; import java.util.*; public class Person { private Long id; private int age; private String firstname; private String lastname; ...

'''Person.java'''
<pre>
package events;

import java.util.*;

public class Person {

private Long id;
private int age;
private String firstname;
private String lastname;
private Set emailAddresses = new HashSet();
private Set events = new HashSet();

public Person() {}

public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
.....setters and getters for each property etc......

protected Set getEvents() {
return events;
}
protected void setEvents(Set events) {
this.events = events;
}

}
</pre>
'''person.hbm.xml mapping file for Person.java'''
<pre>
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>

<class name="events.Person" table="PERSON">
<id name="id" column="PERSON_ID">
<generator class="native"/>
</id>
<property name="age"/>
<property name="firstname"/>
<property name="lastname"/>

<set name="events" table="PERSON_EVENT">
<key column="PERSON_ID"/>
<many-to-many column="EVENT_ID" class="events.Event"/>
</set>

<set name="emailAddresses" table="PERSON_EMAIL_ADDR">
<key column="PERSON_ID"/>
<element type="string" column="EMAIL_ADDR"/>
</set>

</class>

</hibernate-mapping>
</pre>
'''hibernate.cfg.xml configuration file.'''
<pre>
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>

<session-factory>


<property name="connection.driver_class">org.hsqldb.jdbcDriver</property>
<property name="connection.url">jdbc:hsqldb:hsql://localhost</property>
<property name="connection.username">sa</property>
<property name="connection.password"></property>


<property name="connection.pool_size">1</property>


<property name="dialect">org.hibernate.dialect.HSQLDialect</property>


<property name="current_session_context_class">thread</property>


<property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>


<property name="show_sql">true</property>


<property name="hbm2ddl.auto">create</property>

<mapping resource="events/Event.hbm.xml"/>
<mapping resource="events/Person.hbm.xml"/>

</session-factory>

</hibernate-configuration>
</pre>

Hibernate

2008-06-05T15:46:11Z

Tehmina: