各セッションのフォームでトークンを使用するCSRF防止方法が一般的な方法です。ただし、file_get_contentsPHPがクロスドメインファイルフォームのコンテンツを取得できる場合、このトークンウェイがどのように保護できるかわかりません->フォームでトークンを取得して使用することもできます。
では、このトークンウェイはどのように機能しますか？
私があなたの質問をよく理解しているなら、あなたはこのような悪用の可能性を想像しています：
攻撃者のPHPスクリプトは、file_get_contents悪用しようとしているターゲットサイトからフォーム（HTML）をダウンロードし、ダウンロードしたHTMLからCSRFトークンを取り出し、ユーザーに提示された偽のフォーム内にこのCSRFトークンを追加します。
疑いを持たないユーザーがフォームを送信すると、このユーザーのセッションのコンテキストで、ターゲットサイトで意図しない要求が実行されます。
リクエストに有効なCSRFトークンがあるため、ターゲットサイトのCSRFチェックはOKに合格します
しかし、待ってください..有効なトークンがありますか？私たちは本当にしますか！ターゲットサイトがCSRFを実装している場合は、正しい方法を確認してください。
ここで重要なのはセッションです。file_get_contentsターゲットサイトからフォームをダウンロードするために実行すると、リクエストはそれ自体のセッションのコンテキストで実行され、file_get_contentsプロセスはそこでのクライアントであり、そのリクエストに対して生成されたCSRFトークンは、その特定のセッション。後で、ターゲットユーザーが偽のフォームを送信すると、そのリクエストはセッションとは異なるユーザーのセッションのコンテキストで実行されます。file_get_contentsしたがって、CSRFチェックがターゲットサイトによって実装されている場合、CSRKトークンは拒否されます。適切な方法。
これは、CSRFの防止に推奨されるシンクロナイザートークンパターンについて詳しく理解するためのOWASPからの良い記事です。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加