ユーザーアカウントのないサイトでのクリックジャッキング
クリックジャッキング攻撃についての私の理解は、攻撃者が私のサイトを自分のサイトに埋め込む可能性があるということです。次に、攻撃者は巧妙なスタイルを使用して、ユーザーをだまして私のサイトで実行するつもりのないアクションを実行させます。
私のサイトに、ログインせずに実行できるよりも多くのアクションを実行できるユーザーアカウントの概念がないとします。
それでは、クリックジャッキング攻撃はまだ私のサイトに適用できますか？
具体的には、ユーザーが自分のサイトで物を購入することを許可しているが、サイトの「アカウント」を持っていないために毎回個人情報とCC情報を入力するように要求する場合、自分のサイトを他のiFrameに埋め込むことを許可できますかサイト？
私のサイトにユーザーアカウントの概念がないとします...それでは、クリックジャッキング攻撃はまだ私のサイトに適用できますか？
アカウントがない場合でも、ユーザーセッションの概念がある場合は、クリックジャッキングが適用される可能性があります。それはすべて、セッションレベルで何が保存されているかに依存します。
これを考える最良の方法は、サイトがセッションレベルで状態を記憶していて、フレーミングを防ぐために X-Frame-Options を設定していない場合、攻撃者がユーザーをだましてこれを送信させる可能性があるということです。アクションを実行するための状態情報。
もう1つの要件は、サイトのどこかにあるクリック可能なアイテム（通常はボタン）で、クリック以外はページに入力する必要はありません。
クリックジャッキングは、送信にユーザー入力が不要なページでのCSRF保護を「回避する方法」のようなものです。
例：
- ユーザーがサイトのバスケットに「ウィジェット」を追加します。
- ユーザーはチェックアウトに行き、個人情報とカードの詳細を入力します。
- この情報は、ユーザーセッションのサーバー側に保存され、Cookieに保存されているランダムトークンを介して識別されます。
- ユーザーは確認ページにリダイレクトされるため、注文を送信する前に詳細を確認できます。
example.com/confirm.phpへのGETリクエストは注文を表示し、送信ボタンをクリックして空のフォームを送信する注文を完了することができます（ただし、 CSRFトークンの場合）結果としてPOSTcomplete.phpへのリクエスト。
これで、攻撃者はconfirm.phpページをフレームに収め、上部に別のボタンを表示して、ユーザーがボタンをクリックすると、サイトに注文を送信する可能性があります。これは、ユーザーのバスケットにアイテムを追加するために他の場所でCSRFの脆弱性と組み合わされ、セッションが設定されていることがわかっている時点で実行される可能性があります（攻撃者は、後に表示される広告主のサイトの1つを制御できるようになります）。ユーザーの最初のチェックアウトとこの脆弱性により、攻撃者が選択したアイテムを使用して再度チェックアウトすることができます）。
そうです、あなたのサイトは脆弱である可能性があり、それが本当の脅威をもたらすかどうかを確認するのは、特定の実装の詳細とサイトのビジネスモデルにかかっています。
はい、ユーザーアカウントを持っているかどうかに関係なく、サイトはクリックジャックされる可能性があります。
ユーザーがサイトにアカウントを持っている場合、そのアカウントに対してクリックジャッキング攻撃が行われる可能性があります。しかし、ターゲットの他の側面に対してクリックジャッキング攻撃を実行することもできます。
ウィキペディアには いくつかの例 ：ユーザーをだましてウェブカメラを有効にしたり、Twitterで誰かをフォローしたり、Facebookで何かを「いいね」させたりします。
ユーザーがアカウントを持っていないという事実は、クリックジャッキング攻撃からユーザーを保護するものではありません。クリックジャッカーがクレジットカード番号の後にある場合、ユーザーがすべての情報を入力する必要があるため、クリックジャッカーはその個人データも簡単に取得できます。
クリックジャッキングはあなたのサイトに対して行うことができます。認証されたユーザーがアプリケーションにログインしていて、攻撃者が悪意のあるリンクを送信した場合、ユーザーがそのリンクをクリックすると、ここをクリックボタンが付いたサイトが表示されます。ここをクリックボタンの下に、ユーザーを削除するためのサイトのIframeがあります。ユーザーが[ここをクリック]ボタンをクリックすると、アカウントが削除されます。 クリックジャッキングの詳細