使い方¶

'django.contrib.csrf.middleware.CsrfMiddleware' ミドルウェアを MIDDLEWARE_CLASSES に追加してください。このミドルウェアは SessionMiddleware よりも後にレスポンスを処理せねばならないので、リスト中の SessionMiddleware よりも前に配置します。また、圧縮のような操作が入る前のレ スポンスを処理せねばならないので、 GZipMiddleware よりも後に配置します。

仕組み¶

CsrfMiddleware は以下のような処理を行います:

1. CsrfMiddleware は、サーバから出てゆくレスポンス内の ‘POST’ フォーム全て に対して ‘csrfmiddlewaretoken’ という名前の隠しフィールドを追加します。 このフィールドの値はセッション ID とシークレット文字列の和をハッシュした ものになります。セッション ID が設定されていない場合、レスポンスに対する 変更は行いません。このため、セッションをともなわないリクエストに対しては 非常にわずかなパフォーマンスペナルティしかもたらしません。
2. セッションクッキーのセットされた全ての POST リクエストに対し、 ‘csrfmiddlewaretoken’ がセットされていて、かつ正しい値になっているか調べ ます。正しい値でなければ、 403 エラーを返します。

これらの処理により、あなたのウェブサイト由来のフォームだけが POST を送り返 せるようになります。

このミドルウェアは、 HTTP POST リクエスト (と POST フォーム) だけを対象にし ています。 GET リクエストには危険な副作用を持たないはず (RFC 2616: HTTP 1.1 の 9.1.1 節、「安全なメソッド」 を参照) なので、 GET リクエストを使った CSRF 攻撃は威力を持たないのです。

セッションクッキーを伴わない POST リクエストは保護されませんが、セッション クッキーを伴わないようなフォームに対しては、攻撃側のウェブサイトはリクエス トをどのようにでも作れてしまうので、そもそも保護する意味はありません。

CsrfMiddleware はレスポンスを変更する前に Content-Type をチェックし、 ‘text/html’ または ‘application/xml+xhtml’ のページだけを変更します。

制限¶

CsrfMiddleware を動作させるには、 Django のセッションフレームワークが必要で す。手動でクッキーを設定するカスタムの認証システムなどを使っている場合には うまく動作しません。

アプリケーションで HTML ページやフォームを普通とは違うやり方で生成している 場合 (JavaScript の document.write 文などで HTML フラグメントを送信するよう な場合)、フォームの隠しフィールドを追加するフィルタを回避してしまうかもしれ ません。そのような場合、フォームの提出は常に失敗してしまいます。ただし、 CSRF 対策トークンを取得し、提出されるフォームに必ずトークンが入るようにすれ ば、このミドルウェアを使う余地はあるでしょう。