web-dev-qa-db-ja.com

フォームジャッキングとは何ですか?

シマンテックについて非常に混乱したニュースブロードキャストを聞いたところ、フォームジャッキングの危険性について世界に警告しました。ニュースリーダーは、それが何を意味するにせよ、「ウェブサイトではなくフォームをハッキングする」ことを含んでいると語った。

私は探し回って、それに関するシマンテックのブログ投稿を見つけました、そこで彼らは攻撃を次のように説明しています:

  1. 攻撃者は悪意のあるJavaScriptを標的のWebページに「挿入」します
  2. ユーザーはそのウェブページのフォームに記入します
  3. JavaScriptは、入力されたデータを攻撃者のサーバーに送信します。

しかし、攻撃者がサーバーのフォームジャックへの書き込みアクセス権を持っている場合は、懸念はほとんどありません(実際の脆弱性ではなく、アクセス権を与えたものは何でもかまいません)。

なぜ多くのWebサイト(私が住んでいる国のニュースにありました)をフォームジャックするのか、そして多くのWebサイト(Symantecによればブリティッシュエアウェイズにある)に、攻撃者がサーバーにアクセスできるほど途方もなく大きな脆弱性があるのではないのですか?

39
11684

あなたが言及しているシマンテックの記事は これ のようなものです。

グラフィック を見る:

graphic

ポイント1は、セキュリティの研究者にとって一般的に最も興味深いものです。なぜなら、脆弱性がそこにあるからです。

ポイント2と3は、このような脆弱性で何が可能になるかを示しています。たとえば、JavaScriptはフィッシング攻撃(偽のフォームを表示)で使用したり、ユーザーがフォームに入力したデータを読み取るために使用したりできます。これはシマンテックがフォームジャックと呼んでいるものですが、もちろん新しいものではありません。

彼らの記事には「ウェブサイトがどのように危険にさらされているのか」というセクションもあり、おそらく興味を引くでしょう。

脆弱性には、サーバー側のコードを変更するオプションが含まれていますが、メインアプリケーションは必ずしもそうではありませんが、特にJavaScriptの依存関係にあります。

もちろん、サードパーティのJavaScriptの組み込みに関する問題も新しいものではありません。げっぷは、たとえばそれを呼び出す クロスドメインスクリプトインクルード 、そして [〜#〜] owasp [〜#〜] も同様に警告します。サードパーティのスクリプトを含めるには、サードパーティへの完全な信頼とセキュリティプロセスへの信頼が常に必要です。

なぜ大事なことをフォームジャックするのか

シマンテックのマーケティングは良いですか?

47
tim

サーバーへの直接アクセスは必要ありません必要ありません

悪意のあるJavaScriptが、攻撃者がサーバーにアクセスしなくてもWebページに表示される可能性がある方法はいくつかあります。

  • ウェブサイトの作成者が信頼できないソースからのライブラリにリンクしている可能性があります
    • 例えばWeb開発者Aはmy-site.comの画像カルーセルを気に入って直接リンクしています。my-site.comの所有者はいつでもスクリプトを変更でき、悪意のあるコードを追加する可能性があります。
  • Webサイトの作成者が、信頼できないソースからJavaScriptをコピーした可能性があります
    • 例えばWeb開発者Bは、摂氏を華氏に変換するライブラリを探しています。彼らは仕事をするfree.javascriptlib.zzでスクリプトを見つけますが、スクリプト自体が難読化されているため、悪意のあるコードが含まれていることに気付かないでください。
  • エンドユーザーは、信頼できないブラウザ拡張機能やブックマークレットを使用して、自分自身を妨害する可能性があります。
    • 例えばアリスは、絵文字キーボードを提供するボタンをブラウザに追加しましたが、現在のページに悪意のあるコードを挿入します。
  • エンドユーザーはDNSスプーフィングの被害者である可能性があります。
    • 例えばBobの https://code.jquery.com/jquery-3.3.1.min.js のDNSルックアップが侵害されたため、悪意のある安全でないソースからjqueryのバージョンを配信コードを追加しました。
  • ...など.

これらのタイプの攻撃に関するもう1つの懸念は、検出が難しい場合があることです。 JavaScriptはクライアント側で実行されるため、これらのいずれもサイトのセキュリティが侵害されていることを示すフラグを立てることはありません。影響を受けるユーザーが詳細が盗まれたという警告を受け取ることはほとんどありません。


特にブリティッシュエアウェイズの脆弱性に関して、BBCは原因を推測する記事をここに書きました: https://www.bbc.co.uk/news/technology-45446529

その中で、彼らはそれがサードパーティのスクリプトである可能性が高いことを示唆し、「オンサイトのカスタマーサービスチャットボットが潜在的な原因としてラベル付けされた」Ticketmasterに関する別の例を引用します。

42
DaveMongoose

同意します。フォームジャッキングは脆弱性ではなく、一種の攻撃です、攻撃者がすでに被害者のウェブルートまたは別のサイトのウェブルートへの書き込みアクセス権を持っている場合に実行できます。被害者を完全に信頼している。

したがって、被害者のウェブルートが安全であれば、フォームジャッキングも問題になる可能性がありますが、サードパーティのコードを動的に組み込んだり、広告を配信しようとしたりするだけでなく、不正な信頼関係船につながることもよくあります。

攻撃の犠牲者は会社の顧客であるため、フォームジャッキングは興味深いものであり、攻撃者は標的にしており、Magecartのようなグループはすでにかなりのお金を稼いでいます。

シマンテックは実際に「フォームジャッキング」の問題全体を単純化しすぎたようです。初めて読んだとき、あなたと同じ結論に導きました。

しかし、ここで問題になるのは、攻撃者がターゲットのサーバーにアクセスする必要なく、これらの悪質なペイロードが注入されることです。 サプライチェーン攻撃 として言及されているのはそのためです。

チケットマスター、ブリティッシュエアウェイズ、OXO、コペイ、ゲート.ioへの攻撃はすべて、この同じアプローチを通じて達成されました。サードパーティを侵害して、悪意のあるコードをターゲットに送り込みました。

以前このスレッドで述べたように、これらの攻撃ではサードパーティのスクリプトを使用することが最も一般的ですが、それだけではありません。 Copayへの攻撃 は、Copay暗号ウォレットの依存関係であるイベントストリームに悪意のあるコードを挿入することで実現されました。

平均的なWebアプリには1000以上の依存関係があることを考えると、これがレーダーの下で飛んで、会社が悪意のあるコードを含む自社製品のバージョンをリリースしたことは不思議ではありません。この攻撃は「フォームジャッキング」M.O.には適合しませんが、標的の企業に直接侵入するのではなく、侵害されたサードパーティを介して悪意のあるコードを挿入するのと同じ原理を特徴としていました。

1
Carl Rck