
クリックジャッキング(ユーザーインターフェースリドレス攻撃またはUIリドレス攻撃に分類される)は、ユーザーが認識しているものとは異なるものをクリックするようにユーザーをだます悪質な手法であり、ウェブページなどの一見無害なオブジェクトをクリックしている間に、機密情報が漏洩したり、他人がコンピュータを制御できるようになる可能性があります。[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
2002年には、ウェブページ上に透明なレイヤーを読み込み、ユーザーが気づかないうちにユーザーの入力が透明なレイヤーに影響を与えることが可能であることが指摘されていました。[ 7 ]しかし、修正は2004年頃から少しずつ始まっただけで、[ 8 ]一般的な問題は2008年まで主要な問題としてほとんど無視されていました。[ 7 ]
2008年、ジェレマイア・グロスマンとロバート・ハンセン(SecTheory所属)は、Adobe Flash Playerがクリックジャッキングの被害に遭う可能性があることを発見し、攻撃者がユーザーの知らないうちにユーザーのコンピュータにアクセスできることを明らかにした。[ 7 ]グロスマンとハンセンは、「クリック」と「ハイジャック」を組み合わせた造語である「クリックジャッキング」という用語を作り出した。[ 9 ] [ 10 ] [ 7 ]
同様の性質を持つ攻撃がさらに発見されるにつれて、「UI リドレッシング」という用語の焦点は、クリックジャッキング自体ではなく、これらの攻撃のカテゴリを説明するように変更されました。[ 7 ]
クリックジャッキングの一種は、アプリケーションやウェブページに存在する脆弱性を悪用し、攻撃者がユーザーのコンピュータを自分の利益のために操作できるようにするものです。
例えば、クリックジャックされたページでは、隠されたリンクをクリックさせることで、ユーザーが意図しない操作を行うように仕向けます。クリックジャックされたページでは、攻撃者は元のページの上に透明なレイヤーで別のページを読み込み、ユーザーが期待する結果とは異なる操作を行うように仕向けます。ユーザーは、表示されているボタンをクリックしていると思い込んでいますが、実際には、レイヤーの下にある見えないページのボタンをクリックして操作を行っています。隠されたページは認証ページである可能性があり、そのため攻撃者はユーザーが意図していない操作を行うように仕向けることができます。ユーザーは隠されたページで正式に認証されているため、後から攻撃者にそのような操作を追跡する方法はありません。
古典的なクリックジャッキングとは、攻撃者がウェブページの隠しレイヤーを使用してユーザーのカーソルの動作を操作し、ユーザーが実際に何をクリックしているのかを誤解させる状況を指します。[ 18 ]
ユーザーはニュース記事に関する動画へのリンクが記載されたメールを受け取るかもしれませんが、そのニュース動画の「再生」ボタンの上または下に、Amazonの商品ページなどの別のウェブページが「隠されている」可能性があります。ユーザーは動画を「再生」しようとしますが、実際にはAmazonで商品を「購入」してしまいます。ハッカーは1回のクリックしか送信できないため、訪問者がAmazonにログインしていて、ワンクリック注文が有効になっていることを利用します。
これらの攻撃の技術的な実装は、ブラウザ間の非互換性のために困難である可能性があるが、BeEFやMetasploit Projectなどのツールは、脆弱なWebサイト上のクライアントをほぼ完全に自動化して悪用することを可能にする。クリックジャッキングは、 XSSなどの他のWeb攻撃によって促進される場合もあれば、他のWeb攻撃を促進する場合もある。[ 19 ] [ 20 ]
ライクジャッキングとは、ウェブサイトを閲覧しているユーザーを騙して、意図せず「いいね!」したかったFacebookページやその他のソーシャルメディアの投稿/アカウントに「いいね!」させる悪質な手法です。 [ 21 ] 「ライクジャッキング」という用語は、Corey Ballou氏が記事「ウェブ上のあらゆるものに(安全に)いいね!」する方法」に投稿したコメントに由来しており、[ 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 ]
CursorJackingは、ユーザーが認識している位置からカーソルを変更する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 コードを使用した CursorJacking の脆弱性を発見しました (Firefox 30.0 で修正済み)。この脆弱性により、任意のコード実行やウェブカメラの盗撮が可能になります。[ 28 ]
2つ目のカーソルジャッキングの脆弱性が、Jordi Chancel によってMac OS Xシステム上のMozilla Firefoxで再び発見されました (Firefox 37.0 で修正済み)。この脆弱性は、 Flash、HTML、JavaScriptコードを使用しており、Web カメラを介したスパイ行為や悪意のあるアドオンの実行につながり、影響を受けたユーザーのコンピュータ上でマルウェアを実行させる可能性があります。[ 29 ]
UI を修正する他のクリックジャッキング手法とは異なり、MouseJack は、Bastille.net の Marc Newlin が 2016 年に初めて報告したワイヤレス ハードウェアベースの UI 脆弱性であり、脆弱なドングルに外部キーボード入力を注入することを可能にします。[ 30 ] Logitech はファームウェア パッチを提供しましたが、他のメーカーはこの脆弱性に対応しませんでした。[ 31 ]
ブラウザレス・クリックジャッキングでは、攻撃者はプログラムの脆弱性を悪用し、ウェブブラウザの存在を必要とせずに、従来のクリックジャッキングを再現します。
このクリックジャッキングの手法は、主にモバイルデバイス、特にAndroidデバイスで広く行われており、トースト通知の仕組みがその理由です。トースト通知は、通知が要求されてから実際に画面に表示されるまでにわずかな遅延があるため、攻撃者はその隙間を利用して、通知の下に隠れたダミーボタンを作成し、クリックできるようにすることができます。[ 7 ]
CookieJackingは、被害者のWebブラウザからCookieを盗むクリックジャッキングの一種です。これは、一見無害に見えるオブジェクトをユーザーにドラッグさせることで行われますが、実際には、標的のCookieの内容全体をユーザーに選択させるように仕向けられています。そこから、攻撃者はCookieとその中に含まれるすべてのデータを取得できます。[ 15 ]
ファイルジャッキングでは、攻撃者はウェブブラウザの機能を利用してコンピュータ内を移動し、コンピュータファイルにアクセスして個人データを取得します。これは、ブラウザが使用するファイルとフォルダの選択ウィンドウを介して、ユーザーを騙してアクティブなファイルサーバーを確立させることによって行われます。これにより、攻撃者は被害者のコンピュータからファイルにアクセスして取得できるようになります。[ 16 ]
カーネギーメロン大学の研究者による2014年の論文では、ブラウザは現在のログインページのプロトコルがパスワードが保存された時のプロトコルと異なる場合、自動入力を拒否するが、一部のパスワードマネージャーはhttpsで保存されたパスワードのhttpバージョンに対して安全でない方法でパスワードを入力することが判明した。ほとんどのマネージャーはiFrameおよびリダイレクトベースの攻撃から保護されておらず、複数のデバイス間でパスワード同期が使用されていた場合に追加のパスワードが漏洩した。 [ 17 ]
クリックジャッキング (ライクジャッキングを含む) に対する保護は、NoScriptアドオンをインストールすることでMozilla Firefox のデスクトップ版とモバイル版[ 32 ]に追加できます。2008 年 10 月 8 日にリリースされた ClearClick 機能は、埋め込みドキュメントやアプレットの非表示または「修正された」ページ要素をユーザーがクリックすることを防止します。 [ 33 ] 2008 年の Google の「ブラウザー セキュリティ ハンドブック」によると、NoScript の ClearClick は、クリックジャッキングに対する「適切なレベルの保護を提供する無料で利用できる製品」です。[ 34 ]新しいカーソルジャッキング攻撃に対する保護は、NoScript 2.2.8 RC1 に追加されました。[ 27 ]
「NoClickjack」ウェブブラウザアドオン(ブラウザ拡張機能)は、 Google Chrome、Mozilla Firefox、Opera、Microsoft Edgeのユーザー向けに、クライアントサイドのクリックジャック対策機能を提供します。正規のiFrameの動作を妨げることはありません。NoClickjackはGuardedID向けに開発された技術に基づいています。NoClickjackアドオンは無料です。
GuardedID(商用製品)には、正当なiFrameの動作を妨げることなく、Internet Explorerユーザー向けのクライアントサイドのクリックジャック保護機能が含まれています。[ 35 ] GuardedIDのクリックジャック保護機能は、すべてのフレームを表示させます。GuardedIDは、アドオンのNoClickjackと連携して、Google Chrome、Mozilla Firefox、Opera、Microsoft Edgeの保護機能を追加します。
Gazelleは、IEをベースにしたMicrosoft ResearchプロジェクトのセキュアWebブラウザで、 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 ]この種の対策は、対象ページを要素内に含めることで「意図的に」回避できます。[ 40 ]<IFRAMESECURITY=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 ]
Content Security Policyframe-ancestorsのディレクティブ(バージョン 1.1 で導入)は、iframe、object などを使用して潜在的に悪意のあるページによるコンテンツの埋め込みを許可または禁止することができます。このディレクティブは X-Frame-Options ディレクティブを廃止します。ページが両方のヘッダーで配信された場合、ブラウザは frame-ancestors ポリシーを優先する必要があります[ 50 ]。ただし、この要件は一部のブラウザの古いバージョンでは無視されていました[ 51 ] 。
ポリシー例frame-ancestors:
# 埋め込みを禁止します。すべてのiframeなどは空白になるか、ブラウザ固有のエラーページが表示されます。 Content-Security-Policy: frame-ancestors 'none'
#独自のコンテンツの埋め込みのみを許可します。 Content-Security-Policy: frame-ancestors 'self'
# 特定のオリジンがこのコンテンツを埋め込むことを許可する Content-Security-Policy: frame-ancestors www.example.com www.wikipedia.org
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)