ハッカーはどのようにして被害者をXSS攻撃URLにアクセスさせますか？
私が理解しているように、XSSの基本的な考え方は、ユーザーのブラウザーにハッカーが作成した悪意のあるコードを実行させることです。
たとえば、ユーザーがこのURLにアクセスしたときに、ページに任意のスクリプトをロードする脆弱性があるとします。
http://www.example.com/apage?filename=malicious.js
次に、ブラウザはmalicious.jsファイルを問題なくロードし、ユーザーはハッキングされます。
私の質問は、ハッカーがユーザーにそのようなURLにアクセスさせる方法ですか？
上記の場合と同様に、他のすべての手法と同様に、すべての前提条件が1つあります。ユーザーは、通常は実行しないアクションを実行する必要があります。
ハッカーが「こんにちは、何か面白いものがあります、見てください！」誰にとっても、それはあまり効果的な攻撃にはなりません。
それで、これを自動的に行うためのトリックはありますか？またはこれを引き起こす実際のケースはありますか？
ユーザーがいつものように実行しない操作を行った
リンクをクリックすることは、ほとんどのユーザーにとって通常のアクションのようです。
たとえば この調査 を参照してください。56％のユーザーが不明な送信者からのメールのリンクをクリックし、40％がFacebook経由で送信されたリンクをクリックしました（78％が可能性を認識しているにもかかわらず）危険）。 50％は、送信者を知らなかったため、リンクをクリックしなかったと述べています。
それはすでに印象的な成功率です。被害者が攻撃者を知っている場合、または攻撃者が知っている誰かの身元を偽った場合、この率はさらに増加する可能性があります。
ソーシャルネットワークでは、反映されたXSSもワーム可能である可能性があります。悪意のあるアクションに加えて、挿入されたスクリプトは、リンクを含むメッセージを被害者のすべての友達に送信する可能性があります（このような何かが発生した Twitter など）。
電子メールに加えて、リンクはフォーラム、ブログ、課題追跡などにも配布できます。たとえば、これは Apache に起こりました。
それも私がいつも疑問に思っていることであり、私が尋ねたとき、私は通常、「ユーザーは気にせずすべてをクリックする」と言われました。そうは言っても、反映されたXSSは実際にはソフトウェアの脆弱性ではなく、ユーザーの脆弱性のように思えます。私は通常、リンクのプレビューをチェックし（ブラウザーのリンクの上にマウスを置いて）、誰かが私に をクリックするように言った場合、奇妙に聞こえましたStackExchange に関するこの質問と奇妙な形式（パスを参照）を見つけたので、クリックしません。
ただし、反映されたXSSを最初よりも危険にする方法はいくつかあると私は言わなければなりません。次の点を考慮してください。
- 自動クリック、リダイレクト、または類似のトリック：クリックする必要はありません。悪意のあるWebサイトに着地するだけで、ターゲットWebサイトに自動的にリダイレクトされ、悪意のあるJavaScriptが実行されます。ターゲットWebサイトにログインしている場合、攻撃者は任意のJavaScriptを実行させ、悪意のあるアクション（送信または削除など）を実行させます。
- 通常、URLが長いか複雑な（ユーザーフレンドリーではない）Webサイトで、ユーザーはとにかく信頼する傾向がある。私はアマゾンでこれを見る傾向があり、リンクはとにかく読めません。
- プレビューを簡単に表示できないブラウザー。たとえば、モバイルブラウザーやその他のソフトウェアのように、ホバーするだけの簡単なものではありません。モバイルではリンクを確認するのに時間をかけないことを認めなければなりません。タップするだけですが、モバイルでは信頼できるWebサイトの限定された選択のみを使用しようとします。
- 攻撃者は被害者を知っており、リンクをクリックしたりページにアクセスしたりするように説得する方法を知っています。被害者は攻撃者を信頼する場合さえあります。見知らぬ人からのランダムなメールは、（悪意のある）知人からのFacebookのプライベートメッセージとは異なります。
- おっぱいと笑：おっぱい、笑猫などの写真は一時的に意識を失う可能性があり、物理法則のように一度にクリックする必要があるように感じるかもしれません。
したがって、反映されたXSSに関連するリスクは、ユーザー、影響を受けるWebサイトに与えられた信頼、ターゲットWebサイトでの可能なアクションなどによって大きく異なる可能性があることがわかります。定義により、入力サニタイズの弱点を悪用することで任意のJavaScript実行を許可するためです。
あなたが与えた例は非常に簡単です。共有されるURLに数十のGETパラメータを持つアプリケーションはたくさんあります。攻撃者が必要とするのは、これを成功させるために、これらの1つが反映されたXSSに対して脆弱であることです。誰かが期待しているリンクが長くて複雑であり、得られるものが長くて複雑な場合、各パラメータを調べない場合があります。
また、URL短縮機能を使用することもできます。
XSSには、反射型と永続型の2つの主要なタイプがあります。永続的なXSSは、サーバーに格納されて他のユーザーに影響を与える場合であり、リフレクティブは格納されませんが、他のユーザーに影響を与える可能性があります。
私が見た1つの方法は、リダイレクトのようなものを保存することですが、サニタイジングは不十分です。このようにして、コードはサーバー側に格納され、誰かがページをリクエストすると、コードがコメントとともに読み込まれ、コードのブロックがトリガーされます。これにより、被害者が攻撃者のWebサイトにリダイレクトされ、他の悪意のあるものが発生する可能性があります。クレデンシャルハーベスタ、広告のスタックなどの偽のログインページ.
さらに情報が必要な場合はお知らせください。PCに戻ったら編集して詳細を追加できます。
編集：たとえば、サイトがこのタイプの攻撃を受けやすい場合、そのページにアクセスしたすべてのユーザーを新しいサイトにリダイレクトするコメントを残すことができます。この新しいサイトは、元のサイトとほぼ同一のコピーであり、再度ログインして、資格情報を盗みます。人々は複数のサイトで同じパスワードを使用する傾向があるため、これらの資格情報は他の場所などへのログインに使用される可能性があります。
基本的に
Web開発者がこれを行うときはいつでも：
<script src="someOtherDomainThanThisOne"></script>
それはXSSの可能な道です。ユーザーがアクセスしているサイトは、少なくとも、スクリプトをホストしているサイトだけが危険にさらされる必要はありません。
たとえば、私が私のウェブサイトwidgets.comで作業しているWeb開発者であり、この派手な新しいjsライブラリを見つけたとします。私のサイトから直接ホストする代わりに、cooljslibs.comから（スクリプトsrcを介して）セキュアパスを含めることを選択しました。将来のある時点で、cooljslibs.comが悪用されるか、誰かがハッキングしてホストされているファイルを危険にさらします。現在、widgets.comはハッキングされていませんが、cooljslibs.comのコードを盲目的に実行しているため、ユーザーとサイトが危険にさらされています。
これは、基本的にサードパーティファイルのハッシュチェックを強制するサブリソース整合性を使用して部分的に軽減できます。これに加えて、自分でホストすることをお勧めします。あなたはそれについてもっと学ぶことができます ここ 。例:)
<script src="https://example.com/example-framework.js"
integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
crossorigin="anonymous"></script>
XSSを実際に使用する方法の1つの素晴らしい例は、最近のブリティッシュエアウェイズのデータ侵害です。この記事で説明したように、 https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ 攻撃者は悪意のあるJavaScriptを保存し、支払いページの通常のスクリプトを置き換えました、それはユーザーが入力したクレジットカードを盗みます。スクリプトを変更するためにサーバーにアクセスできたため、これは典型的なXSS攻撃ではありませんが、このような攻撃の非常に有効なデモンストレーションです。
何らかの方法で有効なJavaScriptをWebサイト（保存されたXSS）に保存できる場合は、ユーザーのCookieを盗んでそのユーザーになりすまして、同じ情報（プロファイルデータなど）にアクセスできます。
反映されたXSSについては、他の人が指摘したように、ソーシャルエンジニアリングを行い、ユーザーに悪意のあるリンクをクリックさせる必要があります。
一部の攻撃では、被害者は攻撃者のページにアクセスする必要があります。それには、いくつかの方法があります。
- フィッシング。被害者にメール、Facebookページ、LinkedInの招待状を送信し、別のふりをします。この成功率はキャンペーンにどれだけの労力を費やすかに依存しますが、50％を超える成功率は珍しいことではありません。特にドメイン名が一致するため、somegoodsite.comのユーザーをだましてsomegoodsite.comリンクをクリックさせようとしますが、これは一般的に信頼できるものです。
- サイト自体からの包含。時々、サイトはユーザーコンテンツの追加を許可します。攻撃者がプロファイルページにiframeを追加できる場合、プロファイルにアクセスするすべてのユーザーが攻撃されます。ただし、iframeを任意のサイトに追加できることはほとんどありません。
- 中間者攻撃。中間者攻撃では、攻撃者は暗号化されていないデータを変更できます。 somegoodsite.comがHTTPSを使用している場合でも、攻撃者はHTTPSを使用していないWebページにiframeを挿入し、ブラウザーにそのURLにアクセスさせることができます。
- 広告。一部のサイトでは、ページをiframeまたは新しいウィンドウにロードする侵入型の広告を実行しています。無料のiPhoneを獲得したというメッセージが表示されることもありますが、XSSペイロードで実行することもできます。ただし、このような煩わしい広告を許可するサイトは非常にまれです。