Ruby on Rails3で作成したアプリのセキュリティチェック その2 HTTPヘッダインジェクション

Ruby on Rails3で作成したアプリのテスト時にチェックするセキュリティについてのまとめです。

環境はruby-1.9.3-p0, rails3.2.2, postgresです。

難易度★★☆☆☆

HTTPヘッダインジェクション

リダイレクトやクッキー発行など、外部からのパラメーターを元にHTTPレスポンスヘッダを出力する際に発生する脆弱性です。
クッキー発行はガラケーの開発以外では関係ないことがほとんどなのでここでは説明しません。
HTTPヘッダインジェクションが発生するのは、リダイレクト時の処理が一番多いでしょう。

パラメーターからurlを取得してリダイレクト

パラメーターからurlを取得する場合に、HTTPヘッダインジェクションの発生に注意する必要があります。

parameter

http://www.yourapplication.com/controller/action?referer=path/at/your/app%0d%0aLocation:+http://www.malicious.tld

上記は?以降にクエリパラメーターを設定しています。%0d%0aは改行のパーセントエンコードです。

code

redirect_to params[:referer]

結論から言うと、railsの場合は上記のようなコードでもHTTPヘッダインジェクションは発生しません。フレームワーク側で対策がしてあります。
railsの開発ではHTTPヘッダインジェクションを意識するケースはあまりないと思います。

HTTPヘッダインジェクションが発生する原因

HTTPヘッダインジェクションは、レスポンスヘッダの改行には特別な意味があるのに、外部から指定された改行コードをそのまま出力するのが問題となります。
parameterの例の場合は後半のURLがLocationに設定されます。つまり、後半のURLページにリダイレクト遷移されてしまいます。
例えば、後半のurlに悪意の第三者が罠のページを仕込むと、利用ユーザーはそちらの罠ページに遷移してしまいます。その罠ページでパスワードやログインIDを入力させることもできます。

urlは仕様として改行文字を使うことができません。なので、本体urlには改行チェックをおこなわないといけません。
しかし、自分で実装して改行をチェックするより、ライブラリを用いて処理するのがもっとも安全です。

railsのredirect_toはHTTPヘッダインジェクションに対応されています。

自分で実装するのを控えるのがHTTPヘッダインジェクションセキュリティ対策の基本です。

---

参考サイト

• Ruby On Rails Security Guide
• Railsノート - redirect_to は安全か？

参考書籍

この記事がお役にたちましたらシェアをお願いします

Tweet