
Ruby on Rails vulnerable to mass assignment and SQL injection - WestCoastJustin
http://www.zweitag.de/en/blog/ruby-on-rails-vulnerable-to-mass-assignment-and-sql-injection
======
chc
Before anybody gets the wrong idea here: Yes, there are a lot of highly
publicized Rails vulnerabilities lately. If you avoid Rails, it will protect
you from these vulnerabilities. But give somebody familiar with pentesting a
little while with your app and I _rather strongly suspect_ they will find new
and different vulnerabilities that would horrify you as much as anything you
find in Rails.

Rails gets a lot of scrutiny. Just because your ad hoc Flask app doesn't does
not mean it would hold up a lot better. If you believe it will, think very
hard about the reasons.

(This is not to say you shouldn't use something else either — just that the
gut instinct of "Well, my app on this little microframework won't be getting
security advisories every couple of weeks" is not necessarily something you
want to follow. Like I said, think very hard about whether you really believe
you can do justice to your app better than the Rails security team. And read
up on some anecdotes from people who do application security while you're
thinking about it, because I find people tend to underestimate just how broken
most software is.)

~~~
saurik
I agree with you; however, there is something to be said for "not subject to
drive-by mass tagetings on short notice" that is ignored by this argument.
There may be 7 obvious bug in your program, but of you have a couple hundred
users, will any of them bother? However, even if you have no users at all, you
are going to get hacked by these 0-days due to people just scanning the
Internet looking for vulnerable systems. In my case, every single time I've
been hacked has been due to a 0-day dropping that I didn't pay enough
attention to (like exim4), as opposed to the assuredly infinate number of bugs
I have in my own software.

~~~
jiggy2011
Out of those couple of hundred users you only need one of them to be a bored
teenager who has read a bit about web security to bust your application.

It's not like this stuff is that hard in a lot of cases, it's often just "if I
put a semicolon in the URL, how does it respond?" or "does this form have a
CSRF token?".

~~~
bad_user
I'm a senior developer and I can assure you that stuff like " _if I put a
semicolon in the URL, how does it respond?_ " never works on my software. It
doesn't because as a general rule I sanitize all input or rely on the stack to
do it for me, but in general I know which parts of the stack are doing
sanitization to lift that burden from me.

That doesn't mean my software is secure. Unfortunately some bugs are far more
subtle, including the recent Rails exploit. So on one hand I trust Rails even
more, precisely because such problems are found and fixed. But on the other
hand this does open you up to mass exploits, which does give me the shivers.

So it really depends on how much effort you're spending on your app. If you
actively maintain your app then you can take notice of zero day exploits and
upgrade ASAP. But if you want a worry-less app that you don't want to
maintain, a more custom stack is more suitable.

Case in point, Wordpress is the most popular blogging platform in the world.
It's also the most targetted and shitty weekend blog implementations are far
less likely to get hacked.

------
jiggy2011
How do you guys who are freelancers or perhaps you work for a company and are
the only guy working on a particular app handle security stuff like this?

A lot of what I hear is "drop what you are doing and patch this right now!".
But of course there are many reasons why this might not be possible. For
example you might be on a 15 hour flight with no internet, you might be
dealing with some family crisis, you might be in the middle of a coke and sex
binge with identical twins who look like Scarlett Johansen or whatever.

Do you live glued to your smartphone in constant fear of 0 days? Do you make
sure there is some third party available to deal with this stuff? do you
design with the possibility of having your app/site owned as a likely event?

And how do you make your client/employer aware of the implications of stuff
like this?

~~~
static_typed
We actually moved off Ruby/Rails because of all this, but previously it was a
test in QA, then patch Prod, both on same day of the word hitting the street
that there was yet another hole to close

~~~
charliesome
What are you going to do when whatever you're currently using has a security
problem?

Moving off Rails is not a panacea

~~~
mpyne
It doesn't have to be a panacea, it just has to significantly reduce the risk
of being exploited (whether due to superior design philosophy, superior
execution of that design philosophy, or simply 'security by low market
share').

If the security of your platform depends on that platform not become a popular
target of hacker attention then sometimes it really is as simple as "I don't
need to outrun the bear; I just need to outrun you"

~~~
jiggy2011
This is an odd way to think. What happens if you start on a niche platform and
it gets popular, do you switch?

Just because a platform is small doesn't mean somebody isn't going to try and
bust it and when they do the small project may not have the resources to push
out a robust fix quickly.

~~~
obstacle1
I'm not parent, but the claim wasn't that popular implies vulnerable. Just
that some projects ignore security while the stakes are low, which comes back
to bite them in the backside once adopters pick up (e.g. what we're witnessing
with Rails now).

~~~
nostrademons
...which is often the right choice, because projects that pay attention to
security from the get-go often lose out in the marketplace to ones who pay
attention to other, more important factors. There's an opportunity cost to
everything, and for many apps, security is not as important as convenience,
ease-of-use, performance, or features.

Witness Dropbox vs. TarSnap. Dropbox has had multiple serious security
vulnerabilities published. TarSnap is by the FreeBSD security officer. Yet
Dropbox is the one with the million+ users and $B+ market cap, because grandma
cares a lot more about being able to figure out how to use the product than
about what happens when the product gets hacked.

~~~
cookiecaper
There's a lot more to DB v. TS than "Dropbox focused less on security".
They're different programs for different audiences. While in some cases they
may have market overlap, TS definitely has a niche that would never even
consider DB as a possibility. TS's major competitor is custom solutions like
rsync.net + duplicity.

------
trevorcreech
I love building stuff with Rails, but these last few weeks are making me glad
I'm not maintaining it in production.

~~~
thelarry
I get a little chuckle when I tell people I am building some app and they ask
"Why aren't you using RoR and MongoDB?" Maybe I am not comfortable with them
in production?

~~~
meaty
I am of the same opinion. Having trialled both extensively, we stuck with
asp.net MVC and SQL server. Expensive but well engineered.

~~~
RyanZAG
Wouldn't be so sure of safety - RoR just gets a lot more publicity when a
vulnerability surfaces, although the huge amount of magic involved in RoR
makes vulnerabilities more common than more static code.

<http://forums.asp.net/1233.aspx> [http://www.troyhunt.com/2012/04/67-of-
aspnet-websites-have-s...](http://www.troyhunt.com/2012/04/67-of-aspnet-
websites-have-serious.html) etc

Besides, most web app vulnerabilities are coding flaws in the user code
itself, and very rarely in the framework.

~~~
meaty
However framework vulnerabilities offer a consistent attack surface which
needs little analysis or tailoring.

The only vulnerability we've seen (ms11-100) was swiftly dealt with and would
have been eaten by our up front load balancers anyway.

Regarding our application, our test load is 134,000 test cases and 220,000
lines of assertions. I can sleep well at night.

~~~
RyanZAG
I've got to ask: could you share what app or at least industry that app is in?
I've never seen 134,000 test cases before for a web app, and 220,000
assertions to boot. What's the ratio of test cases to code? It sounds like a
record to me!

~~~
meaty
Financial services. Test ratio is 1 test per 6 loc.

Not a record. There are some seriously big apps behind closed doors. Its a
different world to the public facing web.

~~~
EwanToo
Facebook is composed of around 10 million lines of code [1] - the public
facing web is big.

I've no doubt Google looks at that and thinks it's almost trivially small
(Chromium alone is 6.5 million lines [2]).

There's big apps in private, but very few companies are at that scale.

1 - <http://www.quora.com/How-large-is-Facebooks-codebase>

2 - <http://www.ohloh.net/p/chrome>

~~~
joseph_cooney
I've worked in a number of medium to large financial institutions, and 10M LOC
is nothing, really. They had subsystems that were bigger than that by a factor
of 2.

~~~
meaty
yes one of our 3rd party quoting engines' source tops 20mloc of java.

Facebook is a really simple project compared to most of these sort of things.

------
tomkin
I wonder what DHH has to say about all of this? I seem to remember a few of
his posts being pretty harsh on security and security of other platforms. I
can't imagine DHH completely washes his hands of these vulnerabilities?

~~~
rednukleus
<https://twitter.com/dhh/status/289669574427820032>

This was his reaction last time there were posts on HN about security
vulnerabilities in Rails.

~~~
tomkin
Funny he calls HN a cesspool, "It appears that HN is following the law of
large communities: they go to shit." [1] – using Twitter, a community of
millions. Plus, he has posted here as recently as 10 days ago. :D

[1] <https://twitter.com/dhh/status/289728046230028288>

------
sergiotapia
Again? We need a single website alerting RoR devs about vulnerabilities.

I shouldn't have to found out about these things on HackerNews.

Someone build this website for us RoR devs, pretty please? (ps. use PHP - heh)

~~~
static_typed
You could always wait till the server gets compromised, then the customers
could alert you?

~~~
nichols
Actually, that's how security vulnerabilities are normally handled in the Ruby
on Rails world.

What, you think I'm joking? Think again:
[http://arstechnica.com/business/2012/03/hacker-
commandeers-g...](http://arstechnica.com/business/2012/03/hacker-commandeers-
github-to-prove-vuln-in-ruby/)

------
matthuggins
Good explanation, but it sounds like there is a second component to the issue
that this doesn't address: the fact that user input can be converted to
symbols, which will ultimately eat memory as new symbols are created.

------
peterlih
Great job, Thomas!

------
lexy0202
Very good explanation - thanks.

