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!
I suspect an insane number of websites are validated only by the frontend and can be exploited like this.
(In at least one prior edition, it had an entry of its own as "Insecure Direct Object Reference".)
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.
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.
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).
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.
(source: a few years of webapp pentesting and Rails app dev)
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
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 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.
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.
