39

「チャレンジトークン」を使用すると、どのような種類の予防策が追加されるのかわかりません。どの値を何と比較する必要がありますか？

OWASPから：

一般に、開発者は現在のセッションでこのトークンを1回だけ生成する必要があります。このトークンの最初の生成後、値はセッションに保存され、セッションが期限切れになるまで後続の各要求に使用されます。

プロセスを正しく理解していれば、これが起こります。

http://example.comにログインすると、このランダムトークンを含むセッション/Cookieが作成されます。次に、すべてのフォームには、フォーム送信時にセッション/ Cookieと比較される、セッションからのこのランダムな値も含む非表示の入力が含まれます。

しかし、それは何を達成しますか？セッションデータを取得してページに配置し、まったく同じセッションデータと比較するだけではありませんか？循環論法のようです。これらの記事では、「同一生成元ポリシー」に従うことについて話し続けていますが、すべてのCSRF攻撃はユーザーと同じ起源であり、ユーザーをだまして意図しないアクションを実行させるため、意味がありません。

トークンをすべてのURLにクエリ文字列として追加する以外の方法はありますか？非常に醜くて実用的ではないようで、ユーザーにとってブックマークが難しくなります。

4

4 に答える 4

37

攻撃者はトークンを取得する方法がありません。したがって、リクエストは有効になりません。

Gnucitizenからのこの投稿をお勧めします。それはかなりまともなCSRFの説明を持っています：http ：//www.gnucitizen.org/blog/csrf-demystified/

于 2010-04-05T22:32:57.143 に答える
21

アナロジーで説明されたCSRF-例：

あなたが鍵、つまりあなたの鍵を使って玄関のドアを開けていると想像してみてください。他の誰もあなたの鍵を持っていません。あなたはドアを開けます–しかし、あなたが中に入る前に、あなたの隣人は道路の向こう側からあなたに電話をかけます、そしてあなたは天気やおそらくトランプ大統領の最新の午前3時45分のツイートなどについて非常に友好的な会話をします。あなた、他の誰かがあなたを外で見て、あなたと同じ服と髪のスタイルを身に着けてあなたになりすますことを決心し、あなたになりすましてあなた自身の家に入ることに決めます！

あなたの家の中の誰も、何か違うことに気づいていません-あなたの妻は、「おやおや*、彼は家にいる」のようなものです。

なりすましはあなたのお金のすべてに自分自身を助け、おそらく途中でいくつかのXboxをプレイし、誰も賢い人はいないでしょう。

CSRFは基本的に、あなたが家のドアを開けてから開いたままにしておくという事実に依存しており、他の誰かがあなたのふりをするだけです。

この問題を解決する方法は何ですか？

あなたが最初にあなたの家のドアを開けると、あなたはあなたのドアマンによってそれに書かれた長くて非常にランダムな番号が書かれた紙を与えられます：

「ASDFLJWERLI2343234」

さて、あなたが自分の家に入りたいのなら、あなたは入るためにドアの人にその一枚の紙を提示しなければなりません。

だから今、なりすましがあなたの家に入ろうとすると、ドアの男は尋ねます：

「紙に書かれている乱数は何ですか？」

なりすまし者が正しい番号を持っていない場合、彼は入りません。それか、乱数を正しく推測する必要があります。これは非常に難しい作業です。さらに悪いことに、乱数は20分間しか有効ではありません（例）。したがって、なりすまし者は正しく推測する必要があり、それだけでなく、正しい答えを得るのに20分しかありません。それはあまりにも多くの努力です！それで彼はあきらめます。

確かに、アナロジーは少し緊張していますが、お役に立てば幸いです。

** crud =（作成、読み取り、更新された削除）

于 2018-01-31T06:35:52.457 に答える
13

あなたは自分自身のためにこのトピックを研究し続ける必要があります、しかし私はあなたがSOに投稿している理由だと思います:)。 CSRFは非常に深刻で広範囲にわたる脆弱性の種類であり、すべてのWebアプリ開発者が知っておく必要があります。

まず第一に、同一生成元ポリシーが複数あります。ただし、最も重要な部分は、http： //whatever.comからホストされているスクリプトはhttp://victom.comからデータを読み取ることはできませんが、POSTおよびGETを介してデータを送信することはできます。リクエストに攻撃者が知っている情報のみが含まれている場合、攻撃者はvictomのブラウザでリクエストを偽造し、どこにでも送信できます。ランダムトークンを含まないリクエストを構築している3つのXSRFエクスプロイトを次に示します。

サイトにランダムトークンが含まれている場合は、XSSを使用して、同一生成元ポリシーが提供する保護をバイパスする必要があります。XSSを使用すると、JavaScriptを強制的に別のドメインから「発信」し、XmlHttpRequestを使用してトークンを読み取り、リクエストを偽造することができます。これが私が書いたエクスプロイトで、まさにそれを実行します。

于 2010-04-05T22:33:22.963 に答える
9

トークンをすべてのURLにクエリ文字列として追加する以外の方法はありますか？非常に醜くて実用的ではないようで、ユーザーにとってブックマークが難しくなります。

サイトのすべてのGETリクエストが読み取り専用であることを確認する限り、サイトのすべてのURLにトークンを追加する理由はありません。GETリクエストを使用してサーバー上のデータを変更する場合は、CSRFトークンを使用してデータを保護する必要があります。

CSRFの面白い部分は、攻撃者がサイトにhttpリクエストを送信することはできても、応答を読み戻すことができないことです。

ランダムトークンのないGETURLがある場合、攻撃者はリクエストを行うことはできますが、応答を読み戻すことはできません。そのURLがサーバー上の状態を変更した場合、攻撃者の仕事は完了です。しかし、HTMLを生成したばかりの場合、攻撃者は何も得られず、あなたは何も失いません。

于 2010-04-06T01:40:12.867 に答える