5

知っている人からの意見を求めたいだけです。私は CSRF の脆弱性を検討していましたが、これは私が知っている最も一般的な方法であると思われます。その方法は、返された html でトークンを作成し、同じ値の Cookie を追加することです。したがって、スクリプトが投稿を行おうとすると、have to guess the token thats embedded in the web page成功するはずです。

しかし、彼らが特定の Web サイトをターゲットにしている場合、なぜ彼らはスクリプトを使用できないのでしょうか。

  1. ページで get を呼び出します (スクリプトがアクセスできなくても Cookie は返されます)
  2. HTML を解析してトークンを取得する
  3. そのトークンを含む投稿を呼び出します (戻ってきた Cookie が送り返されます)
  4. ユーザーに気づかれずにフォームを送信した

スクリプトは Cookie の内容を知る必要はありません。Cookie が常に送受信されるという事実を利用しているだけです。

ここで何が欠けていますか？これは不可能ですか？これはよく考えるとかなり怖いと思います。

この行の下は、質問に答えるために読む必要はありません:)

この脆弱性は、認証が現在行われている主な方法である Cookie に基づいて行われるという事実に依存しています。

私が考えることができる別の解決策は、認証をページレベルにすることです。したがって、ログインすると、返された html にそのトークンが含まれます。クリックするすべてのリンクにはそのトークンが含まれているため、Web サーバーが要求を受け取ると、ユーザー/セッションを識別する方法があります。それに関する問題は、それ以外のナビゲーションを使用すると、「認証されていない」(たとえば、URL を入力する) ことになり、おそらく次のようになるため、URL で見栄えがよくないことです。

https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3

しかし、安全性がより重要である場合、きれいな URL が 2 位であることは理解しています。

私は Cookie についてすべてを知っているわけではありませんが、ユーザー エージェントが Cookie にもう少し注意を払っていたらどうでしょうか?

たとえば、送信される Cookie がタブによって異なる場合はどうなるでしょうか。私たちは今ではタブを使ってサーフィンしていますよね？では、Cookie のスコープがタブである場合はどうなるでしょうか。したがって、タブ 1 でバンキング サイトを開き、タブ 2 でサーフィンしている場合、タブ 2 で取得/投稿を呼び出すスクリプトは、タブ 2 で発生した Cookie のみを送信します。

または、Cookie が保存されている場合はどうなりますか / ドメイン。そのため、私が example.com にアクセスしている間、返された Cookie はすべて example.com の Cookie コレクションに入ります。そして、私が www.mybankingsite.com にアクセスすると、すべての Cookie が mybankingsite.com コレクションに入れられます。したがって、example.com にアクセスして get/post を呼び出すスクリプトを実行すると、ユーザー エージェントは example.com Cookie のみを送信します。これは、要求されたドメインの Cookie を送信することとは異なります。たとえば、スクリプトが example.com の Web ページ内で mybankingsite.com の get を呼び出した場合、ユーザー エージェントは mybankingsite.com Cookie を送信しません。

ユーザー エージェントの動作を制御できないことはわかっていますが、可能性を探っているだけです

4

3 に答える 3

4

したがって、ここでの問題は、攻撃者がページのコンテンツを取得しようとする試みになると思います。認証されたユーザーのページを取得するには、攻撃者は自分に代わってリクエストを送信し、コンテンツを読み取ることができる必要があります。AJAX はクロスドメイン リクエストを送信しません。iframe ではレスポンスを読み取ることができません。攻撃者が最初にコンテンツを取得する他の方法を考えるのに苦労しています.

より可能性の高いハッキングは、クリックジャッキングを使用してユーザーにフォームを送信させることです。このテクニックはあまりありそうにありません。(注意: これはセキュリティです。常に間違っている可能性があります。)

于 2010-06-24T15:35:26.977 に答える
2

自分のサイト（本番環境ではない）をCSRFでハッキングしたので、この問題に関するコードを共有したい人はいますか。私がしなければならなかったのは次のことだけでした

で: www.badguy.com/ 次の html を書きます

img src="www.goodguy.com/secure/user/delete/5">

管理者が www.badguy.com/ にアクセスすると、画像がユーザーのブラウザから www.goodguy.com/secure/user/delete/5 にリクエストを送信するため、管理者は知らないうちにユーザーを削除してしまいます。ループを作成すると、問題が発生します。ステータスを変更するだけでデータを削除することは決してないことを期待してください:)しかし、それでもこの見た目は好きではありません。

于 2010-06-30T23:12:04.707 に答える
1

CSRF トークンは、セッションごとに一意である必要があります。悪意のあるサーバーが同じページを要求すると、別のトークンが取得されます。クライアントのマシンで JavaScript を介してページのコンテンツを要求しようとすると、同一生成元ポリシーによって阻止されます。

于 2010-06-24T13:39:56.640 に答える