
Attacking Ruby on Rails applications (2016) - bryan_cooper
http://phrack.org/issues/69/12.html#article
======
atom_enger
I remember reading this when I was the sole Infrastructure Engineer for
Reverb.com. I knew we were being attacked and I knew we had issues but I
didn't have any idea where to start. This article sparked my interested in
Cyber Security and helped me find a bug in the website that allowed me to set
the CEO's credit card as a primary card on my account in production. That was
an amazing day.

All I had to do was modify a post parameter in flight and the backend would
accept it. Turns out this is what is known as an "unscoped find". More info
here:
[https://brakemanscanner.org/docs/warning_types/unscoped_find...](https://brakemanscanner.org/docs/warning_types/unscoped_find/)

Thanks to the author of the article for inspiring me to dig in the rails
codebase and find vulnerable patterns that I could exploit. Thankfully I was
able to pivot into a cyber security focused career and I credit this article
for starting me down that path.

Rails has a few things going for it that other languages and frameworks don't
but it still lets you shoot yourself in the foot if you're not careful. I
ended up writing a blog article about preventing XSS in rails as a direct
inspiration from the OPs article: [https://product.reverb.com/stay-safe-while-
using-html-safe-i...](https://product.reverb.com/stay-safe-while-using-html-
safe-in-rails-9e368836fac1?gi=9bcb3cdf5726)

Just because this article is old doesn't mean it's not useful. Thanks for
posting!

~~~
Polylactic_acid
The unscoped find issue is fairly easily solved by using devise's current_user
in combination with something like cancancan. Let them send anything as a
param but have the controller blow up if the user doesn't have permission to
access it.

I suspect an insane number of websites are validated only by the frontend and
can be exploited like this.

~~~
atom_enger
You'd suspect right :) I've had a huge number of bounties from this as a
result of finding the pattern first on Reverb.

------
dwheeler
If you're using Ruby on Rails, you should be using a static code analyzer to
look for vulnerabilities. Please take a look at Railroader, an OSS tool I
maintain that does this (and contributors are wanted!):
[https://railroader.org/](https://railroader.org/)

I recommend that you also use a web application scanner like OWASP ZAP and
something to scan your dependencies for known vulnerabilities (e.g., bundle
audit or GitHub's scanner).

That is in addition to normal software development tools like a style checker
(like Rubocop) and a test suite with good coverage (e.g., minitest).

If you develop software, it's going to get attacked. There are some pretty
straightforward ways to help resist attacks, but you have to use them.

~~~
Polylactic_acid
Static code analyzers don't seem to find too much interesting in my
experience. They could basically only find string interpol in queries and uses
of constantize. Ruby is just too dynamic to find any really interesting
issues.

~~~
tprynn
Really? I find that brakeman is a pretty amazing tool which finds a number of
surprising issues. Of course, these days the vast majority of Rails apps
already have brakeman set up, so it's used more as part of the commit process
and less of a "wow, here's a few dozen potentially high-impact web vulns". I
wouldn't hesitate to say that it's the most high-signal SCA tool I've used
across any language/framework.

(source: a few years of webapp pentesting and Rails app dev)

~~~
Polylactic_acid
I ran brakeman on our app and it found a bunch of things that were almost
vulnerabilities because it was unable to work out the source of some data
going in to a potentially unsafe function but after I inspected all of them,
none of them were actual vulnerabilities. Meanwhile a bunch of real issues go
undetected that could have been spotted in a language like rust.

~~~
thrownaway954
[https://github.com/presidentbeef/brakeman](https://github.com/presidentbeef/brakeman)

link to mentioned app for those interested.

------
peteforde
I suppose this is good, since this document was written for Rails 3 and Ruby
1.x; the author mentions that most of the attack vectors stopped working by
Rails 4.1.

We're now well into Rails 6 and Ruby 2.x is in its last year before 3.x rolls
out. So far the sky hasn't fallen.

------
hajimuz
I like the format of this post very much. Plain text yet clean and
navigatable. Is there any tool for this?

~~~
1vasari
No. It's plain text

~~~
1propionyl
I think you've missed the point of what they were asking... which is probably
if there are tools to facilitate authoring and publishing in plain text.

~~~
dmamills
The year is 2020, developers demand decent tooling for authoring and
publishing plaintext.

~~~
capableweb
Pretty sure anyone working in plaintext is using something better than ed or
similar. emacs, vim, and many others are plaintext editors. It's not hard to
imagine we can come up with even better tools for it as well.

~~~
owl57
I suspect the best of those tools will be called Emacs and vim for some more
decades.

------
rmoriz
This is from 2016

~~~
dang
Added above. Thanks!

------
gargarplex
I figure, if you ever want to attack a Rails app (white hat on), go through
the CVE list and try every vulnerability. There's been so many with exploit
codes and it's dubious that every single service is patched.

~~~
peteforde
I figure, if you want to attack literally any app, go through the CVE and try
every vulnerability.

I don't think it's defensible to claim that Rails itself is inherently more
vulnerable than other similar systems. If you disagree, feel free to cite
references.

~~~
1propionyl
The question isn't whether a framework is or is not more vulnerable than other
similar systems.

It is whether using that framework <dis/en>courages developer behavior that
produces more or less vulnerabilities.

Ruby in general almost certainly does encourage dangerous developer patterns,
however I doubt that's the case for Rails in particular as it has largely been
practically a DSL for nearly a decade.

As a corollary of "convention over configuration" and dominant patterns in
popular accessory frameworks however, this only applies so long as you don't
try to be too clever.

~~~
peteforde
I would genuinely appreciate cited references to back up your assertion that
Rails almost certainly does encourage dangerous developer patterns.

I'm not trying to be pedantic; I do hear this sort of claim a lot but when
pressed people rarely have anything more than pearl clutching about various
metaprogramming capabilities that rarely get used outside of blog posts.

In other words, just because you can redefine + doesn't mean everyone is doing
that in production code. :)

