本日、Django1.4.11, Django1.5.6, Django1.6.3, Django1.7 beta 2 が セキュリティプロセスの一環 としてリリースされました。 PyPI と ダウンロードページ から入手できます。

このリリースでは、予期しないコードが実行される問題、 CSRF を引き起こす問題、そしてMySQL型キャストの問題を対象にしています。 問題が全Djangoユーザーには影響するわけではありませんが、リスク回避のために可能な限り早くアップデートしてください。

問題の詳細は下記を参照してください。

reverse()により予期しないコードが実行される問題

DjangoのURLの扱いは、view callableに対する正規表現マッピング(つまりURLs)をベースにしています。 Django内の処理ではリクエストされたURLを各正規表現のパターンにマッチさせて、実行させるviewを特定しています。

Djangoは上記の処理と逆のことをする django.core.urlresolvers.reverse() も提供しています。 reverse() 関数は view に関する情報をうけとり、viewを実行するためのURLを返します。 reverse() の返り値は常に現在のURLパターンを基本にしているので、アプリケーション開発者には reverse() の使用が推奨されています。これで開発者はURLsを変更しても他のコードを修正しなくて済むようになります。

reverse() への識別子としての引数は対象viewへのドット区切りのPythonパスで表されます。この場合Djangoは結果のURL生成のために、パスが指すモ ジュールをインポートします。このモジュールがimport時の副作用を含む場合、その副作用が実行されてしまいます。

なのでこれは攻撃者に予期しないコードの実行を許可してしまいます。以下を満たす場合です:

  1. ユーザーインプット由来の値でURLが生成されるviewがある (クエリ文字列中の "next" パラメータで完了ページ(view)を指定している場合などが考えられます)
  2. インポートによる副作用があるモジュールが、サーバー内に存在すると攻撃者に知られている

修正のため、reverse()は、URLパターン内に列挙されているviewを含むパスのみを許可するよう修正されました。 このやり方でインポートすると指定したモジュールのみがインポートできるようになっています。

未ログインページのキャッシュによりCSRFトークンが漏れる問題

Djangoはキャッシュフレームワークと、クロスサイトリクエストフォージェリ(CSRF)攻撃を防ぐシステムを提供しています。 CSRFプロテクションシステムは、ランダムな文字列をクッキーでクライアントに送り、その文字列が後にリクエストから返されることを基礎としています。この文字列はformからhidden valueとしてサーバーに返信されます。

キャッシュフレームワークは匿名(未ログイン)クライアントへのレスポンスをキャッシュするオプションを提供しています。

あるページヘの最初の匿名リクエストでクライアントがCSRFクッキーを持っていない場合、キャッシュフレームワークはCSRFクッキーをもキャッ シュしてしまい、他のCSRFクッキーを持たない匿名ユーザーへ同じ文字列を送信してしまいます。これは攻撃者に有効なCSRFクッキーを与えることにな り、クッキーへのチェックを回避する攻撃を引き起こします。

これの修正として、キャッシュフレームワークはこのようなレスポンスをキャッシュしないようになりました。手順は以下のようになります:

  1. リクエストがクッキーを1つも送信しておらず
  2. レスポンスが1つ以上のクッキーを送信しており、
  3. Varyの場合はクッキーヘッダーがレスポンスに設定されており、レスポンスがキャッシュされていない場合。

MySQL型キャストの問題

MySQLデータベースは特定クエリにおいて'型キャスト'(typecast)するものとして知られています 。例えばstring値を含むテーブルに対してinteger値を基本にしたフィルターをした場合、MySQLは暗黙のうちにstringをintegerにし、結果を返します。

適切な型への変換が発生しない場合、クエリ自体に変更が入った場合と変わらないような予期しない結果が返ります。

Djangoのモデルフィールドクラスはそれぞれの型を考慮し、クエリ実行の前にデータベースレベルで正しい型に各クエリ引数を変更します。 しかし、以下3つのモデルフィールドは引数を正しく変換していませんでした:

* FilePathField
* GenericIPAddressField
* IPAddrennField

この3フィールドはクエリ実行前に正しい型に引数を変更するよう修正されました。

さらに、カスタムモデルフィールドの開発者に対して適切な型への変換を提供するようドキュメントで注意書きが追加されました。 生SQLやSQLフラグメントを可能にするraw(), extra()クエリメソッドの利用者も、クエリ実行前にマニュアルで正しい型に変換するよう注意してください。

(原文は以下にあります。文章におかしなところがあればコメントか @hirokiky に連絡してください https://www.djangoproject.com/weblog/2014/apr/21/security/)

UbuntuのSecurityNoticeではこちら http://www.ubuntu.com/usn/usn-2169-1/

Currently unrated
  • Share

Comments

There are currently no comments

New Comment

* Please fill all required form field, thanks!