Thanks Michael, that's really helpful. FWIW, the Pyramid version of Zope's traversal does require explicit handling, thus allowing one the pros of traversal without surrendering fine grained control. I *believe* part of the impetus for that was to reduce the Zope Magic in the Zope 2 traversal mechanism.
iain On Wed, Jan 9, 2013 at 9:27 AM, Michael Bayer <mike...@zzzcomputing.com>wrote: > 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. > > -- 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.
