I've just read http://www.insinuator.net/2013/01/rails-yaml/ and really, the huge fail here is that Rails allows the construction of arbitrary application objects based on parameters. So while SQL injection is of course part of the hack here, the ORM part of rails isn't what's failing in this case - it's that the web framework is basically allowing the environment of the whole application to be controlled from a web request, and this post coins a great new term to describe it called an "object injection attack". There are plenty of other ways to attack an application with this that don't even need the database.
SQLAlchemy and any other ORM of course provides for special SQL expression objects to be placed into any statement, where you can provide the string contents. But granting that capability to your web users is pretty much like running untrusted input through eval(). This is kind of the nightmare scenario that makes me avoid Zope's "traversal" idea like the plague, even though I know that is something different, the whole concept of GET/POST data having any kind of implicit link to application structure without explicit code mediating those paths is very scary. So if any approach is to take a hit here, it's monolithic web stacks that provide wide and complex data pipes with a heavy emphasis on implicit translation of data between tiers. On Jan 9, 2013, at 12:07 PM, Michael Bayer wrote: > I'd say if RoR was actually quoting strings in their ORM then things are > terribly mis-designed. SQLAlchemy always defers to the DBAPI for bind > parameter handling, the only area where we have had a vulnerability was that > we weren't using these binds for the LIMIT/OFFSET parameters of a SELECT > statement. That issue was fixed years ago, there were many messages > generated from automated Linux distro trackers and such but that was pretty > much it. > > There's very little to compare between ActiveRecord and SQLAlchemy as the > philosophies are completely different (for example, SQLAlchemy tries to stay > agnostic of any "convention" as possible) so I wouldn't think the security > issues of RoR would have any tendency to spread doubt about other projects. > SQLAlchemy's approach insists that the user has a clear idea of what he or > she is doing in the first place, as opposed to relying upon tools to figure > everything out (tools are for automation, not design), so that puts us in a > much better spot right off. > > That said, my constant defenses of SQLAlchemy are generally oriented around > dispelling ORM myths spread by people's experiences with other ORMs, so in > that sense whatever failures RoR is bringing aren't really anything new. > > > On Jan 9, 2013, at 11:57 AM, Iain Duncan wrote: > >> Just curious as to whether anyone has seen changes in interest in SQLAlchemy >> in the wake of the Ruby on Rails SQL injection vulnerability, or if anyone >> has any thoughts on it. Or worse, if it's going to tar SQLA with the same >> brush. >> >> This is pure conjecture, and should be taken with a giant grain of salt, but >> I wonder whether the monolithic, almost closed-garden nature of the RoR >> ecosystem contributed to the situation compared to the situation in Python. >> Of course that could just be a big confirmation bias on my part. Would >> welcome thoughts from those more experienced than me. >> >> Iain >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To post to this group, send email to sqlalchemy@googlegroups.com. >> To unsubscribe from this group, send email to >> sqlalchemy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sqlalchemy?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
