Railsのリモートコード実行脆弱性、今昔
去年、今年とStruts2、Drupalのリモートコード実行脆弱性が問題になりました。記憶に新しい方も多いと思います。Railsにもリモートコード実行脆弱性が複数レポートされており、Railsユーザーであればよくご存知だと思います。
ざっと思い付く昔の脆弱性から最近の脆弱性まで簡単にまとめてみます。
もっと読む去年、今年とStruts2、Drupalのリモートコード実行脆弱性が問題になりました。記憶に新しい方も多いと思います。Railsにもリモートコード実行脆弱性が複数レポートされており、Railsユーザーであればよくご存知だと思います。
ざっと思い付く昔の脆弱性から最近の脆弱性まで簡単にまとめてみます。
もっと読むRailsユーザーがソースコード検査やWebサイト診断を受ける前に真っ先に使った方が良いセキュリティ検査ツールがあまり使われていないように感じています。
Brakemanはかなり良くできたツールです。私は何年も前から補助的に使っています。
先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。
Railsで多用されているActiveRecordのインジェクションパターンを簡単に紹介します。出典はrails-sqli.orgなのでより詳しい解説はこちらで確認してください。特に気をつける必要があると思われる物のみをピックアップしました。
Railsアプリケーションを作る機会も多くなったと思います。今までPHPのみを使ってきた方の為に、開発者がよく落ちてしまうRails/Rubyの落とし穴を少しだけ紹介します。RailsからWebアプリをはじめる方にも役立つと思います。
RailsはJavaScript文字列エスケープメソッドをサポートしています。JavaScript文字列エスケープのエントリで様々な議論があったようです。弊社ではRailsアプリのソースコードも検査しているので、参考としてRailsのソースコードを確認したことを追記をしたました。Rails開発者に直して頂きたいので独立したエントリにしました。
参考:
前回公開したRails4セキュリティのスライドは誤解をされる可能性があるのでは?と指摘される方も居たので「Rails4セキュリティ リローデッド」として追加情報を加えたスライドを作ろうかと思っていました。確かに、今見直したら肝心な所で追加し忘れてる部分があって誤解しやすい、というか言いたい事が分からないかも知れません。
入力パラメータをバリデーションするとは、バリデーションするメソッドを作ってバリデーションする、ことです。必須・許可設定だけだとモデルに渡すデータがどれかしか分かりません。許可設定と同時にバリデーションする事が良い、という事です。少なくともここだけは直した方が良さそうです。
あまり時間が取れなかったのでスライドを作るために作ったメモを取り敢えず公開します。スライドにして欲しいという方が多ければスライドにするかも知れません。
メモを読む前に「モデルで処理に利用すべきパラメータが指定してある場合、モデルで指定外のパラメータをバリデーションすべきか?」を考えてから読むと解りやすいかも知れません。
関連エントリ
http://blog.ohgaki.net/rails4-security
岡山Ruby会議02が先週末の土曜日にありました。私は「Rails 4 セキュリティ」をテーマに講演させていただきました。
プレゼン資料だけでは分かりづらいと思いますが、参考までに公開します。
追記:肝心なところで記述漏れがあり、誤解もあったので解説を追加しています。こちらも合わせてご覧ください。
多分、WindowsにRails4をインストールしようとして困っている方も多い(?)と思うので簡単にエントリを書きました。
Rails4をWindowsで使うにはWindows版のRuby 2.0とDevKitがあれば良いとあったのでこれらをインストールした後に
gem install rails
を実行するとしばらくするとインストールが完了したが、テストアプリを作り実行しようとしたら もっと読む
Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由を詳しく解説されたブログエントリをまっちゃさんのブログで知りました。 入力で特には何もしていない事は知っていたので、出力時のどこかで全体をチェックできるような仕組みになっているのでは?と思っていたのですが、ETagの値を生成するコードの正規表現で例外が発生する、という事だそうです。 もっと読む
1.2.4などで修正を試みたセキュリティ上の問題が完全ではなかったようです。
セッションIDの固定化が可能な脆弱性が(こんどは完全に?)修正されたようです。
The rails core team has released ruby on rails 1.2.6 to address a bug in the fix for session fixation attacks (CVE-2007-5380). The CVE Identifier for this new issue is CVE-2007-6077.
PHPの場合、Session Adoptionに脆弱(普通にアプリを作るとSession Fixationにも脆弱なる設定がついこの間までデフォルト…)ですがいつ直すつもりなんでしょう… パッチはあるのですけどね…
MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。(PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります)この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。
Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。
PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が追加されていたりするので、たまたま最近読んだRoRの本だけでなく、多くの開発向け情報ソースにSET NAMESを利用した例が載っていると思います。
ストアドプロシージャだけ使っていれば安全ですが、アプリケーションからDBMSの文字エンコーディングを設定する場合、SQL文ではなく必ず文字エンコーディング設定APIを利用するよう紹介しなければならないです。MySQL4はストアドプロシージャが使えないので、フレームワークなどではエミュレートしています。ストアドプロシージャだけ使って防御している「つもり」で防御になっていない場合もあります。これもフレームワークを使っていてもアプリケーションが脆弱になる良い例ですね。
脆弱性の説明は面倒ですが注意事項は簡単です。「DBMSをアプリケーションから利用する場合、文字エンコーディング設定は必ずAPIを利用する」つまり「SET NAMES(PostgreSQLのSET CLIENT_ENCODING等も)は禁止」です。
PHPのMySQL:
PHPのPostgreSQL:
PHPのPDO:
<?php // MySQL $pdo = new PDO( 'mysql:host=yourhost;dbname=yourdb;charset=sjis', 'user', 'password' ); // PostgreSQL $pdo = new PDO( "pgsql:host=yourhost;dbname=yourdb;options='--client_encoding=sjis'" );
Rails:
config.encoding = 文字コード
Rubyを使っている方やMLを覘いている方(私はこちらです)はWebフレームワークのRuby on Railsをご存知と思います。Ruby使いではないのでMLをさらっと横目で見ている程度なので詳しくは知らなかったのですが
http://www.rubyonrails.org/
にQuickTimeの紹介ムービーがあったので見てみました。10分ほどのムービーですが簡単にWebアプリケーションが作れる事が分かります。
Rails、面白そうですね。MLで盛り上がる訳ですね :)