I thought that SQL injection was "mostly" a thing of the past with newer frameworks such as Rails and Django. I mean, short of concatenating your query string together, it is much harder to set yourself up for failure.
When you pass nested query parameters such as "id[a]=b&id[c]=d", Rails will parse it as parameters :id => {'a' => 'b', 'c' => 'd'}
If you use where(:id => params[:id]) it will become where(:id => {'a' => 'b', 'c' => 'd'})
And when Rails convert that to SQL statement, something can be exploited (though it's not mentioned in the report).
It's the first query, the metadata one, that applies the passed arguments in a raw form directly to the query. The exploit takes place inside of a 'show' operation. It's totally unprotected and lets you run pretty much any select you're interested in.
It also goes beyond prepared statements - the metadata query in question is totally separate from the one specified by any parameterized query you'd pass using something like ('id = ?', params[:id]). So essentially, as a developer, you can't do anything better. This is kind of on the framework side alone :/
You can see those tests here:
http://seclists.org/oss-sec/2012/q2/att-504/3-2-sql-injectio...
(this is for 3.2, you can change the patch name for 3.1, etc.)