Attacking Ruby on Rails applications (2016)

Attacking Ruby on Rails applications (2016)(phrack.org)

131 points by bryan_cooper 6 years ago | 37 comments

atom_enger 6 years ago |

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...

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...

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

Polylactic_acid 6 years ago | |

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 6 years ago | | |

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

greenie_beans 6 years ago | | |

Can't this be solved with scoping via the pundit gem, as well?

mytailorisrich 6 years ago | |

It should be said that an "unscoped find" is a generic and serious design flaw, which isn't specific to Rails.

rst 6 years ago | | |

It's on the current OWASP top ten as one case of "Broken Access Control" (scenario 1): https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top...

(In at least one prior edition, it had an entry of its own as "Insecure Direct Object Reference".)

tptacek 6 years ago | |

In practice, XSS is largely mooted by the rise of front-end frameworks like React, Vue, and Angular, which are the modern norm for delivering UI (I don't think we have a single client that uses serverside-templated-HTML anymore), and the front-end framework approach is better than the Rails/Django approach; I'm very unlikely to find XSS in a simple React app, but not at all unlikely to find it in a Rails app, because people always dip out of the XSS protection to do programmatic tags.

adrianmsmith 6 years ago | | |

I think making the mistake of "unscoped find" that "atom_enger" was referring to is just as easy a mistake to make when writing a REST backend (to support a SPA front-end framework) as when using a traditional non-SPA web framework.

It's tempting, when writing a REST backend, to respond to e.g. "PUT /message/:id" by just executing "UPDATE ... WHERE message_id=?" from the parameter, without checking that that message belonged to the user whose credentials have been used to access the call.

That's possible with a non-SPA web framework, and it's also possible when writing REST backends.

seisvelas 6 years ago | | |

> I'm very unlikely to find XSS in a simple React app

I do offensive security. A lot of developers are ignorant of when/how React apps tend to be XSS vulnerable. Since it has a reputation as being 'safe' from XSS, devs often assume it's just something they don't have to worry about.

This has led to a small renaissance of XSS bug bounties on sites like hackerone, where you see a lot of specialists who just go around finding obvious, common XSS vulns in eg Angular apps.

greenie_beans 6 years ago | |

Thanks for sharing this. I'm new-ish to web dev and have considered a similar pivot. Also a customer on Reverb so that's cool to hear your story and read that write up you linked.

peteforde 6 years ago | |

Don't get me wrong: I'm really glad that you caught the bug in your code before anyone lost an eye.

However, a critical summary of your situation could be "improperly used an advanced method that exists for the specific purpose of marking a string as having been certified safe, potentially allowing an XSS that would have otherwise been successfully filtered out by Rails' extensive anti-XSS mechanisms".

I was super upset when one of the drives in my RAID 0 set went, but it was still my bad for not learning that RAID 0 isn't mirroring. (Hint: the 0 is the amount of information you can recover in case of failure.)

My point is just that you can't really claim that Rails dropped the ball here. If there are footguns installed, it's because you installed them (and didn't read the manual for html_safe).

dwheeler 6 years ago |

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/

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 6 years ago | |

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 6 years ago | | |

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)

SmileyJames 6 years ago | |

I installed and ran railroader.

It encountered an error: /var/lib/gems/2.5.0/gems/sexp_processor-4.13.0/lib/sexp.rb:222:in `line': setting s(:args).line nil (ArgumentError)

ruby 2.5.1p57

peteforde 6 years ago |

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 6 years ago |

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

1vasari 6 years ago | |

No. It's plain text

1propionyl 6 years ago | | |

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.

rmoriz 6 years ago |

This is from 2016

dang 6 years ago | |

Added above. Thanks!

gargarplex 6 years ago |

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 6 years ago | |

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.

gargarplex 6 years ago | | |

I never claimed whatsoever that Rails itself is inherently more vulnerable. I made my comment with having maintained Rails apps for many years and watching the CVE list.

1propionyl 6 years ago | | |

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.