Django プロジェクトによる報告：

- ホストヘッダーポイズニング

エンドユーザーが記述したアプリケーションから独立した Django の一部は、
-- ドメイン名を含む完全な URL を利用します。これは、HTTP Host ヘッダーから生成されます。これに対する一部の攻撃者は、Django のコントロール能力を超えており、Web サーバーが適切に構成されていることが必要です。Django の文書には、この構成についてユーザーにアドバイスする記述がしばらくの間含まれていました。

しかし、Host ヘッダーに対する Django の独自のビルトイン解析は、最近弊社に報告されたとおり、依然として脆弱です。Django 1.3 および Django 1.4 の Host ヘッダー解析（具体的には、django.http.HttpRequest.get_host()）は、ヘッダーのユーザー名/パスワードを不適切に処理していました。このため、例えば、次の Host ヘッダーは、「validsite.com」で実行時に Django によって受け入れられました：

Host：validsite.com:random@evilsite.com

これを利用して、攻撃者が、Django の一部（特にパスワードリセットメカニズム）に任意の URL を生成させて、これをユーザーに表示させる可能性があります。

これを修正するために、HttpRequest.get_host() の解析は変更されています。危険な可能性があるコンテンツ（ユーザー名とパスワードのペアなど）を含む Host ヘッダーは、例外 django.core.exceptions.SuspiciousOperation を上げるようになりました。

- HttpOnly クッキーオプションの文書

Django 1.4 では、セッションクッキーは常に HttpOnly フラグとともに送信されます。これは、セッションクッキーに対するクライアント側のスクリプトアクセスを拒否することで、クロスサイトスクリプティング攻撃に対する保護を高めています。

直接的な Django のセキュリティ問題ではありませんが、Django 1.4 の文書が、これは HttpResponse.set_cookie() メソッドによって設定されたすべてのクッキーのデフォルトになったと、この変更を誤って記述していたことが報告されました。

これがセッションクッキーにのみ適用されることを反映するために、Django の文書は更新されました。Django のユーザーは、set_cookie() の使用を確認し、HttpOnly フラグが適切に設定または解除されていることを確かめることが推奨されます。

検出

FreeBSD：django -- 複数の脆弱性（5f326d75-1db9-11e2-bc8f-d0df9acfd7e5）

medium Nessus プラグイン ID 62705

変更ログが見つかりません