Django1.1.4リリースノート
Django 1.1.4へようこそ！
これは、Django 1.1シリーズの4番目の「バグ修正」リリースであり、Django1.1コードベースの安定性とパフォーマンスを向上させます。
1つの例外を除いて、Django1.1.4はDjango1.1.3との下位互換性を維持しています。 また、多くの修正やその他の改善も含まれています。 Django 1.1.4は、現在Django1.1を使用または対象としている開発またはデプロイメントに推奨されるアップグレードです。
1.1ブランチの新機能、後方互換性、および非推奨の機能の詳細については、 Django1.1リリースノートを参照してください。
後方互換性のない変更
AJAXリクエストのCSRF例外
Djangoには、送信フォームに挿入されたトークンを利用するCSRF保護メカニズムが含まれています。 次に、ミドルウェアはフォーム送信時にトークンの存在を確認し、検証します。
Django 1.2.5より前は、CSRF保護により、次の基準でAJAXリクエストの例外が作成されていました。
- 多くのAJAXツールキットは、XMLHttpRequestを使用するときにX-Requested-Withヘッダーを追加します。
- ブラウザには、XMLHttpRequestに関して厳密な同一生成元ポリシーがあります。
- ブラウザのコンテキストでは、この性質のカスタムヘッダーを追加できる唯一の方法は、XMLHttpRequestを使用することです。
したがって、使いやすさのために、X-Requested-Withヘッダーに基づいてAJAXであると思われるリクエストにはCSRFチェックを適用しませんでした。 Ruby on RailsWebフレームワークにも同様の免除がありました。
最近、Googleのエンジニアは、Ruby on Rails開発チームのメンバーに、ブラウザプラグインとリダイレクトの組み合わせを認識させました。これにより、攻撃者は任意のWebサイトへのリクエストにカスタムHTTPヘッダーを提供できます。 これにより、偽造されたリクエストがAJAXリクエストのように見える可能性があり、それにより、AJAXリクエストの同一生成元の性質を信頼するCSRF保護が無効になります。
RailsチームのMichaelKoziarskiがこれに注目し、DjangoのCSRF処理に同じ脆弱性があることを示す概念実証を作成することができました。
これを修正するために、Djangoは、明らかなAJAXの発信元に関係なく、すべてのリクエストに完全なCSRF検証を適用するようになりました。 これは技術的には下位互換性がありませんが、この場合、セキュリティリスクが互換性の懸念を上回ると判断されています。
さらに、DjangoはカスタムHTTPヘッダーX-CSRFTOKENとフォーム送信自体でCSRFトークンを受け入れるようになり、すべてのAJAXリクエストにカスタムヘッダーを挿入できる一般的なJavaScriptツールキットで使いやすくなりました。
必要な正確なコードはDjangoの古いバージョンによって異なるため、この手法を示す CSRFドキュメント（jQueryコードなど）を参照して、Djangoのバージョンのドキュメントを確認してください。
