Attacking Ruby on Rails applications (2016)
1–10 of 41 posts
Re: Attacking Ruby on Rails applications (2016)
#2This is from 2016
Re: Attacking Ruby on Rails applications (2016)
#3I 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.
Re: Attacking Ruby on Rails applications (2016)
#4[deleted]
Re: Attacking Ruby on Rails applications (2016)
#5If 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.
Re: Attacking Ruby on Rails applications (2016)
#6I 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!
Re: Attacking Ruby on Rails applications (2016)
#7I 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]
Re: Attacking Ruby on Rails applications (2016)
#8I 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.
Re: Attacking Ruby on Rails applications (2016)
#9This is from 2016
Added above. Thanks!
Re: Attacking Ruby on Rails applications (2016)
#10If 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…
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.