201–210 of 220 posts
Earlier quoted context omitted.
History seems to keep reminding us that in-band signalling is a convenient idea fraught with danger.
Look no further than the deprecated 5ESS switches which used to give up free calls due to 2600hz tones being signaled inband. Ask Steve Jobs and Woz about BlueBoxes; you need look no further to see the inherent dangers on inband signaling. Slightly off-topic, but still relevant IMHO.
Earlier quoted context omitted.
I've always found Rails to be easy to secure compared to most other frameworks. I think the defaults are all pretty secure. I'd prefer having constant security patches. It shows people are still constantly testing it for vulnerabilities.
SQL injection is the web-equivalent of having a stack allocated buffer overflow. We have built and use (expensive) abstractions that supposedly eliminate these whole class of issues. With Rails, you get the expensive abstraction and apparently none of the security.
But briefly, if you think of a grammar such as HTML in terms of an abstraction, the very fact that you need to encode output when creating HTML indicates that the abstraction can be "punctured".
And many abstractions, such as stored procedures, don't help you out at all. There is a oft-repeated untruth that somehow stored procedures magically prevent SQLi.
The overreaction on this page is ridiculous. Has anyone actually read the steps required to exploit this vulnerability? You do know that to be able to exploit it you have to know the application's secret key, so you can create your own malicious encrypted session cookie that includes hashes instead of strings for the auth token lookup? You do know that if someone has your app's secret key they can just write whatever…
It is not an overreaction. This is a much more subtle SQL injection. I believe the takeaway is that too much magic is a bad thing when it obscures the underlying behavior. Post.find_by_id( ) accepts an argument. Here are some normal assumptions: 1. It might only take a number 2. The method might coerce it to a string or integer for you 3. The method might not coerce it. 4. The method might throw an error if it isn't…
What people seem to be reacting to is the idea that User.find_by_id(params[:id]) is exploitable because you can coerce params[:id] into a hash instead of a string (by using a query string like ?id[select]=some_thing_here instead of ?id=27). True, but what most people here are overlooking is that User.find_by_id actually rejects these hashes because their keys are strings and not symbols. Try it out.
This vulnerability can be coupled with other vulnerabilities (like having someone's session secret, which is a much worse vulnerability IMO), but people are talking about it as if you can do something nasty with it by itself alone. That's why it's an overreaction.
I've written a blog post which explains what this vulnerability is, how it works, what the facts and non-facts are: http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulner...
It would have been really useful if the upgrade notification had included this level of detail to start with so people could make a much more informed decision about when/if to upgrade, rather than having to dive through bug reports, commits etc just to work out if our apps are vulnerable.
Earlier quoted context omitted.
the thing that is different is that the raw sql facilities are made explicitly available not through the common methods that expect them, but through something else. The orm supports building the sql piecemeal, e.g find(select: "name, foo(bar) as baz", conditions: 'x=y', limit: 3) this is a small step above a raw execute, and obviously ugly and low level. Also a somewhat obsolete practice, since for a few years you c…
Just so you know, Django has a sort of dynamic finder implemented with kwargs in the lookup Post.objects.filter(some_field_name=some_value)
With no obvious value over the former that I may think of anyway, I think they are mostly there for historical reasons.
Earlier quoted context omitted.
the thing that is different is that the raw sql facilities are made explicitly available not through the common methods that expect them, but through something else. The orm supports building the sql piecemeal, e.g find(select: "name, foo(bar) as baz", conditions: 'x=y', limit: 3) this is a small step above a raw execute, and obviously ugly and low level. Also a somewhat obsolete practice, since for a few years you c…
Can't see how it's different from: (in a manager) def find_by_foo(self, arg): return self.filter(foo=arg)[:1]
What you wrote is exactly what I wrote that a finder method _could be but it's not and that is the issue_
Earlier quoted context omitted.
>The fact that this keeps happening on Rails is the #1 reason I haven't bothered to take the time to do anything real with it. I don't have the time to read the code for the framework and I don't trust that it's written with security in mind. What frameworks do you use? Have you performed your own audit?
Totally fair question. I personally prefer not to use ORMs for this specific reason: they are typically way too complicated to be able to plow through the code in any reasonable way. It's also generally not that hard to design your application in such a way that using a minimalist "ORM-ish" layer of your own making isn't exactly a waste of time. I've also found that they rarely follow these best practices (it's madde…
You have no credibility to talk about database if you can't tell what kind of statements are being executed.
Earlier quoted context omitted.
The standard way to find a post in Rails would be: Post.find(params[:id]) That method is unaffected. The methods that are affected by this are the dynamic finder methods `find_by_*` such as: Post.find_by_id(params[:id]) This would most commonly occur when looking up users by a token or some other piece of data other than the id. User.find_by_token(params[:token]) I'm not sure why they chose to use find_by_id in the e…
I believe if you do Post.find on a nonexistent id, a ActiveRecord::RecordNotFound exception is thrown, but this doesn't happen with the dynamically generated finders like find_by_id. Given this difference, it's possible you want to handle a missing record in a more graceful, non exception catching matter.
Earlier quoted context omitted.
History seems to keep reminding us that in-band signalling is a convenient idea fraught with danger.
This isn't an in-band signaling error, per se. This is not an issue of escaping the quotes or something, rather the way this issue works is that User.find_by_username(params[:username]) is interpreted wildly differently if params[:username] is a string compared to if it is a different data type. If it is not a string, then the "options" for the dynamic finder are automatically extracted. It turns out that you probabl…