web-dev-qa-db-ja.com

XSSはどれほど危険ですか?

私はソフトウェアエンジニアで、XSSに関するビデオをたくさん見てきました。

しかし、クライアント側で実行され、データベースと多くの重要なファイルを含むサーバー側で実行されない場合、それがどのように危険かを理解できません。

38
Sai Kumar

以下は、XSSの脆弱性がある場合に攻撃者が実行できることです。

  • Ad-Jacking-WebサイトにXSSを保存できた場合は、広告をWebサイトに挿入してお金を稼ぐ;)
  • Click-Jacking-非表示のオーバーレイをページに作成して、被害者のクリックをハイジャックして悪意のあるアクションを実行できます。
  • Session Hijacking-HTTP ONLYフラグがCookieに存在しない場合、JavaScriptからHTTP Cookieにアクセスできます。

  • コンテンツのなりすまし-JavaScriptはWebアプリのクライアント側コードへの完全なアクセス権を持っているため、目的のコンテンツを表示/変更できます。

  • Credential Harvesting-最も楽しい部分。派手なポップアップを使用して、資格情報を取得できます。 WiFiファームウェアが更新されました。認証のために資格情報を再入力してください。

  • 強制ダウンロード-被害者は絶対にsafe.comから悪意のあるフラッシュプレーヤーをダウンロードしていませんか?心配する必要はありません。被害者がアクセスしている信頼できるウェブサイトから強制的にダウンロードしようとする運が高まります。

  • Crypto Mining-はい、被害者のCPUを使用してビットコインをマイニングできます!

  • CSRFのバイパス保護-JavaScriptでPOSTリクエストを作成できます。JavaScriptでCSRFトークンを収集して送信できます。他に何が必要ですか?

  • Keylogging-あなたはこれが何であるか知っています。

  • 録音オーディオ-ユーザーの承認が必要ですが、被害者のマイクにアクセスします。 HTML5とJavaScriptに感謝します。

  • 写真を撮る-ユーザーの許可が必要ですが、被害者のWebカメラにアクセスします。 HTML5とJavaScriptに感謝します。

  • Geo-location-ユーザーからの承認が必要ですが、被害者のGeo-locationにアクセスします。 HTML5とJavaScriptに感謝します。 GPSを備えたデバイスでよりよく機能します。

  • HTML5 Webストレージデータの盗用-HTML5は、Webストレージという新機能を導入しました。これで、Webサイトは後で使用できるようにブラウザーにデータを保存でき、JavaScriptはwindow.localStorage()およびwindow.webStorage()を介してそのストレージにアクセスできますブラウザーとシステム

  • Fingerprinting-JavaScriptを使用すると、ブラウザ名、バージョン、インストールされているプラ​​グインとそのバージョン、オペレーティングシステム、アーキテクチャ、システム時間、言語、画面解像度を簡単に見つけることができます。

  • ネットワークスキャン-JavaScriptでポートとホストをスキャンするために、被害者のブラウザが悪用される可能性があります。

  • ブラウザのクラッシュ-はい!あなたはそれらをあふれさせる….stuffでブラウザをクラッシュさせることができます。

  • 盗む情報-Webページから情報を取得し、サーバーに送信します。シンプル!

  • リダイレクト-JavaScriptを使用して、ユーザーを選択したWebページにリダイレクトできます。

  • Tabnapping-リダイレクトの洗練されたバージョン。たとえば、キーボードまたはマウスのイベントが1分以上受信されなかった場合、そのユーザーはafkであり、現在のWebページを偽のページにこっそり置き換えることができます。

  • キャプチャスクリーンショット-HTML5のおかげで、ウェブページのスクリーンショットを撮ることができます。ブラインドXSS検出ツールは、クールになる前にこれを行っていました。

  • アクションを実行-ブラウザを制御しています。

92
Goron

たぶん実際の例は、XSSのような、明らかにマイナーなセキュリティ上の欠陥がどれほど危険であるかを理解するのに役立ちます。

セキュリティ評価の一環として、私の会社はCEOの個人の電子メールにアクセスすることを試みられました。
私はなんらかのOSintを介して個人の電子メールアドレスを取得することができましたが、今では多くの情報盗用マルウェアの1つのカスタムバージョンを使用してスピアフィッシングに行くことができましたが、情報収集フェーズをもう少し延長しました。

それは、CEOがボートを愛し、彼らの1つをボート販売サイトで販売していたことが判明しました。
このサイトはかなりアマチュアらしいので、登録して少し騙しました。そして、私は何を見つけましたか?
このサイトでは、パスワードフィールドに現在のパスワードフィールドを事前に入力して管理できます。これにより、サイトをもう少し詳しく調査します。
保存されたXSSの脆弱性に遭遇しました。オファーに答えると、スクリプトを含む任意のHTMLコードをその中に入れることができ、それがリーダーブラウザーで実行されます!

かなり「無害」に見えませんか?それをパスワードの不適切な管理と組み合わせるとどうなりますか?

そこで、パスワードページを取得するスクリプトを作成し(これはドメイン内の要求であり、SOPが満たされています)、パスワードとクライアント情報(UA、OSなど)を抽出して送信します私のC&C。
それから、購入する「私の意思」を知らせる電子メールを注意深く書いて、CEOに衝動を吹き込みました。

1日後、ボートサイトへのログインに使用したパスワードを受け取りました。
予想通り、それは彼らの電子メールに使用されたのと同じパスワードであり(2FAがなかった、それがまだ物だったかどうか思い出せない)、ウェブメールにアクセスできた(クライアント情報が使用された)目立たないようにする必要がある場合に備えて、正当なアクセスをシミュレートします)。

簡単に言えば、攻撃は単一の原子的なステップではなく、ほとんど征服されていません。敵に一歩の余裕を与えると、彼らがそこから何ができるかわかりません。 XSSのかなりの部分をご覧になったように、XSSは攻撃者にとって余地があります。

34
Margaret Bloom

クライアント側のWebアプリケーションのコンテキスト内で実行される攻撃者制御のコードは、クライアントの動作を完全に制御し、HTMLページのDOMなどを読み取ることもできます。

これは、このページ内にあるシークレット(パスワードなど)を盗むだけでなく、ログインしたクライアント(何かを購入する、メールクライアントで爆弾の脅威を送信するなど)も実行できることを意味します。この種のアクティビティは、クライアントから隠されている場合が多いため、クライアントが現在攻撃されていることに気付かないことに注意してください。

25
Steffen Ullrich

XSS攻撃はサーバーにとって危険ではありません。それはあなたがサーバーを持っている理由への危険です。技術的な意味ではなく、人間による攻撃です。サイトから発生するあらゆる種類のXSS攻撃は、通常、トイレでの評判で終わります。いくつかのテストケース:

  • 誰かがあなたのサイトから偽のログインページにリダイレクトします。これで、サイトのユーザーアカウントに大量のセキュリティ違反が発生する可能性があります。
  • 誰かがあなたのサイトにクリプトマイナーを置きます。これにより、訪問者のマシンが長時間動作し、発見されたときに、システム管理者として非常に貪欲であるか、または非常に無能であるかのように見えます。どちらも見栄えがよくありません。
  • 誰かがトラフィックをサイトから競合他社にリダイレクトします。これが悪い理由を説明する必要はありません。
  • 誰かがJavaScriptをそこに配置すると、サイトが使用できなくなったり、ブラウザがクラッシュしたりします。繰り返しますが、これがなぜ悪いのかは明らかです。
  • 誰かがDDOSコードをサイトに挿入して、サイトまたはサードパーティを停止させようとします。あなたを対象とする場合、これが悪い理由は明らかです。他の誰かを狙っており、サイトが不法行為であると見なされる場合、契約違反のためにサイトを修正しないと、ホスティングプロバイダーがあなたを遮断する可能性があります。
  • 誰かがあなたの広告を自分のものに置き換えます。広告収入に依存している場合、彼らはその収入を盗んでいます。
  • 誰かがそれを使ってユーザーをのぞきます。 Hel-lo、GDPR違反。
11
520

XSSがWebアプリケーションのセキュリティコミュニティで最初に広く知られるようになったとき、一部のプロの侵入テスト担当者はXSSを「不完全な」脆弱性と見なす傾向がありました

出典:Web Application Hackers Handbook

XSSはクライアント側のコマンドインジェクションであり、他のユーザーが指摘したように、ユーザーが実行できるアクションが発生する可能性があります。ほとんどの場合、XSSは、攻撃者がJavaScriptを使用してセッションCookieを攻撃者が制御するサーバーに送信し、そこから攻撃者が「セッションライディング」を実行できるセッションハイジャックに使用されます。

ただし、XSSはアプリケーションの完全なテイクオーバーを引き起こす可能性もあります。 JavaScriptを挿入して保存するシナリオを考えてみます。次に、管理者はそれをWebブラウザー(通常はログまたはCMS)にロードします。 XSSが存在する場合は、管理セッショントークンを取得しています。そのため、XSSは非常に危険です。

10
Vipul Nair

XSSの脆弱性がもたらす可能性のある影響のほとんどは、サーバーではなくユーザーに影響します。そのため、ユーザーがWebサイトのアカウントを侵害したり、ユーザーのWebサイトにサーバー以外のコンテンツが表示されることを気にしない場合は、これらの脆弱性を無視してください。

ただし、ユーザーに管理者権限がある場合、XSSの脆弱性により、意図しない管理操作が簡単に発生する可能性があります。その典型的なケースは、XSSに対応していない管理領域のログビューアーです。アクセスログの一部のJavaScriptスニペットは、管理者によって実行され、そのアカウントで管理アクションを実行する場合があります。このため、ウェブサイトをハッキングしようとするボットのHTTPヘッダーにJavaScriptスニペットが表示されることがあります。

8
Philipp

XSSを使用して、約10年前のインシデントでサーバーを直接引き継いだ実際の例を示します(ただし、(小さい/重要でない)Webサイトの名前を忘れてしまい、もう存在しないと思います)。

Webマスターに報告:「WebサイトにXSSの脆弱性があります。これを修正する必要があります。詳細をどのように送信すればよいですか?」

志望のWebマスターの回答:「これをどのように悪用するかを見せてください。私のサーバーは非常に安全です。必要に応じて試してみてください。でもチャンスはありません。」

記者の回答:「それからあなたのウェブサイトの私のプロフィールページを見てください。」

ウェブマスターはこれを行い、突然ウェブサイト全体が死んでしまいました。どうした?レポーターは、XSSの脆弱性を使用して、JavaScriptコードをプロファイルページに挿入しました。

JavaScriptコード(ブラウザーおよびWebマスターのセッションで実行)は、サーバーに次の要求を送信しました。

  1. 最高の権限を持つ新しいアカウントを追加する(デモ目的)
  2. サーバー上のPHPファイルとSQLテーブルの名前を変更する(ウェブサイトには、多くのCMSシステムと同様の更新やウィジェットのインストールなどの管理目的でこれを許可する管理セクションがありました)

ホスティング会社にサーバーとドメインのサブスクリプションをキャンセルし、彼の銀行口座から送金するリクエストを送信することにより、追加の損害が発生した可能性があります(ウェブマスターがホスティング事業者/ドメインレジストラー/銀行にログインしており、 CSRF保護(これは10年前には珍しくありませんでした)。

MySpace-worm Samy のようなXSSワームも忘れないでください。これらはすべてのプロファイルページに広がり、サーバーにDDOSを実行したり、ユーザーに害を及ぼしたりする可能性があります。

4
H. Idden

クライアントではなくサーバー(SQLなどを含む)に対する危険を探しているように見えるため、多くの危険は当てはまりません。

しかし、クライアントに対してサーバー上で許可されていることからサーバーに対しての危険があります。クライアントにデータベースを変更する権限がある場合、攻撃者も同様に変更できます。また、クライアントがサーバー上で実行する権限を持つすべてのことについても同じことが言えます。

3
User42

XSS自体は次の意味で危険です。

  • セッションID/Cookieは、被害者のアカウントへの完全なアクセスを取得するために盗まれる可能性があります。
  • ウェブサイトの一時的な改ざん。悪質なJSスクリプトの実行(マイナー、カードデータスティーラー、キーロガーなど)
  • 攻撃者は、ビーフなどの悪用フレームワークを使用して、リモートでWebカメラを開く、マイクを回す、すべてのWebサイトを悪意のあるWebサイトにリダイレクトするなど、一部のOS呼び出しを行うことができます。
  • XSSは、被害者のシークレットトークン、CSRF(クロスサイトリクエストフォージェリ)トークン、APIキーを盗むために使用される場合があり、CSRF攻撃などのさらなる悪用が行われる可能性があります。

このブログ および これ は、XSS攻撃を使用してWebアプリケーションでSQLインジェクションを実行する方法を示しています。

1
Kailash

他の回答から、XSSが問題となる技術的理由の非常に優れたリストがあります。別の見方をします。

XSSは、コードに取り込むのが非常に簡単な脆弱性であり、スキャナーによって発見可能です。これはおそらく、ジャーナリストを含む(「私はそれについて聞いた」という意味で)「一般市民」にとって 比較的よく知られている である理由の1つです。

公開されているものがある場合は、次のように記述できます。

Sai Kumar LLCにはXSSがあるため、非常に脆弱なサイトがあります。 XSSは非常に危険な脆弱性です。非常に。そうです。

これにより、すべてのデータが盗まれる可能性があります。します。 The͟҉da҉t͘a̵͢haś̴al͞r̀ead́y͠b̷e̷e̶n̨s͝t͜o̢l͝e͜n。そうだね。

その後、脆弱性ではないことを説明するあらゆる種類のベリーダンスを実行できます。エラータは、74ページのフォント3 ptでグレー表示されます。

これが、私が公開しているWebサイトでXSSのCVSSの調査結果を体系的に上げている理由です(ペンテスト、スキャン、またはその他のテストで判明した場合)。

0
WoJ

格納されたクロスサイトスクリプティングは、さまざまな理由で非常に危険です。ブラウザのXSSフィルターからペイロードが見えなくなります。影響を受けるページにアクセスすると、ユーザーは偶然にペイロードをトリガーする可能性がありますが、反射されたXSSを悪用するには、巧妙なURLまたは正確なフォーム入力が必要です。

0
Tatum