クリックジャッキングの脆弱性をどのように証明できますか？
サイトリンクをiframeに配置した場合（およびiframeで開いた場合）は、サイトがクリックジャッキング攻撃に対して脆弱であることをどのように示しますか？また、サイトがフォーラムベースである場合、脆弱性が重大である可能性があることも読みました。どうして？可能であれば、いくつかの例を提供してください。
Facebookをiframeに配置できると想像してください。 「無料自転車に勝つ！」というボタンのあるWebページを作成し、その上にFacebookページで透明なiframeを配置して、いいねボタンが「無料自転車に勝つ！」ボタン。誰かがそのボタンをクリックした場合、彼は自転車に勝つことはありませんが、代わりにそれに気付かずに私のFacebookページが好きになります。
はい、あなたはこれを疑問視する権利があります。
クリックジャッキングに対して脆弱なサイトと、実際に悪用可能な脆弱性は、2つの異なるものです。
Bhuvaneshtheir answer でクリックジャッキング攻撃の小さなサブセットについて説明します。このタイプのクリックジャッキングは OWASPの記事 で言及されています。
同様の手法を使用して、キーストロークをハイジャックすることもできます。スタイルシート、iframe、テキストボックスの巧妙に作成された組み合わせにより、ユーザーは自分の電子メールまたは銀行口座にパスワードを入力していると思わせることができますが、代わりに攻撃者が制御する非表示のフレームに入力しています。
このタイプのクリックジャッキングは、 -Dセキュア または Visaによって検証 を使用してIFrame内で秘密の銀行パスワードを要求するサイトに適用される場合があります。外部のWebサイトは、パスワードを取得するために、独自のテキストボックスを慎重に配置できます。ただし、これはクリックジャック攻撃や脆弱性が通常意味するものではありません。
同じ起源のポリシーが別の起源からあなた自身のサイトで生成されるIFrameを止めるであろうという点でBhuvaneshの答えは正しいです。ただし、別のサイトが独自のWebページで自分のサイトをフレーミングするのを防ぐことはできません。ほとんどのサイトがクリックジャッキングに対して脆弱なのはこの使用例です。これは本質的にクリックジャッキング攻撃です。攻撃者はドメインのページをIFrameに読み込みますが、CSSを使用してページを非表示にします。攻撃者は自分のボタンをページの下に配置します。これらのボタンが被害者によってクリックされると、ブラウザは実際にクリックをサイトに送信します。
例-あなたのサイトはexample.comです：
- 真ん中にボタンがある
confirmDeleteAccount.phpというページがあるとします。 - 攻撃者は自分のサイトにIFrameを作成します：
<iframe src="http://example.com/confirmDeleteAccount.php"></iframe> - CSSは、IFrameのサイズと配置、および非表示にするために使用されます。
- 攻撃者のコードは、IFrameに読み込まれたページの
I confirm I want to delete my Example.com accountボタンのすぐ下にある独自のページにボタンを配置します。 IFrameは表示されないため、攻撃者のボタンは、犠牲者には表示される唯一のボタンであるように見えます。 - 攻撃者のコードセットでは、ボタンに
Click here to claim your free holidayと表示されます。 - 被害者は攻撃者のボタンだと思うものをクリックしますが、ページにはボタンの上にサイトを含むIFrameがあるため、被害者は実際にボタンをクリックしてアカウントを削除しています。
X-Frame-Options を適切に設定すると、サイトがフレーム化されなくなります（これは現在、CSPの frame-ancestors に置き換えられていますが、現時点では両方とも推奨されていません）すべてのブラウザがframe-ancestorsをまだサポートしています）。
X-Frame-Options/frame-ancestorsを設定する必要がありますか？
上記の例は、悪用可能なクリックジャッキングの脆弱性を示しています。クリックジャッキングは、結果に影響を与えるシングルクリックボタンがある場合、サイトでの懸念のみです。したがって、クリックジャッキングの脆弱性を悪用するには、2つの要件があります。
- フレーム可能なページがあります（つまり、
X-Frame-Options/frame-ancestorsはありません）。 - マウス操作のみで操作できるページがあり、ユーザーに望ましくない結果をもたらすか、何らかの方法で攻撃者を有利にします。
したがって、ユーザー入力を必要とするページがあり、攻撃者がそのユーザー入力を提供できない場合、そのページは悪用されることはありません。ただし、ページのフォームがクエリ文字列値またはPOSTデータによって完成している場合、攻撃者は攻撃のためにデータを提供する方法を持っています。
サイトのすべてのページと、そこにどのデータが提供されているかを考慮せずに、サイトが悪用可能かどうかを判断するのは複雑です。したがって、多くのセキュリティ評価と侵入テストでは、これらのヘッダーが欠落している場合、サイトが脆弱であると報告される傾向があります。私のアドバイスは通常、サイトをその機能の一部としてフレーム化する必要がない限り、常にヘッダーを追加することです。 パス相対スタイルシートのインポート（PRSSI） 、 クロスサイト履歴操作（XSHM） または framesniffing）などの他の脆弱性を軽減するためにこれらのヘッダーを設定することも良い 。
単純なログインフォームと送信ボタンがあるとします。送信ボタンは、資格情報をサーバーに送信します。
攻撃者はこのログインページをiFrame内に読み込み、元のページと同様のスタイルのログインフォームを作成した後、ページの元のページの上に新しいものを配置します。データを取得した後、手動で送信し、アカウントのハッキングを試みます。
Stanford Web Security Researchは、これに対処するスマートな方法を考え出しました。
https://www.codemagi.com/blog/post/194
そして、あなたはここでより多くの例を見つけることができます：
実際クリックジャッキングは、iframeをWebサイトにロードするだけではなく、サイトがクリックジャッキングに対して脆弱であることを示すためのテストにすぎません。
最近のブラウザーは、Chrome、IE、FirefoxなどのブラウザーがSame-Origin-policyに従ってロードを許可しないため、このテストも許可しません。あなたのウェブサイトにiframe。
この脆弱性については、ローカルホストから試すことができます。ただし、Webサイトにiframeをロードして何かを悪用する必要があります。たとえば、ユーザーに知らせずに[オファー]をクリックするようにユーザーに要求して、ユーザーのパスワードを変更する必要があります。クリックジャッキングの仕組みについては、このリンクを参照してください クリックジャッキング
この脆弱性のOWASPトップ10プロジェクトを参照することもできます。 OWASPクリックジャッキング