

Rails Data Injection Vulnerability in Active Record (CVE-2014-0080) - gkop
https://groups.google.com/forum/#!topic/rubyonrails-security/Wu96YkTUR6s

======
scottshea
I hate myself. My first thought was being happy my version of Rails was not
vulnerable to this one.

------
piratebroadcast
Someone explain this to be like I'm 5?

~~~
hfghegheotqhgo
Bad framework, with too much magic, poor security, poor performance, not good
for anything beyond the five minute blog.

~~~
vesinisa
Sadly, I tend to agree. It seems anyone starting a new publicly-accessible web
site with Rails are aiming for a shot at their own feet. Rails might still be
usable for Intranet servers in a trusted network setting or prototyping web
site ideas before transitioning to a "serious" framework. The continuing
security issues and lack of focus on performance make it terrible choice for
_any_ production web site.

~~~
matthewmacleod
With respect, you don't know what the hell you are talking about. All software
suffers from security issues, and Rails' performance issues are overstated.

~~~
vesinisa
Rails does suffer disproportionately from security issues. The framework code
has become increasingly bloated and serious security vulnerabilities are being
continuously discovered (see [http://www.cvedetails.com/vulnerability-
list/vendor_id-12043...](http://www.cvedetails.com/vulnerability-
list/vendor_id-12043/product_id-22568/Rubyonrails-Ruby-On-Rails.html)) both on
the low and high level code (the seriousness of this specific vulnerability
depends on application). While I _like Rails_ , I would not choose it as a
server-side framework for my product anymore: painful to maintain (backwards-
compatibility is not a priority) and slow (compared to say, Go, anyway).

Rails is nowadays easily replaced. Most of the fancy server-side bits are not
really that useful, and on the front-end the zeitgeist are JavaScript
frameworks, where the server acts as an API but serves static HTML/JS/CSS
files.

~~~
djur
Comparing Rails to Go doesn't make any sense.

Rails regularly has security vulnerabilities reported because it's popular,
mature, deployed in a lot of places, and thus gets a lot of attention. When
something like Play or whatever is equivalent in the Go world is similarly
exposed I would expect to see security vulnerabilities reported there, too.

Software only _gets_ widely reported CVEs if it's popular. The lack of these
reports for smaller, less popular frameworks does not indicate the lack of
security flaws.

~~~
vesinisa
It does not suffice that a software is popular to render it insecure. OpenSSH
is wildly more popular than Rails will ever be, yet it has a superior security
record ( [http://www.cvedetails.com/product/585/Openbsd-
Openssh.html?v...](http://www.cvedetails.com/product/585/Openbsd-
Openssh.html?vendor_id=97) ). Good strategy to avoid security issues is to use
the smallest possible set of well-tested tools to achieve your task. Rails is
almost the complete opposite of this: a large package of pretty much
everything, of which most will ever use only a small portion.

~~~
grey-area
You're comparing a web app framework to a language and then to encrypted
communication software which has been around for over a decade? You're
grasping at straws here and it is telling you quote the OpenSSH security
record but not that of other frameworks.

Even comparing it to Go is pretty flawed, because of course Go is a language,
not a framework, and it has not been tested extensively or attacked
extensively, nor have the apps you have written in it. You can expect those
apps to have some vulnerabilities you don't even know about as yet, unless you
have had a security audit?

Like many projects, Rails is continually discovering potential security
problems, though I wouldn't say it is significantly worse than other
comparable frameworks/stacks, and some of the flaws they are fixing nowadays
are pretty much harmless for normal use (some not, like this one, which is
dangerous for the subset of users using these advanced features (probably
under 5% of users)).

Pick any other widely used app framework, and you will find a similar history
of security exploits discovered, though I'm sure some are better than others.
It's fine to say that Rails has worse security than project x, backed up by
figures, but saying anyone using Rails is shooting themselves in the foot is
hyperbole.

The worst recent issue in rails I can remember is the JSON parsing incident,
which also affected some python users. Just as an example comparison, in
Golang if you are lazy and unmarshal into an interface or map[string]interface
you might end up with similar problems of unintended data leakage, and if you
unmarshal into your own struct without carefully checking what you get, you
might end up with unexpected nils which only surface much later or data
overwritten which was unintended. You're unlikely to get clobbered just as the
Ruby JSON parser was, but you could easily introduce vulns without knowing it.

I actually prefer golang to ruby for other reasons, but the frameworks are
neither mature nor battle tested, so it's not a great example to compare on
security, and neither is OpenSSH.

~~~
batiste
> Like many projects, Rails is continually discovering potential security
> problems, though I wouldn't say it is significantly worse than other
> comparable frameworks/stacks

Compared to Django, a framework similar both in feature and popularity, Rails
is definitely worse. Especially compared with the most serious flaws (code
execution, SQL injections).

[http://www.cvedetails.com/product/18211/Djangoproject-
Django...](http://www.cvedetails.com/product/18211/Djangoproject-
Django.html?vendor_id=10199)
[http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-
On-...](http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-
Rails.html?vendor_id=12043)

Not sure about the JSON incident you mention. Maybe you thought about YAML?

~~~
grey-area
Thanks for the links, which I think would lead to a more productive discussion
because they are a comparison of similar frameworks. There are of course
difficulties with gauging how much attention each gets (a lower CVE count is
not proof of security), but overall Django looks better here.

I was thinking of the third one on this page (I suppose strictly speaking a
vuln in a gem outside rails) which was pretty serious:

[http://weblog.rubyonrails.org/2013/2/11/SEC-ANN-
Rails-3-2-12...](http://weblog.rubyonrails.org/2013/2/11/SEC-ANN-
Rails-3-2-12-3-1-11-and-2-3-17-have-been-released/)

but there was a related YAML bug too at the same time with serialize, which
also allowed users to supply input that was then instantiated (madness!). Do
lots of people use serialize? I've never explicitly used it, unless it is used
behind the scenes somewhere. I remembered the fuss being over JSON because of
broader impact but may have misremembered.

