Rubyが危ない?!クラス汚染が引き起こす“アプリ全崩壊”の可能性：2025/02/06
- 晋次 宮田
- 2025年2月6日
- 読了時間: 2分
クラス汚染とは？
2024年10月2日付で公開されたDoyensecのブログ記事では、Rubyにおける「クラス汚染（Class Pollution）」という概念が取り上げられました。
クラス汚染（Class Pollution）:「Rubyの動的機能（eval, send, class_eval など）を悪用して、既存クラスの定義や挙動を 意図せず書き換えてしまう（汚染する） 攻撃」を指す。
Rubyの動的再定義・メタプログラミングは非常に強力で便利ですが、使い方を誤ると攻撃者にとっての“裏口”になります。
「あ〜evalインジェクション？そもそもeval使わね〜し」
と思うかもしれませんが、改めてリマインド的にご紹介します。
（タイトルがちょっと釣りっぽくてすみません。。）
どんな攻撃があるのか？
● eval の悪用例
# 危険な例
def run_user_input
user_code = params[:code] # ユーザー入力
eval(user_code) # 文字列をそのまま実行
end
攻撃者が「system('rm -rf /')」のようなコードを送れば、サーバー上で任意のコマンドを実行できます。
● send の悪用例
def call_dynamic_method
method_name = params[:method]
SomeModel.send(method_name)
end
method_name に「destroy_all」などが指定されると、データの削除や不正操作が行われる可能性があります。
● class_eval でクラスを書き換え
FooClass.class_eval(params[:body])
受け取った文字列で既存クラスを上書きし、アプリ全体が侵害されるリスクがあります。
なぜ危険？
コードインジェクション: これらの動的メソッドを誤用すると、任意のRubyコードが実行できてしまい、サーバーをほぼ自由に操られます。
SQLインジェクション以上の範囲: データベースだけでなく、ファイル操作やネットワーク操作まで踏み込めるため、より広範な被害に発展する恐れがあります。
対策は？
危険メソッドを使わない
そもそもevalやclass_evalは極力使わず、通常のRuby構文で実装する。
ホワイトリスト方式
send を使う場合は呼び出すメソッドを限定し、自由に指定させない。
サンドボックス化
どうしても動的コードを実行するなら、Dockerなど隔離環境で行う。
依存ライブラリのチェック
使用中のGemがeval系メソッドを乱用していないか、CVEや脆弱性情報を定期的に確認する。
権限を絞る
万一突破されても被害を最小にするため、root権限での実行は避ける。
まとめ
とりあえずこの記事を書きながら「念の為、動的コードを使っているかだけ確認しておこうかな」という気持ちにはなりました。
引用元
この記事の元になっている詳細情報は、Doyensecの2024年10月2日付ブログで解説されています。より詳しく知りたい方は、下記リンクをご覧ください。
