Loading article…
クリックジャッキング（ユーザーインターフェースリドレス攻撃または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 is a UI redressing technique to change the cursor from the location the user perceives, discovered in 2010 by Eddy Bordi, a researcher at vulnerability.fr.[26] Marcus Niemietz demonstrated this with a custom cursor icon, and in 2012 Mario Heiderich did so by hiding the cursor.[27]
Jordi Chancel, a researcher at Alternativ-Testing.fr, discovered a CursorJacking vulnerability using Flash, HTML and JavaScript code in Mozilla Firefox on Mac OS X systems (fixed in Firefox 30.0) which can lead to arbitrary code execution and webcam spying.[28]
A second CursorJacking vulnerability was again discovered by Jordi Chancel in Mozilla Firefox on Mac OS X systems (fixed in Firefox 37.0) using once again Flash, HTML and JavaScript code which can also lead to spying via a webcam and the execution of a malicious addon, allowing the execution of malware on the affected user's computer.[29]
Different from other clickjacking techniques that redress a UI, MouseJack is a wireless hardware-based UI vulnerability first reported by Marc Newlin of Bastille.net in 2016 which allows external keyboard input to be injected into vulnerable dongles.[30]Logitech supplied firmware patches but other manufacturers failed to respond to this vulnerability.[31]
In Browserless clickjacking, attackers utilize vulnerabilities in programs to replicate classic clickjacking in them, without being required to use the presence of a web browser.
This method of clickjacking is mainly prevalent among mobile devices, usually on Android devices, especially due to the way in which toast notifications work. Because toast notifications have a small delay in between the moment the notification is requested and the moment the notification actually displays on-screen, attackers are capable of using that gap to create a dummy button that lies hidden underneath the notification and can still be clicked on.[7]
CookieJacking is a form of clickjacking in which cookies are stolen from the victim's web browsers. This is done by tricking the user into dragging an object which seemingly appears harmless but is in fact making the user select the entire content of the cookie being targeted. From there, the attacker can acquire the cookie and all of the data that it possesses.[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メンテナンス: アーカイブサービスは非推奨になりました (リンク)