この質問は、コーディング方法に関する直接的な質問ではなく、再保険に関するものです。独学者として、私は専門家にそのようなことを尋ねる機会があまりなかったので、ここで試してみました.
django-docs ( https://docs.djangoproject.com/en/1.3/ref/contrib/csrf/ ) のドキュメントとそのページの情報を読みました: http://cwe.mitre.org/top25 /#CWE-352
私が理解している限り、django はトークン (ある種の PIN コード) をユーザーに配信します。そして、それが本当に彼のものであることを確認するために、彼は次に要求を行うときにそれを返さなければなりません. Google の何人かは、これが ajax リクエストでも可能であることを発見しました。これが、1.2.6 以降、それらを保護する新しいポリシーを持っている理由です。CSRF とは、他人になりすまして私に何か (悪い、危険なコード、破損したファイル、またはそのようなもの) を与える人に関するものです。
したがって、次のようなコードがある場合:
@csrf_exempt
def grab(request):
"""
view to download an item
POST because it stores that a user has downloaded this item
"""
item_id = request.POST.get('item', None)
if not loop: return HttpResponseBadRequest('no item id provided')
item = Item.objects.get(pk=int(item_id))
指定された値を整数に変換しようとする前に、データベースまたはアプリケーションの一部へのアクセスを許可していないため、保存する必要があります。また、誰かがファイルをダウンロードしたという誤った記録を行っても、それほど大きな被害はありません (この場合はほとんどありません)。この見解に基づいて請求書を作成すると仮定すると、CSRF免除はさまざまな悪い考えになります(そうですか?)。
また、誰かがユーザーから CSRF トークンを盗むことができず、それを使用して私 (またはユーザー) をだますことができない理由もわかりません。だから私はこのトピックについていくつか質問があります:
1)上記の私の仮定は正しいですか?
2) 誰かが私に教えてくれませんか? あまりいい人ではない人が上のビューを使用して汚いトリックを行うことができたのは何 (そしておそらくどのように) でしょうか?
3)CSRFは中間者攻撃の例ですか、それは単にそれに関連しているだけですか、それともまったく別のものですか?
4) そのような危険性についてさらに読むための貴重なリンクはありますか?
これらの質問のいくつかは十分な情報に基づいていないように聞こえるかもしれませんが、私はそれを乗り越えようとしています. 誰かが私を助けてくれたらとてもうれしいです。