11

この質問は、コーディング方法に関する直接的な質問ではなく、再保険に関するものです。独学者として、私は専門家にそのようなことを尋ねる機会があまりなかったので、ここで試してみました.

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) そのような危険性についてさらに読むための貴重なリンクはありますか?

これらの質問のいくつかは十分な情報に基づいていないように聞こえるかもしれませんが、私はそれを乗り越えようとしています. 誰かが私を助けてくれたらとてもうれしいです。

4

2 に答える 2

10

CSRF 攻撃は、被害者のブラウザに偽造されたリクエストを送信させることに関するものです。GET メソッドと POST メソッドの両方でこれを行うには、単純な<img>または自動的にサブミットさ<form>れるだけで十分です。また、リクエストがブラウザによって送信されると、認証資格情報も一緒に送信されるため、リクエストは基本的にユーザーのアクションによって開始されたものと変わらないため、サーバーの観点からはリクエストが本物で正当であるように見えます。

CSRF トークンは、まさにそのために使用されます。ユーザーによって開始されたリクエストと、サード パーティのサイトによって偽造されたリクエストとの違いを確立します。この目的のために、CSRF トークンは、サーバーとユーザーだけが知っている秘密として機能します。サーバーは、ドキュメントのシークレットをレスポンスに入れ、次のリクエストでそれが送り返されることを期待します。

また、シークレットはこの特定のユーザーに割り当てられた応答のドキュメントに埋め込まれているため、攻撃者はその特定の応答を盗聴するか、他の方法でドキュメントにアクセスする必要があります。確かに、CSRF トークンを取得する攻撃があります (例:盗聴MITMXSSなど)。しかし、これらの攻撃から保護されていれば、攻撃者は本物のリクエストを偽造することができなくなります。

于 2012-03-31T16:16:01.117 に答える
8

CSRF攻撃

imgコード (通常はまたはを介し​​たリクエストform) を別のサイト (おそらく何らかの権利を持っているサイト)に挿入した Web ページを表示させます。

無害な例

<img src="http://www.yoursite.net/changelanguage?lang=fr">

私はあなたのセッションの言語を残酷にフランス語に変更しました。いやいや!csrf 保護を安全に削除して、データベース ヒットを保存できます。

危険な例

<img src="http://www.yourbank.net/sendmoney?amt=9999&account=123>

yourbank.net にログインしている場合 (および csrf やその他の保護機能がない場合) は、アカウントが軽くなったように感じるはずです。(私は123歳です。)

<img src="http://www.yoursite.net/admin/users/123/edit?admin=1">

あなたが管理者として yoursite.net にログインしていた場合、私たちは両方ともログインしています。(私は123歳です。)

于 2015-08-07T02:56:46.783 に答える