Re: [Sqlalchemy-tickets] [sqlalchemy] #2951: Confusing Query.get() behaviour. Possible insufficient criterion checking.

[sqlalchemy <mi...@zz...>]

#2951: Confusing Query.get() behaviour. Possible insufficient criterion checking.
-----------------------------------+-----------------------------------
      Reporter:  enomad            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  high              |  Milestone:  0.8.xx
     Component:  orm               |   Severity:  trivial - <10 minutes
    Resolution:  fixed             |   Keywords:  Query get criterion
Progress State:  completed/closed  |
-----------------------------------+-----------------------------------

Comment (by zzzeek):

 a security breach requires that an attacker can inject a specific,
 incorrect outcome into code that otherwise performs its function correctly
 when this injection is not taking place.

 In this case, there is no incorrect result that can be returned; get()
 does its job consistently.   It's just that a particular exception related
 to how get() was used may or may not be raised, and in that sense it
 behaves more like a query that is inconsistently available, but not in any
 way one that occasionally returns unexpected results versus expected
 results.  The results it returns, when it's not raising an exception, are
 consistent and are not subject to manipulation.

 A number is passed to get() - the primary key of an object.  That number
 is *always* the primary key that will be searched.  There is no way for
 the query to return the "wrong" result, as far as get() - get() always
 returns the object with the pk that you give it, end of story.  There is
 no attack vector by which an attacker can manipulate input into a system
 such that a different object is returned, and especially not a specific,
 different object.

 An application that writes out session.query(User).filter(User.password ==
 somepassword).get(5), is broken.  However, while putting that code in
 production is a security hazard, the hazard is because the code is
 entirely broken 100% of the time, not because it can be manipulated in
 some circumstances to return unexpected results.   That particular query
 will fail every time to check the user's password, which will be revealed
 in any test.  It's not any different from a query that fails to check the
 password at all.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2951#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python