Earlier quoted context omitted.
On the bright side you need not fear this bug for your apps using MongoDB. Mongoid and MongoMapper do not use SQL, so there should be no SQL injection problems using those two options.
I'm aware they don't use SQL, but someone on HN once told me there was some kind of JavaScript injection you could do in theory. Was wondering how mongoid would handle this technique.
SQL Injection Vulnerability in Ruby on Rails; affects all versions
111–120 of 220 posts
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#112Earlier quoted context omitted.
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…
> To whit, if you look at the bug report it says that the problem is when an application is passing user-provided data into the framework. They say "don't do that" and then apparently provide a patch to somehow get around if you don't 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 pos…
This is the exact quote from the posting linked for this article:
---- Impacted code passes user provided data to a dynamic finder like this:
Post.find_by_id(params[:id]) ----
It later tells you to apply the "to_s" function to the "user provided data" in order to avoid the problem.
I'm unclear on how that is "misinformation".
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#113Earlier 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.
This is not a rubyism, it is a Railsism, they wrote a method called extract_options! and use it everywhere to get this kind of behavior. This is not how vanilla ruby works.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#114Earlier 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.
This is not a rubyism, it is a Railsism, they wrote a method called extract_options! and use it everywhere to get this kind of behavior. This is not how vanilla ruby works.
If it wasn't a rubyism, why is there syntax sugar for passing a hash as the last positional parameter?
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#115Earlier quoted context omitted.
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.
Blue boxing predates 5ESS switches; 5ESS was notoriously the switch you couldn't blue-box.
Oh really? I always thought SS7 was the first switch to move to out of band.
What's the last blueBox-able switch?
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#116Earlier quoted context omitted.
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…
What's the great benefit of these methods? Why not just do find_by("url", x)? I just don't understand the desire to move string parameters into member names.
That method predates the "Forum.where(:url => ...)" syntax of xentronium's demo code. Previously it looked like this: "Forum.find(:first, :conditions => {:url => ...})". Dynamic finders were really sugar over this form, which was always kind of an eyesore.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#117Earlier quoted context omitted.
> To whit, if you look at the bug report it says that the problem is when an application is passing user-provided data into the framework. They say "don't do that" and then apparently provide a patch to somehow get around if you don't 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 pos…
This is the exact quote from the posting linked for this article: ---- Impacted code passes user provided data to a dynamic finder like this: Post.find_by_id(params[:id]) ---- It later tells you to apply the "to_s" function to the "user provided data" in order to avoid the problem. I'm unclear on how that is "misinformation".
It tells you to do that in the "Workarounds" section when talking about how the vulnerability can be mitigated. At no point do they tell you not to pass user provided data to this method.
The problem is an argument parsing bug that leads to user provided data being used as programmer provided data. Rails does not force SQL sanity off on the developer.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#118Earlier quoted context omitted.
This is not the problem. Please stop spreading misinformation. ActiveRecord does escape user input. The exploit here is that under certain obscure circumstances it is possible trick ActiveRecord into thinking the user input is an options hash passed by the caller. From my understanding this is non-trivial to exploit on most applications, and requires passing in a Hash with symbol keys. This is still a vulnerability t…
Umm.. I didn't say that ActiveRecord doesn't escape user input. So, stop spreading misinformation about my post ;-) The fact of the matter is, whether its in some dark edge-case or not, user-provided data is being used to compose a SQL statement that is being passed to the server. Escaped or otherwise, that's a recipe for an injection attack.
> user-provided data is being used to compose a SQL statement that is being passed to the server. Escaped or otherwise, that's a recipe for an injection attack
How do you implement authentication if you can't check an email (user provided data) matches a password (user provided data, probably hashed but still)? How do you look up blog posts by a user-provided tag, without using that tag in query composition? How do you save any user provided information at all without somehow including that information in an SQL query?
You have to use escaped user provided data all the time in a real application. Any actual web developer would know that.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#119Having just finished upgrading my production rails because of today's news I thought I would pass along a how-to for rails 3.x
update your Gemfile and set the version you want. In my case:
gem 'rails', '3.2.10'
locally, run
'bundle update rails' which will update your Gemfile.lock
check-in and deploy your code. If you are using capistranso, the default 'deploy' task should handle everything for you. Otherwise, run 'bundle update rails' on your production server.
Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions
#120Earlier quoted context omitted.
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…
Stupid question, but how was that not discovered until now? That seems quite major, or something that the developers would have tested for ..
The vulnerability doesn't get triggered normally. As the grandparent said, request parameters are stored in an object of class HashWithIndifferentAccess, which stores all keys as strings. For the vulnerability to be triggered, the keys must be symbols. You cannot trigger this vulnerability unless your have written code in your app which converts the HashWithIndifferentAccess to a normal hash.
This patch does not fix a wide vulnerability. It just fixes a corner case, a just-in-case-somebody-might-write-vulnerable-code fix.
It just so appears that Authlogic does this. They pass a cookie value into a dynamic finder, so you can tamper the cookie to inject SQL.