CORSの説明
CORS（クロスオリジンリソースシェアリング）が引き起こす可能性のある問題について、いくつか説明が必要です。特に、サイトA.COMでCORSが有効になっているとします。
- Access-Control-Allow-Originは、HTTPリクエストで任意のウェブサイトに設定でき、レスポンスでコピーされます。
- Access-Control-Allow-Credentialsをtrueに設定できます
それを前提として、次のA.COMパスでA.COM/user.php?id=USER_IDがユーザーのパスワードをホストしていると仮定しましょう（非現実的ですが、先に進みましょう）。
考えられる攻撃シナリオは次のとおりです。
- 攻撃者は、B.COMでホストされるページを作成します。このページには、ページが読み込まれると、HTTPリクエスト（Originヘッダーが設定されている）を
A.COM/user.php?id=USER_IDに送信し、結果を取得してどこかに保存します（おそらく追加のhttp別の攻撃者ページへのリクエスト） - 攻撃者はユーザーにB.COMをロードさせる必要があります
したがって、私の質問は次のとおりです。A.COM/user.php?id=USER_IDにアクセスするには、ユーザーが認証され、Cookieが設定されている必要があります。攻撃者は、攻撃されたユーザーがA.COMに対して有効なCookieを持っていることを確認する必要があり、攻撃者はWebを知っている必要がありますA.COMの構造？攻撃されたユーザーがログインしておらず、Cookieが設定されていない場合、攻撃は機能しませんか？
ご説明ありがとうございます。
E。
攻撃されたユーザーがログインしておらず、Cookieが設定されていない場合、攻撃は機能しませんか？
そのとおり。
誤って設定されたCORSポリシーによる攻撃は、説明したとおりに機能します。ユーザーがログインしていない場合、攻撃者は何も得られません。
また、攻撃者はA.COMのWeb構造を知る必要がありますか？
はい、攻撃者は、ユーザーに送信を強制できるリクエストを知る必要があります。彼らも同様の権限を持つアカウントを持っている、アカウントまたはソースコードに一時的にアクセスできる、CORSリクエストへの返信がさらにリンクを返す、またはリクエストを推測しようとするため、これを知っている可能性があります。
はい、同じOriginポリシーが軽減するクロスサイトリクエストフォージェリ（ https://www.owasp.org/index.php/Cross-Site_Request_Forgery_（CSRF） ）は、ログインしているユーザーに最適です。 CORSは、特定の信頼できるWebサイトに対するこの緩和策を緩和します。