クリックジャッキングは実際のセキュリティの脆弱性ですか？
私が理解しているように、これは攻撃者がクリックジャッキングを悪用する方法です。
- フレームに私のサイトが含まれているが、悪意のある入力フィールドまたはボタンが私のサイトのHTML要素の上にオーバーレイされている、新しいWebサイトの悪意のあるサイト.comを作成します。
- フィッシングメールを送信して、ユーザーが自分のサイトではなく、malicioussite.comへのリンクをクリックするようにします（または他の手法を使用してフィッシングリンクを配布します）。
- ユーザーはデータを入力するか、悪意のある要素をクリックします。
- 利益
精通したユーザーはリンクをクリックしないか、アドレスバーが正しくないことに気づくでしょう。しかし、多くの人はおそらく気付かないでしょう。
私の質問はこれです。攻撃者は、悪意のあるサイト.comをリバースプロキシとして使用して同じことを行うことはできませんか？上記のすべての手順は同じですが、malicioussite.comがリクエストを自分のサイトに転送し、追加の<script>タグをHTML応答に挿入して、悪意のあるコードを実行し、悪意のあるHTML要素を追加します。その場合、X-FRAME-OPTIONSヘッダーは役に立ちません。これは、フレームがないためです（リバースプロキシはとにかくそれを取り除くことができます）。
攻撃はユーザーがアドレスバーをチェックしないことに依存しているため、攻撃者が同じ攻撃を打ち負かすことができない別の方法で実装できる場合、X-FRAME-OPTIONSまたは他のクリックジャッキング保護に迷惑をかけるのはなぜですか？
これは非常に興味深い質問です。
まず、シナリオから始めましょう。Webサイトwww.evil.comにアクセスするユーザーは、www.good.comを読み込んでコンテンツを変更するリバースプロキシです。 おめでとうございます！古典的な MiTM攻撃 を再発明したばかりですが、非常に貧弱です。 evil.comにアクセスすると、ブラウザがgood.com Cookieを送信しないことを意味します。つまり、リバースプロキシがユーザーに代わって動作することはできません。これを修正するには、good.comを使用してユーザーをリバースプロキシにログインさせる必要があります。 おめでとうございます！偽のランディングページで攻撃を再考しました。
あなたが説明しているシナリオはクリックジャッキングとは何の関係もありませんが、実際には非常に異なる理由でクリックジャッキング保護を採用しています。クリックジャッキングでは、攻撃者はauthenticatedユーザーが何らかのアクションを実行するようにします。ユーザーがevil.comにアクセスしている場合でも、リバースプロキシを使用した提案シナリオとは異なり、ユーザーのリクエストはセッションIDを含むCookieとともにgood.comに送信されます。したがって、アクションは認証されたユーザーのセッション内で実行されます。
聞き覚えがありますか？はい、そうです CSRF攻撃 が機能する方法ですが、唯一の違いは、CSRFを使用すると、アクションがプログラムで実行されるという点です。クリックジャッキングでは、アクションはユーザーのブラウザー内、ユーザー自身、および正当なページ（iFrame内にロードされた）内で実行されます。
要するに、提案された攻撃は確かにもっともらしいですが、私たちはアンチクリックジャッキングを使用して、まったく異なる攻撃を打ち負かしています。そのため、はい、クリックジャッキングは実際に、明確なセキュリティ上の懸念事項です。