101–110 of 220 posts
Earlier quoted context omitted.
Rails does escape inputs with its finder and scope methods. I think the problem is that the "magic" in these methods allow for some edge cases to be parsed in unexpected ways...for example, when params[:id] contains a nested hash instead of a string or integer.
This pull request is probably what caused the alarm: https://github.com/binarylogic/authlogic/pull/341 With 3395 stars it seems to be a quite popular.
So does the fact that "Rails is Omakase" ( http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... ) mean that the chef tried to serve Fugu ( http://en.wikipedia.org/wiki/Fugu ) but cut it wrong?
I am mostly a Django programmer so excuse my ignorance of rails. How does this keep happening? In Django you would do: Post.objects.get(pk=request.GET['id']) There really is no way to do SQL injection this way. This line in rails looks almost exactly like how you would do it in Django: Post.find_by_id(params[:id]) Also this seems really serious. It's not like a edge case where you need to grab a post by id. This is p…
You are going to have problems with this whenever you are composing SQL statement with any type of user-provided data as part of the raw SQL string passed to the server. This generally happens in one of two says: 1) (most common) You have a SQL statement that takes a user-provided parameter and you compose your SQL statement as a string, including that parameter (eg., sql = "SELECT * FROM person where id = " + form.i…
True, but Rails is not doing that, was never doing that, and the patch has nothing to do with this. So you're talking about something unrelated to this security flaw.
Earlier quoted context omitted.
Btw, this applies for my (Python) Flask apps using MongoDB ORMs. They escape the inputs. What the hell is going on with ActiveRecord?
The main issue stems from Ruby using the last positional parameter to pass a hash representing keyword arguments. This means if there's only one parameter, and someone can sneak a Hash in there where you weren't expecting it (params parsing, request body parsing, etc) then they can end up passing dodgy 'keyword arguments' into your method call.
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.
>You are going to have problems with this whenever you are composing SQL statement with any type of user-provided data as part of the raw SQL string passed to the server. This is still, mathematically-speaking, a bug. The function is supposed to find a post by ID. If its implementation causes side effects or returns unexpected results for a certain subset of possible input data, then it doesn't conform to spec. This…
I didn't say it wasn't a bug. It's a bug that indicates that ActiveRecord was written/designed in such a way that it trusts user-provided data to be executed. And, yes, I would fully expect to be able to trust my data-abstraction layer to be bug free. Since Rails seems to have this problem regularly, I can't trust it and therefore choose not to use it for those purposes. So, I think we agree here. --- Edit --- To whi…
They never tell you not to pass in user provided data. I have no idea where you got that conclusion, but you're obviously off and running with it. Quit spreading misinformation.
The post includes a simple workaround for people who are not able to upgrade to a version that includes this security release. It's not a "don't do that" statement.
> To my mind, the problem is that Rails should be treating any data passed to it as user-provided data
It does. This is a bug. Please quit spreading misinformation.
FWIW, this is the third time in seven months that Rails had to issue a patch related to how ActiveRecord handles method parameters. 3.2.6 (June 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra... 3.2.4 (May 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...
History seems to keep reminding us that in-band signalling is a convenient idea fraught with danger.
for instance, before this patch you could do User.find_by_username('whocares', :conditions=>"ARBITRARY SQL")
Earlier quoted context omitted.
The main issue stems from Ruby using the last positional parameter to pass a hash representing keyword arguments. This means if there's only one parameter, and someone can sneak a Hash in there where you weren't expecting it (params parsing, request body parsing, etc) then they can end up passing dodgy 'keyword arguments' into your method call.
i don't know ruby, so forgive the dumb question, but doesn't that mean that a single syntax has two different semantics? what if you want to pass a hash to a method as the last parameter? what decides whether it is treated as a hash or keywords?
For example, this:
my_method(1, 2, three: 3, four: 4)
my_method(1, 2, { three: 3, four: 4 })
def my_method(one, two, opts)
three = opts[:three]
four = opts[:four]
puts one, two, three, four
endWould appreciate if someone could explain the issue in a little more detail for non RoR developers
Assuming you have no ruby knowledge: ActiveRecord (rails' default ORM) has a feature called "dynamic finders". When you call a method like `Forum.find_by_url('news.ycombinator.org')` it gets a first forum with such url. This is a sugar over `Forum.where(:url => 'news.ycombinator.org').first`. Normally, you use it like that `Forum.find_by_url(params[:url])` where `params` is a hash of parameters (that is auto-generate…