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.<p>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: <a href="https://brakemanscanner.org/docs/warning_types/unscoped_find/" rel="nofollow">https://brakemanscanner.org/docs/warning_types/unscoped_find...</a><p>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.<p>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:
<a href="https://product.reverb.com/stay-safe-while-using-html-safe-in-rails-9e368836fac1?gi=9bcb3cdf5726" rel="nofollow">https://product.reverb.com/stay-safe-while-using-html-safe-i...</a><p>Just because this article is old doesn't mean it's not useful. Thanks for posting!
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!):
<a href="https://railroader.org/" rel="nofollow">https://railroader.org/</a><p>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).<p>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).<p>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.
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.<p>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.
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.