
Two Active Record SQL Injection Vulnerabilities Affecting PostgreSQL - elektronaut
https://groups.google.com/forum/#!topic/rubyonrails-security/wDxePLJGZdI
======
Pacabel
It's unfortunate that the wording of the email subject (and the current HN
submission title) can make it sound like the problem is with PostgreSQL, when
it's really a problem with Active Record's adapter for PostgreSQL.

PostgreSQL itself isn't responsible or affected, contrary to what the
"Vulnerabilities Affecting PostgreSQL" phrasing suggests at a glance.

------
bensedat
Looks like the Rails 3.2 update drags along a few other unrelated changes,
although they appear to be fairly minor:
[https://github.com/rails/rails/compare/v3.2.18...v3.2.19](https://github.com/rails/rails/compare/v3.2.18...v3.2.19)

as compared to:
[https://github.com/rails/rails/compare/v4.1.2...v4.1.3](https://github.com/rails/rails/compare/v4.1.2...v4.1.3)
and
[https://github.com/rails/rails/compare/v4.0.6...v4.0.7](https://github.com/rails/rails/compare/v4.0.6...v4.0.7)

~~~
thibaut_barrere
I use this now to make sure I review before updating:

[https://gist.github.com/thbar/7dc97d3f5f6a52e4fa00](https://gist.github.com/thbar/7dc97d3f5f6a52e4fa00)

(obviously not to be used in a CI environment).

Also, if you want to make sure you get push notification for security updates,
check out this:

[http://thibautbarrere.com/how-to-get-push-notifications-
for-...](http://thibautbarrere.com/how-to-get-push-notifications-for-rails-
ruby-security-updates/)

(I get only critical stuff as pushes, and get notified even in the rare case
that the rails security email goes to spam as it happened once previously).

------
craigkerstiens
You should be able to see if you are vulnerable by running this query:

    
    
      select 
            cn.nspname as schema, 
            relname as table, 
            attname as column, 
            tn.nspname as type_schema, 
            typname as type_name 
        from pg_attribute a 
        inner join pg_class c on a.attrelid = c.oid 
        inner join pg_namespace cn on c.relnamespace = cn.oid 
        inner join pg_type t on a.atttypid = t.oid 
        inner join pg_namespace tn on t.typnamespace = tn.oid 
        where (t.typtype = 'r' or t.typname = 'bit' or t.typname = 'varbit');

------
bni
So Active Record is building its SQL from string concatenation, not using
prepared statements with bind variables?

~~~
simonw
All ORMs build at least some of their SQL using string concatenation.

Prepared statements with bind variables only work when the SQL string is
static and only the variables change - but ORMS are used to construct full SQL
statements with custom select / while / join clauses etc.

~~~
X-Istence
Yes, all ORM's build their SQL using string concatenation, BUT the good ORM's
won't use string concatenation on user data, instead they will use bind
parameters.

This way the query sent to the server looks like this:

    
    
      SELECT * FROM whatever WHERE email = :1 AND user_name = :2;
    

And then the parameters are passed to the database server separately to bind
to the above placeholders.

This way the database server knows what is user provided data and what is part
of the SQL, and no special quoting is required since the database server
handles that internally. It's much safer in that SQL injection becomes
impossible at that point.

~~~
warmwaffles
That's not what OP was saying. That SQL string you just provided is static. At
some point the ORM has to assemble that string.

~~~
X-Istence
OP said:

    
    
      > Prepared statements with bind variables only work when the SQL string is static and only the variables change
    

This is wrong.

~~~
simonw
I said "All ORMs build at least some of their SQL using string concatenation"

The "at least some" was meant to imply that they also use bind variables.

------
jrmiii
FTA: Only applications which query against either bitstring or range types are
vulnerable.

