12 ms·
Attacking Ruby on Rails applications (2016)
- rmoriz 7y agoThis is from 2016
- dang 7y agoAdded above. Thanks!
- peteforde 7y agoI 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.
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- dwheeler 7y agoIf 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 7y agoStatic 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 7y agoReally? 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 7y agoI 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 7y agohttps://github.com/presidentbeef/brakeman https://github.com/presidentbeef/brakeman link to mentioned app for those interested.
- slimed 7y agoThe bar is low for such tools regardless of programming language. In a language as dynamic as Ruby it's several miles into the Earth's crust. The tool won't be able to tell you much of anything you shouldn't already know. "Potentially high-impact web vulns" is a next to useless metric when provided by such a tool. The rate of false positives is high. A distraction such as this when your application surely has more serious vulnerabilities is not helpful.
- atom_enger 7y agoI 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-in-rails-9e368836fac1?gi=9bcb3cdf5726 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 7y agoThe 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.
- greenie_beans 7y agoCan't this be solved with scoping via the pundit gem, as well?
- atom_enger 7y agoYou'd suspect right :) I've had a huge number of bounties from this as a result of finding the pattern first on Reverb.
- gargarplex 7y agoI 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 7y agoI 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 7y agoThe 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 7y agoI 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. :)
- gargarplex 7y agoI 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.
- hajimuz 7y agoI like the format of this post very much. Plain text yet clean and navigatable. Is there any tool for this?
- 1vasari 7y agoNo. It's plain text
- 1propionyl 7y agoI 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 7y agoThe year is 2020, developers demand decent tooling for authoring and publishing plaintext.
- capableweb 7y agoPretty 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 7y agoI suspect the best of those tools will be called Emacs and vim for some more decades.