Railsのリモートコード実行脆弱性、今昔

去年、今年とStruts2、Drupalのリモートコード実行脆弱性が問題になりました。記憶に新しい方も多いと思います。Railsにもリモートコード実行脆弱性が複数レポートされており、Railsユーザーであればよくご存知だと思います。

ざっと思い付く昔の脆弱性から最近の脆弱性まで簡単にまとめてみます。

“Railsのリモートコード実行脆弱性、今昔” の続きを読む

Railsユーザーが真っ先にするべきセキュリティチェック – Brakeman

Railsユーザーがソースコード検査やWebサイト診断を受ける前に真っ先に使った方が良いセキュリティ検査ツールがあまり使われていないように感じています。

Brakemanはかなり良くできたツールです。私は何年も前から補助的に使っています。

“Railsユーザーが真っ先にするべきセキュリティチェック – Brakeman” の続きを読む

Rails ActriveRecordとSQLインジェクションと実際のアプリケーション

先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。

 

“Rails ActriveRecordとSQLインジェクションと実際のアプリケーション” の続きを読む

RailsのJavaScript文字列エスケープ

RailsはJavaScript文字列エスケープメソッドをサポートしています。JavaScript文字列エスケープのエントリで様々な議論があったようです。弊社ではRailsアプリのソースコードも検査しているので、参考としてRailsのソースコードを確認したことを追記をしたました。Rails開発者に直して頂きたいので独立したエントリにしました。

参考:

“RailsのJavaScript文字列エスケープ” の続きを読む

Rails4セキュリティ リローデッド(仮)

前回公開したRails4セキュリティのスライドは誤解をされる可能性があるのでは?と指摘される方も居たので「Rails4セキュリティ リローデッド」として追加情報を加えたスライドを作ろうかと思っていました。確かに、今見直したら肝心な所で追加し忘れてる部分があって誤解しやすい、というか言いたい事が分からないかも知れません。

入力パラメータをバリデーションするとは、バリデーションするメソッドを作ってバリデーションする、ことです。必須・許可設定だけだとモデルに渡すデータがどれかしか分かりません。許可設定と同時にバリデーションする事が良い、という事です。少なくともここだけは直した方が良さそうです。

あまり時間が取れなかったのでスライドを作るために作ったメモを取り敢えず公開します。スライドにして欲しいという方が多ければスライドにするかも知れません。

メモを読む前に「モデルで処理に利用すべきパラメータが指定してある場合、モデルで指定外のパラメータをバリデーションすべきか?」を考えてから読むと解りやすいかも知れません。

関連エントリ

 http://blog.ohgaki.net/rails4-security

 

“Rails4セキュリティ リローデッド(仮)” の続きを読む

岡山Ruby会議02のプレゼンテーション資料「Rials4 Security」

岡山Ruby会議02が先週末の土曜日にありました。私は「Rails 4 セキュリティ」をテーマに講演させていただきました。

プレゼン資料だけでは分かりづらいと思いますが、参考までに公開します。

Rails4Security.pdf

追記:肝心なところで記述漏れがあり、誤解もあったので解説を追加しています。こちらも合わせてご覧ください。

http://blog.ohgaki.net/rails4

“岡山Ruby会議02のプレゼンテーション資料「Rials4 Security」” の続きを読む

Rails4 Windows `require’: cannot load such file — sqlite3/sqlite3_native (LoadError)

多分、WindowsにRails4をインストールしようとして困っている方も多い(?)と思うので簡単にエントリを書きました。

Rails4をWindowsで使うにはWindows版のRuby 2.0とDevKitがあれば良いとあったのでこれらをインストールした後に

gem install rails

を実行するとしばらくするとインストールが完了したが、テストアプリを作り実行しようとしたら “Rails4 Windows `require’: cannot load such file — sqlite3/sqlite3_native (LoadError)” の続きを読む

Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由

Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由を詳しく解説されたブログエントリまっちゃさんのブログで知りました。 入力で特には何もしていない事は知っていたので、出力時のどこかで全体をチェックできるような仕組みになっているのでは?と思っていたのですが、ETagの値を生成するコードの正規表現で例外が発生する、という事だそうです。 “Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由” の続きを読む

Rails 1.2.6 リリース

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にも脆弱なる設定がついこの間までデフォルト…)ですがいつ直すつもりなんでしょう… パッチはあるのですけどね…

SET NAMESは禁止

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:

Rails:

 

Rails

Rubyを使っている方やMLを覘いている方(私はこちらです)はWebフレームワークのRuby on Railsをご存知と思います。Ruby使いではないのでMLをさらっと横目で見ている程度なので詳しくは知らなかったのですが

http://www.rubyonrails.org/

QuickTimeの紹介ムービーがあったので見てみました。10分ほどのムービーですが簡単にWebアプリケーションが作れる事が分かります。

Rails、面白そうですね。MLで盛り上がる訳ですね 🙂