クリックジャッキング

クリックジャッキング（ユーザーインターフェイスリドレス攻撃またはUIリドレスとして分類される）は、ユーザーを騙して、ユーザーが認識しているものとは異なるものをクリックさせ、機密情報を漏洩させたり、 Webページなどの一見無害なオブジェクトをクリックしている間に他人がユーザーのコンピューターを制御できるようにしたりする悪意のある手法です。^{[1] [2] [3] [4] [5]}

クリックジャッキングは混乱した代理人問題の一例であり、コンピュータが騙されて権限を悪用してしまう。^[6]

2002年には、 Webページ上に透明なレイヤーを読み込み、ユーザーに気付かれずにユーザーの入力が透明なレイヤーに影響を与える可能性があることが指摘されていました。^[7]しかし、修正は2004年頃から少しずつ行われ始め、^[8] 2008年までこの問題は大きな問題としてほとんど無視されていました。^[7]

2008年、ジェレミア・グロスマンとロバート・ハンセン（SecTheory）は、Adobe Flash Playerがクリックジャックされ、攻撃者がユーザーの知らないうちにユーザーのコンピュータにアクセスできる可能性があることを発見しました。^{[ 7]グロスマンとハンセンは、「クリック」と「ハイジャック」を組み合わせ}た造語として「クリックジャッキング」という用語を作り出しました。^{[9] [10]}

同様の性質の攻撃がさらに発見されるにつれて、「UI再ドレスアップ」という用語の焦点は、クリックジャッキングそのものだけでなく、これらの攻撃のカテゴリを説明するために変更されました。^[7]

クリックジャッキングの 1 つの形態は、アプリケーションまたは Web ページに存在する脆弱性を悪用し、攻撃者がユーザーのコンピューターを操作して自分の利益を図ることを可能にします。

たとえば、クリックジャックされたページでは、ユーザーは隠されたリンクをクリックすることで、望ましくないアクションを実行するように誘導されます。クリックジャックされたページでは、攻撃者は元のページの上に別のページを透明なレイヤーで読み込み、ユーザーを騙してアクションを実行させますが、その結果はユーザーの予想とは異なるものになります。何も知らないユーザーは、表示されているボタンをクリックしていると思いますが、実際にはレイヤーの下のページのボタンをクリックして、見えないページでアクションを実行しています。隠されたページは認証ページである可能性があるため、攻撃者はユーザーを騙して、ユーザーが意図していないアクションを実行させることができます。ユーザーは隠されたページで実際に認証されているため、後でそのようなアクションを攻撃者にたどる方法はありません。

• クラシック：主にWebブラウザ経由で動作する^[7]
• ライクジャッキング： Facebookのソーシャルメディア機能を利用する^{[11] [12]}
• ネスト： Google+に影響を与えるようにカスタマイズされたクリックジャッキング^[13]
• カーソルジャッキング：カーソルの外観と位置を操作する^[7]
• マウスジャッキング：リモートRFリンクを介してキーボードやマウスの入力を挿入する^[14]
• ブラウザレス：ブラウザを使用しない^[7]
• クッキージャッキング：ブラウザからクッキーを取得する^[7][15]
• ファイルジャッキング：影響を受けたデバイスをファイルサーバーとして設定する機能^{[7] [16] [17]}
• パスワードマネージャー攻撃：ブラウザの自動入力機能の脆弱性を利用したクリックジャッキング^[7]

典型的なクリックジャッキングとは、攻撃者がウェブページ上の隠しレイヤーを利用してユーザーのカーソルの動作を操作し、実際に何がクリックされているのかについてユーザーを誤解させる状況を指します。^[18]

ユーザーはニュース項目に関するビデオへのリンクが記載されたメールを受け取ることがありますが、別のウェブページ、たとえばAmazonの製品ページがニュース ビデオの [再生] ボタンの上または下に「隠されている」場合があります。ユーザーはビデオを「再生」しようとしますが、実際には Amazon から製品を「購入」します。ハッカーは 1 回のクリックしか送信できないため、訪問者がAmazonにログインしていて、1 クリック注文が有効になっているという事実に頼っています。

これらの攻撃の技術的な実装は、ブラウザ間の非互換性のために難しいかもしれませんが、BeEFやMetasploit Projectなどの多くのツールは、脆弱なウェブサイト上のクライアントをほぼ完全に自動的に攻撃する機能を提供しています。クリックジャッキングは、 XSSなどの他のウェブ攻撃によって促進されるか、促進される可能性があります。^{[19] [20]}

ライクジャッキングとは、ウェブサイトを閲覧しているユーザーを騙して、意図せず「いいね！」したFacebookページやその他のソーシャルメディアの投稿/アカウントに「いいね！」させる悪質な手法である。[ 21 ]「ライクジャッキ^ング」という用語は、Corey Ballouが記事「Web上のあらゆるものに「いいね！」する方法（安全に）」に投稿したコメントに由来しており、^[22]これはFacebookの「いいね！」ボタンに関する悪質な活動の可能性を説明した最初の文書化された投稿の1つである。^[23]

IEEE Spectrumの記事によると、Facebookのハッカソンの1つで、いいねジャッキングの解決策が開発されたとのことです。^[24] Facebookのいいねボタンに存在するいいねジャッキングの可能性を回避する「いいね」ブックマークレットが利用可能です。^[25]

ネストされたクリックジャッキングは、従来のクリックジャッキングとは異なり、元の無害なウェブページの 2 つのフレーム(フレーム化されたページと上部のウィンドウに表示されるフレーム) の間に悪意のあるウェブフレームを埋め込むことで機能します。これは、HTTP ヘッダーの脆弱性によって機能しますX-Frame-Options。この脆弱性では、この要素の値が の場合SAMEORIGIN、ウェブブラウザは前述の 2 つのレイヤーのみをチェックします。これら 2 つの間に検出されずに追加のフレームを追加できるという事実は、攻撃者がこれを自分の利益のために利用できること を意味します。

過去には、Google+や の欠陥バージョンでX-Frame-Options、攻撃者はGoogle の画像検索エンジンに存在する脆弱性を利用して、任意のフレームを挿入することができました。Google+ にも存在する画像表示フレームの間に、攻撃者が制御するこれらのフレームを読み込むことができ、制限されることもなかったため、攻撃者は画像表示ページにアクセスした人を誤解させることができました。^[13]

カーソルジャッキングは、ユーザーが認識している位置からカーソルを変更するUI再調整技術であり、2010年にvulnerability.frの研究者Eddy Bordiによって発見されました。^[26] Marcus Niemietzはカスタムカーソルアイコンでこれを実証し、2012年にはMario Heiderichがカーソルを非表示にしてこれを実証しました。^[27]

Alternativ-Testing.frの研究者であるJordi Chancel氏は、Mac OS Xシステム上のMozilla FirefoxでFlash、HTML、JavaScriptコードを使用したカーソルジャッキングの脆弱性を発見しました（Firefox 30.0で修正済み）。この脆弱性により、任意のコードの実行やウェブカメラの盗聴が発生する可能性があります。^[28]

2つ目のカーソルジャッキング脆弱性は、Mac OS Xシステム上のMozilla Firefox（Firefox 37.0で修正済み）でJordi Chancelによって再び発見されました。この脆弱性は、再びFlash、HTML、JavaScriptコードを使用しており、これによりウェブカメラを介したスパイ行為や悪意のあるアドオンの実行につながり、影響を受けるユーザーのコンピュータ上でマルウェアの実行が可能になります。^[29]

UIを修正する他のクリックジャッキング技術とは異なり、マウスジャックは、2016年にBastille.netのMarc Newlinによって初めて報告されたワイヤレスハードウェアベースのUI脆弱性であり、外部キーボード入力を脆弱なドングルに挿入することができます。^[30] Logitechはファームウェアパッチを提供しましたが、他のメーカーはこの脆弱性に対応できませんでした。^[31]

ブラウザレス クリックジャッキングでは、攻撃者はプログラムの脆弱性を利用して、Web ブラウザを必要とせずに、プログラム内で従来のクリックジャッキングを再現します。

このクリックジャッキングの手法は、主にモバイルデバイス、特にAndroidデバイスで広く利用されています。これは、トースト通知の仕組みが原因です。トースト通知は、通知が要求された瞬間から実際に画面に表示される瞬間までの間にわずかな遅延があるため、攻撃者はそのギャップを利用して、通知の下に隠れてクリック可能なダミーボタンを作成することができます。^[7]

クッキージャッキングはクリックジャッキングの一種で、被害者のウェブブラウザからクッキーを盗むものです。これは、一見無害に見えるオブジェクトをドラッグするようにユーザーを騙して、実際には標的のクッキーのコンテンツ全体を選択させることで行われます。そこから、攻撃者はクッキーとそれが保持するすべてのデータを取得できます。^{[15] [説明が必要]}

ファイルジャッキングでは、攻撃者はウェブブラウザの機能を利用してコンピュータ内を移動し、コンピュータファイルにアクセスして個人データを取得します。これは、ユーザーを騙してアクティブなファイルサーバーを確立させることによって行われます（ブラウザが使用するファイルとフォルダの選択ウィンドウを介して）。これにより、攻撃者は被害者のコンピュータにアクセスしてファイルを取得できるようになります。^[16]

カーネギーメロン大学の研究者による2014年の論文によると、ブラウザは現在のログインページのプロトコルがパスワードを保存したときのプロトコルと異なる場合、自動入力を拒否しますが、一部のパスワードマネージャーはhttpsで保存されたパスワードのhttpバージョンのパスワードを安全でない方法で入力することがわかりました。ほとんどのマネージャーはiFrameやリダイレクトベースの攻撃から保護しておらず、複数のデバイス間でパスワード同期が使用されていた場合に追加のパスワードが公開されていました。 ^[17]

クリックジャッキング（ライクジャッキングを含む）に対する保護は、Mozilla Firefoxのデスクトップ版とモバイル版^[32]にNoScriptアドオンをインストールすることで追加できます。2008年10月8日にリリースされたClearClick機能は、埋め込まれたドキュメントやアプレットの見えない、または「再ドレスアップされた」ページ要素をユーザーがクリックするのを防ぎます。^[33] Googleの2008年の「ブラウザセキュリティハンドブック」によると、NoScriptのClearClickはクリックジャッキングに対して「適度な保護を提供する無料で利用できる製品」です。^[34]新しいカーソルジャッキング攻撃に対する保護はNoScript 2.2.8 RC1に追加されました。^[27]

「NoClickjack」ウェブブラウザアドオン（ブラウザ拡張機能）は、正当な iFrame の動作を妨げることなく、 Google Chrome、Mozilla Firefox、Opera、Microsoft Edgeのユーザーにクライアント側のクリックジャック保護を追加します。NoClickjack は、GuardedID 用に開発されたテクノロジーに基づいています。NoClickjack アドオンは無料です。

GuardedID（商用製品）には、正当なiFrameの動作を妨げることなくInternet Explorerのユーザー向けにクライアント側のクリックジャック保護が含まれています。^[35] GuardedIDのクリックジャック保護は、すべてのフレームを強制的に表示します。GuardedIDは、Google Chrome、Mozilla Firefox、Opera、Microsoft Edgeの保護機能を追加するために、アドオンNoClickjackと連携しています^{[説明が必要]}。

GazelleはIEをベースにしたMicrosoft Researchプロジェクトの安全なウェブブラウザで、 OSのようなセキュリティモデルを使用し、クリックジャッキングに対する独自の限定的な防御機能を備えています。^[36] Gazelleでは、異なるオリジンのウィンドウは、描画するコンテンツが不透明である場合にのみ、別のウィンドウの画面スペースに動的コンテンツを描画できます。

Intersection Observer v2 API ^[37]は、人間が定義するターゲット要素の実際の「可視性」を追跡するという概念を導入しています。^[38]これにより、フレームウィジェットはカバーされているかどうかを検出できます。この機能は、2019年4月にリリースされたGoogle Chrome 74以降、デフォルトで有効になっています。 ^[39]このAPIは、Microsoft EdgeやOperaなどの他のChromiumベースのブラウザでも実装されています。

ウェブサイトの所有者は、異なるソースからのフレーム内に含めたくないページにフレームキラーJavaScriptスニペットを含めることで、サーバー側でのUIの再ドレスアップ（フレームベースのクリックジャッキング）からユーザーを保護することができます。^[34]

このようなJavaScriptベースの保護は必ずしも信頼できるものではありません。これは特にInternet Explorerに当てはまります。^[34] Internet Explorerでは、この種の対策は、要素内にターゲットページを含めることで「設計上」回避される可能性があります。^[40]<IFRAME SECURITY=restricted>

2009年にInternet Explorer 8で導入された新しいHTTPヘッダーはX-Frame-Options、クリックジャッキングに対する部分的な保護を提供し^{[41] [42]} 、その後すぐに他のブラウザ（Safari、^[43] Firefox、^[44] Chrome、^[45] Opera ^[46]）にも採用されました。このヘッダーは、ウェブサイトの所有者によって設定され、優先するフレーミングポリシーを宣言します。、、またはの値はそれぞれDENY、すべてのフレーミングを防止、外部サイトによるフレーミング、または指定されたサイトによるフレーミングのみを許可します。さらに、一部の広告サイトは、どのページでもコンテンツのフレーミングを許可する目的で非標準の値を返します（X-Frame-Optionsをまったく設定しないのと同等）。 ALLOW-FROM originSAMEORIGINALLOWALL

2013年にX-Frame-OptionsヘッダーはRFC 7034として公式に公開されましたが^[47] 、インターネット標準ではありません。この文書は情報提供のみを目的としています。W3Cのコンテンツセキュリティポリシーレベル2勧告では、X-Frame-Optionsヘッダーを廃止することを目的とした代替セキュリティディレクティブframe-ancestorsが提供されています。^[48]

X-Frame-Optionsのようなセキュリティヘッダーは、フレームを使用しないクリックジャッキング攻撃からユーザーを保護することはできません。^[49]

コンテンツセキュリティポリシーframe-ancestorsのディレクティブ（バージョン1.1で導入）は、iframe、オブジェクトなどを使用して潜在的に悪意のあるページによるコンテンツの埋め込みを許可または禁止することができます。このディレクティブは、X-Frame-Optionsディレクティブを廃止します。ページが両方のヘッダーで提供される場合、ブラウザはframe-ancestorsポリシーを優先する必要があります。^[50] —ただし、一部の一般的なブラウザはこの要件に従わない場合があります。^[51]

フレーム祖先ポリシーの例:

# 埋め込みを許可しません。すべての iframe などは空白になるか、ブラウザ固有のエラー ページが含まれます。
コンテンツ セキュリティ ポリシー: フレーム祖先 'none'

#独自のコンテンツの埋め込みのみを許可します。
コンテンツ セキュリティ ポリシー: フレーム祖先 'self'

# 特定のオリジンがこのコンテンツを埋め込むことを許可する
コンテンツセキュリティポリシー: フレームアンセスター www.example.com www.wikipedia.org