ハクソク

世界を動かす技術を、日本語で。

Ruby on Rails監査完了

347日前原文(ostif.org)

概要

  • Open Source Technology Improvement Fund による Ruby on Rails のセキュリティ監査結果の発表
  • X41 D-Sec、 GitLab、 Sovereign Tech Agency の協力による監査プロセス
  • 監査期間は 2024年12月から2025年3月、合計4ヶ月間
  • 7件のセキュリティ影響を持つ指摘 と 6件のハードニング推奨
  • Ruby on Railsのセキュリティ成熟度の向上と今後の課題提案

Ruby on Rails セキュリティ監査の概要

  • Ruby on Rails は、オープンソースの フルスタックWebアプリケーションフレームワーク
  • Model-View-Controllerパターン に基づく データベース連携型Webアプリケーション開発 を支援
  • X41 D-Sec、 GitLab Security Research Team、 Sovereign Tech Agency の協力体制
  • 監査期間は 2024年12月～2025年3月、4ヶ月間、 5つのステークホルダー が参加
  • 監査および報告は X41 D-Sec が担当、 GitLab がサポート

監査プロセス

  • 監査開始時に 脅威モデル を作成
    • 機能、デプロイシナリオ、エントリポイント、信頼境界、脅威、Rails固有の脆弱性を定義
  • 脅威モデリング後に 手動コード監査 を実施
    • ツール や ファザー を活用したコードベースの検証
  • X41 D-Sec による調査・分析体制

監査結果

  • セキュリティ影響を持つ指摘：7件
    • 高リスク：1件
    • 低リスク：6件
  • ハードニング推奨事項：6件
  • カスタム脅威モデリング を通じたセキュリティ評価
  • Ruby on Rails のセキュリティ成熟度の向上を評価
  • プロジェクトの規模や期間制約により未カバー領域も存在

謝辞と今後

  • Railsメンテナ、 コミュニティ への感謝
  • X41 D-Sec （Eric Sesterhenn, J.M., Markus Vervier, Robert Femmer, Antonela Conti）への特別な謝意
  • GitLab （Joern Schneeweisz）、 Sovereign Tech Agency への協力感謝
  • 監査レポート はこちら
  • X41 D-Secのブログ はこちら
  • OSTIF 10周年記念ミートアップ 案内
    • 活動報告、学び、OSSセキュリティの未来展望
    • ミートアップカレンダー：https://lu.ma/ostif-meetups

Hackerたちの意見

Djangoもやってくれないかな？

└

一つはお金を払ってでもできるよ。早い、安い、いいのどれか二つを選んでね。多分、非営利の基金がこのRoR監査に数万ドル払ったんだろうね。Djangoの監査のために同じ金額を集めるか、既に集めたお金を使ってくれる基金を説得できる？できたら最高だね！

いいニュースだね！Railsの大ファンだけど、こんなに脆弱性が少ないとは正直驚いたよ。こんな大きなコードベースなのに、もっとあると思ってた。でも、ないって聞いて嬉しい！

└

コードベースの完全な監査を意図しているわけではないと思うし、実際、最終報告書にもそれが示唆されてるよね[0]（ただ、言い回しが変で、以前の報告書から更新するのを忘れたのかも）：> Ruby on Railsのサイズのため、以下のテストプランのすべてのテストとタスクをカバーすることはできません。実施されたテストは最終報告書に含まれ、今後の監査で注力すべき点についての提案もあります。こういう監査は通常、成熟した広く使われているフレームワークよりも、個別のアプリケーションに対して行われる印象があるね。開発者が何をしているかを確認するためのもので、コードベースについて何かを証明するためではないと思う。まあ、何もしないよりはマシだけど。[0] セクション3.7, https://ostif.org/wp-content/uploads/2025/06/X41-Rails-Audit...

Railsアプリケーションサーバー（例：Puma、Unicorn） それはRackアプリケーションサーバーと呼ぶ方が適切だと思うよ。RackはRuby CGI Railsが実装しているものだから。ちょっとした指摘だけどね。

Ruby on Railsのセキュリティ向上に向けた努力を見られて嬉しいよ。正直、これでフレームワークがまだ最も実用的な選択肢だと思う。

B2Bの「CRUD」ソフトウェアにおけるRailsの生産性は比類がないね。もっと新しいスタートアップが使ってるのを見ないのが意外だよ！

└

2012年のシーンは全部Railsを使ってたんだ。でも、スケールするのが難しいことに気づいて、全部Goで書き直したんだよね。

└

エリクサーとフェニックスで数年プログラミングしてきたけど（その前にレールズの経験がたくさんあった）、レールズを選ぶ理由が全然わからない。エリクサーはパフォーマンスが高いし、コンパイラの安全性もどんどん良くなってるし、ウェブ開発のためにゼロから設計されてる（アーランVMをベースにしてるからね）。それに…単純に楽しいんだよね（主観的なのはわかってるけど）。エリクサーは、僕がいつもルビーに求めていたものだし、これからの型推論が楽しみで仕方ない。エリクサーでプログラミングしてると、ルビーが古い世代の言語に感じる。ルビーがコボルやフォートランに対してそう感じさせてくれたのと同じくらい、ほんとにその差は大きい。

└

僕は約7年間レールズのコンサルタントをやってた。その後、好奇心からフェニックスに切り替えたんだけど、それ以来振り返ったことはないよ。「シンプルがベター」って哲学を信じてなかった人も、フェニックスを使ったらそう思うようになるよ。開発時間は短くなるし、コンパイル時にバグをキャッチできるから、バグもずっと少ない。開発体験は比類がないよ。それに、パフォーマンスも言ったかな？箱から出しただけで驚異的なパフォーマンスが得られるよ。

└

RoRの人気が落ちた原因は何だろう？約10〜12年前にはRoRがスタートアップのデファクトスタンダードだったように思う。ある日のHNのフロントページには、RoRに関する複数のアイテムがあったよね。

└

こんなに多くの生成AIツールがある中で、もっとマイナーな言語を選ぶのはマイナスだよ。AIモデルは、何かを頼んだときに引き出せるトレーニングの深さが少ないからね。それに、B2Bウェブアプリの技術選択は、ビジネスの成功や失敗を決定する唯一の要因にはならないことが多い。コミュニティがパフォーマンス指標やベンチマーク、フレームワークを比較するのが好きだけど、みんなが「良い」と思うものには個人の好みがあるから、そういう議論はほとんど無意味だよ。チームが快適に使えるもの、そして知識が深いものを選ぶのが良いプラクティスだね。だから、レールズを選んでビジネスの問題を解決することに集中しよう！

└

真面目な質問だけど、みんなルビーを書くの楽しんでるの？僕はなんかバッシュみたいな言語で書いてる気がする。RustやZig、C#を触って、プログラミング言語理論を少し学ぶまでは、こんな風に感じたことなかったんだ。その後、ルビーのゆるくてふわふわした感じが本当に気になり始めた。あと、知ってるルビーのプログラマーはみんな、他の動的言語（Pythonとか）しか使ってない気がする。C++のエキスパートで、そこからルビーを始めたって人は見たことないな。

└

なんでそう思うのか教えてくれない？Railsは使ったことないけど、GitlabのRubyコードを理解しようとしたことがあって、正直言って全然理解できないゴチャゴチャだった。大きなコードベースには慣れてるけど、Gitlabはほぼ追いかけるのが不可能で、完全にRubyを使ってるせいみたい。1つのファイルを見れば、コードは結構きれいでちゃんと書かれてるように見えるけど、例えば関数がどこから呼ばれてるのかを調べようとすると…運が良くないと無理だよ！静的型付けもないし、さらに悪いことに、ほとんどすべてが「魔法のように」繋がってる感じ。foo_bar()って関数があって、それをgrepしてもゼロ件。結局、Fooクラスの中にBARを含む文字列のリストがあって、そこから識別子を構築してるのがわかる。ほんと悪夢だよ。でも、Railsを好きな人も多いみたい…なんでだろう？

└

Railsの生産性が「比類ない」っていう考え方は、13年前の名残だね。Railsが好きでもいいけど、今は質の高いフレームワークがいくつもあって、それらはRailsのリアルな欠点に悩まされてないよ。

すべてのセキュリティ監査と同様に、ほとんどの発見はリスクと使いやすさのバランスだね。

みんな、こんにちは！友達からこれがトレンドになってるって教えてもらったよ。プロジェクトについて質問やコメント、フィードバックがあったら教えてね！素晴らしいプロジェクトだったけど、もっと予算があれば、ラズィーやC拡張にもっと時間をかけられたのに。ASANやUBSANで掘り起こせることがあると思うんだ。それから、スプリングやエリクサー、ジャンゴ、フェニックスに関するコメントは、毎年のウィッシュリストに載ってるけど、いつも資金に制限があるんだ。コミュニティや財団、機関が支援できることが重要だからね。もっと大きな助成金を得て、自由にやりたいことができるように努力してるけど、今のところ実現してない。これからも頑張るよ！

Djangoの監査を資金提供するためにお金を払える場所はある？喜んで寄付するよ。

RailsがGET、HEAD、DELETEリクエストに渡されたパラメータ用のparamsを生成するのが面白いよね、実際はそうするべきじゃないのに。デバッグしてるときにこれに気づいたことがあったけど、あんまり気にしてなかった。コードがひどいアプリケーション（例えば、before_actionでグローバルにparamsを検出するような）だと、確かに問題になるかも。

いい推薦だね。これについてのフィードバック: > 「X41は、ユーザー入力でエスケープされていないSqlLiteralオブジェクトの作成を禁止することを推奨していますが、SQLの完全なモデルを優先しています」RailsはすでにArelレイヤーで十分なSQLモデルを持ってるよ。完全かって言うと、そうでもないけど、SQLは標準で実装されることがないから、確かに十分で、非常に組み合わせや拡張がしやすい。残念ながら、コアチームは数回のメジャーアップデート前にArelの公開ドキュメントを廃止しちゃった。でも、Active Recordがモデルを十分に公開していないときは、Arelを使ってるよ。例えば、左開区間を不等式で表現する時とか。時々「プライベートAPI」と呼ばれるけど、誰の私有物でもないし、Arelは最近のリリースではドキュメントがないだけ。推薦の言葉も少しナイーブだね。Rubyで開発者がほとんど何でもやるのを完全に禁止するのはほぼ不可能だから、隔離されたサンドボックスもないし。問題は、彼らがそうしたくないようにするためのインセンティブがあるかどうか。Active Recordはすでに述語ビルダーを通じてバウンド値の優れたサポートを持ってるし、生のユーザー提供値をクエリ文字列に直接連結するのは、ひどいコードだけだよ。それでも、#calculateのように、APIの中で偶然にこれが起こる可能性がある残りの場所については、似たような精神の別の推薦があるかもしれない。つまり、すでにそうでない場合は、Active Recordが生の文字列をエスケープが必要と扱うようにするか、Arel.sql()で明示的にラップされている場合を除いて、Arelノード/ASTを受け入れるか。つまり、開発者に自分の罪を文書で告白させるか、リレーショナルにやらせるってこと。でも、個人的には、魔法使いたちがArelを塔に閉じ込めておくべきじゃないと思う。

└

推薦の言葉は少しナイーブに感じる。なぜなら、Rubyで開発者がほとんど何でもやるのを完全に禁止するのはほぼ不可能だから。 確かに、でもデフォルトは重要だよ。ほとんどの言語では、本当にプライベートなものはないから。C/C++では、生のメモリにアクセスできるし、Rustではトランスミュートできる。Javaでは、クラスローダーをオーバーライドして、JVMに渡される前にクラスを編集できるし、そういうことができる。でも、ほとんどの環境には、ほとんどの開発者が歩く「ゴールデンパス」がある。ドキュメントを削除することがまさにこれをするんだ。開発者に、あるAPIが期待されるゴールデンパスの一部ではないことを示す。すべてのSQLライブラリには、生のSQL文字列をデータベースに渡す方法が必要だよ。（すべてのブラウザフレームワークが生のHTML文字列を埋め込む方法を必要とするのと同じように）。でも、それをやってることを明示的に認める必要があるはず。Rustのunsafeキーワードや、ReactのunsafelySetInnerHTMLみたいにね。否定することじゃなくて、明らかに安全なことを安全にし、危険なことを明らかにしないようにすることが大事なんだ。