XSSの脆弱性とは何ですか？テスターがそれを見逃さないようにするにはどうすればよいですか？

私の観察では、かなりの数のテスターがXSSの脆弱性のようなことを聞​​いたことがあります。しかし、インタビューで彼女のことを簡単に話すことができる人はほとんどいません。または、この脆弱性についてWebサイトを効果的に確認してください。これらすべてを詳しく見て、この記事のために特別に用意したデモページで単純なXSSの脆弱性を見つけてみましょう。



あなたがセキュリティテストの第一人者であり、大規模なIT企業の報奨金プログラムに1〜2回参加していて、見つけたXSSの数が数十または数百である場合は、この記事を無視しても問題ありません。このトピックに不慣れで、脆弱性の発見に興味を持ち始めたばかりの場合は、猫の下で歓迎します。

定義

XSS（Cross-Site Scripting）は、多くのWebアプリケーションで見られるかなり一般的な脆弱性です。その本質は非常に単純です。攻撃者は、開発者から提供されていないページにJavaScriptコードを挿入することができます。このコードは、被害者（通常のユーザー）がこのコードが追加されたアプリケーションページにアクセスするたびに実行されます。そして、いくつかの開発シナリオがあります。



まず、攻撃者はユーザーの資格情報を取得して自分のアカウントにログインできるようになります。



第二に、攻撃者は被害者に気付かれずに別のクローンページにリダイレクトする可能性があります。このページは、ユーザーが期待するページと完全に同じに見える場合があります。しかし、それは侵入者に属します。ユーザーが置換に気付かず、このページに機密データ、つまり個人データを入力した場合、攻撃者はそれを入手します。



3番目...はい、一般的に、あなたが考えることができるより多く。 JavaScriptが実行できるほとんどすべてのことは、攻撃者が利用できるようになります。以下では、これらの例の1つを詳しく見ていきます。それまでの間、脆弱性がどのように機能するかについてもう少し詳しく説明してみましょう。また、攻撃者がソースにアクセスせずに自分のコードを他の誰かのアプリケーションに挿入することができるのはなぜですか。



少し警告。以下のすべての情報は、情報提供のみを目的として提示されています。テスターは、自分のWebアプリケーションの脆弱性をテストできる必要があります。ただし、他の人のリソースでXSSの脆弱性を悪用することは違法です。



現在のロシアの法律について言えば、研究者が他人の製品の脆弱性をテストしたり、所有者の知らないうちに他人のネットワークに侵入したりすると、彼の行動は違法と見なされる可能性があります。



しかし、XSSに戻ります。

脆弱性はどのように機能しますか？

まず、以前はなかったページにJavaScriptコードをどのように正確に挿入できますか？そして、このコードを他のユーザーにどのように配布しますか？



たとえば、JavaScriptコードを入力フィールドに追加して、そこからテキストを保存し、後ですべてのユーザーのページに表示することができます。これは、ソーシャルネットワークのプロフィールページに自分に関する情報を入力したり、フォーラムにコメントしたりするためのフィールドにすることができます。



攻撃者は、ページに保存されているテキスト（および1つの悪意のあるコード）を入力します。他のユーザーが同じページにアクセスすると、攻撃者のJavaScriptがテキストとともにダウンロードされます。ロードの時点で、このコードは機能します。もちろん、この脆弱性は、保存時にテキストが安全でない場合にのみ機能します。これを行う方法と、開発者が時々それを忘れる理由については、少し後で説明します。



これは、脆弱性を隠すことができる最も単純で最も明白な例です。以下では、特別に用意されたデモページでより興味深い例を検討します。



それまでは、先に進みましょう。

これらのエラーがWebプロジェクトで頻繁に見られるのはなぜですか？

要するに、ブラウザはプレーンテキストとCSS、HTML、またはJavaScriptコードであるテキストを個別に区別できないということです。 <script>タグの間のすべてをJavaScriptコードとして処理しようとします。 <style>タグの間にあるものはすべてCSSと見なされます。そして、タグのように見えるものはすべてHTMLコードと見なされます。



開発者が一部のテキストをコードのように見せたいが、そうではない（つまり、ブラウザで処理されなかったが、そのまま表示された）場合、このテキストはブラウザに渡す前に特別に処理する必要があります。この処理は「シールド」と呼ばれます。



このテキストのテキストをエスケープする過程で、すべてのスペシャル。文字は「カウンターパート」に置き換えられ、ブラウザはそれが単なるテキストであることをすでに確実に認識しています。最も重要なことは、ユーザーからのテキストを処理することです。これは、どのユーザーも攻撃者であることが判明し、テキストと一緒にコードを送信する可能性があるためです。残念ながら、開発者がWebアプリケーションの特定の場所でエスケープすることを忘れ、テキストが処理されずに表示されることがあります。これにはいくつかの理由が考えられます。



たとえば、プログラマーは、ユーザーが指定したテキストがページに表示されるすべての場所を常に念頭に置いているわけではありません。さらに、サイトのさまざまな部分がさまざまな時間に、および/またはさまざまな人々によって作成される場合があります。この場合、エラーの可能性が高くなります。



もう1つの理由は、脆弱性が開発者自身のコードではなく、開発者が使用するライブラリのコードにあることである可能性があります。通常、これらはWebサービスを作成するための既製のフレームワークです。この場合、開発者はもちろん、このフレームワークをプロジェクトに接続することで、既成の脆弱性をプロジェクトに自動的に接続することを疑うことさえできないかもしれません。



そのようなリスクは常にあります。それにもかかわらず、ライブラリをまったく使用せずにアプリケーションを完全にゼロから作成することは、今日では長くて費用がかかります。すべての企業がこのレベルを開発する余裕があるわけではありません。



この場合、すべての希望はテスターに​​あります。

XSSの脆弱性が危険なのはなぜですか？

もう一度、XSSの脆弱性の危険性について詳しく説明しましょう。脆弱性自体は危険ではありません。侵入者がそれを見つけて自分の目的に使い始めると危険になります。脆弱性を悪用することを「攻撃ベクトル」と呼びます。 XSSの場合、かなりの数の攻撃ベクトルがあります。



最も簡単な例は、Webアプリケーションのユーザーから認証Cookieを盗むことです。ほとんどの場合、許可があるサイトは、いわゆるセッションCookieによって許可されたユーザーを区別します。そこにない場合、ユーザーは許可されていません。もしそうなら、このクッキーの値によって、サーバーはあるユーザーを別のユーザーから区別することができます。



すべてのCookieはユーザーのコンピューターに保存されます。ユーザーとしてログインすると、Cookieの値が表示されます。そして、私は見知らぬ人の意味を見つけることができません。



ユーザーのブラウザで実行されるJavaScriptコードについても同じことが言えます。このJavaScriptコードは、ブラウザで実行されているユーザーのCookie値とその1つだけを表示します。



ここで、攻撃者がJavaScriptコードをWebアプリケーションページに挿入することに成功したと仮定しましょう。このページにアクセスしたユーザーは、ブラウザでJavaScriptコードを実行できます。このユーザー（現在は被害者）のCookie値を読み取ります。この値を攻撃者に渡すだけで、作業は完了です。しかし、悪意のあるコードは被害者のブラウザで実行されるため、値を渡す方法は？



とても簡単です。同じJavaScriptコードで、リモートサーバーへのAJAX要求を作成できます。たとえば、次のURLへ：www.zloy-site.ru/stolen= { victim_cookie_value }



zloy-siteドメインは、この例の攻撃者に属しています。このドメインに送信されるすべての要求は、データベースに記録されます。攻撃者はURLパラメータを確認することで、被害者のCookie値を学習し、それらを使用してアカウントにアクセスできます。



上で説明したように、XSSの脆弱性が危険である理由はこれだけではありません。したがって、セキュリティとユーザーを保護するために、プロジェクトでそのような脆弱性を見つけて修正できる必要があります。

XSSはどこにありますか？どのように対処しますか？例のあるデモページ

まず、一般ユーザーがコンテンツに影響を与える機会があるサイト上のXSSの脆弱性をチェックする価値があります。彼がどこかにテキストを追加できる場合は、JavaScriptコードも追加してみることができます。



具体的な例でこれを見てみましょう。 XSSの脆弱性が隠されている非常に単純なサンドボックスを用意しました。一緒に見つけてみることをお勧めします。



サンドボックスを開く：https：//playground.learnqa.ru/demo/xss



まず、ページがどのように機能するかを見てみましょう。それは本質的に検索できる非常に単純な本のカタログです。クエリに「RayBradbury」と入力すると、この著者のこのディレクトリにあるすべての本が表示されます。







注意深いユーザーは、検索フィールドに入力したテキストがすぐにURLに含まれることにすでに気づいています。この瞬間はまだ私たちに役立ちます。



とりあえず、検索ボックス「fwefewf」に意味のないものを挿入してみましょう。



この場合、ページに何も見つかりませんでした。そして、エラーテキストでリクエストテキストが繰り返されました。







それで、あなたと私は、私たちが入力したテキストが表示される場所を見つけました。したがって、これはXSSの脆弱性の潜在的なサイトです。最も人気のあるJavaScriptコードを挿入して、脆弱性があるかどうかを確認してみましょう。



<script> alert（123）</ script>



ページが脆弱な場合、このコードを入力すると、次のウィンドウがページに表示されます。







これは、JavaScriptコードが実行され、XSSの脆弱性が見つかったことを意味します。



したがって、コードを入力すると、次の警告が表示







されます。フォームは検証されており、文字と数字のみを処理する必要があるため、フォームではこの値で検索できません。一見、開発者はすべてを考慮に入れてページをXSSから保護しているように見えますが、これは完全に真実ではありません。



すぐ上で、検索フィールドに入力したテキストが、いわゆるGETパラメーターのURLに表示されていることに気づいたことを覚えていますか？このパラメータの名前は「q」で、値は検索フィールドに入力する値です。これは、この検索文字列と一緒にURLをコピーして、次に適切な作成者がいるページをすぐに開くことができるようにするためです。



たとえば、このURLはすぐにのみレイ・ブラッドベリの本でページを開きます：playground.learnqa.ru/demo/xss?q=Ray+Bradburyは



フォームとは異なり、開発者は、URL検証を行うことができませんでした-すべてのユーザーが自分のブラウザに任意のURLを入力することができますGETパラメータの任意の値を含め、必要なものは何でも。この場合の開発者のタスクは、すべてのオプションを考慮に入れ、このGETパラメーターの値に対して正しいハンドラーを作成することを忘れないことです。



開発者がここですべてを考慮に入れるのを忘れていないかどうかを確認しましょう。同じJavaScriptコードを「q」GETパラメーターに置き換えてみましょう。https：//playground.learnqa.ru/demo/xss？ q = <script> alert（123）</ script>



このURLをクリックすると、次のことがわかります。値123のウィンドウがページに表示されました。しかし、なぜですか？



とても簡単です。サイトが特定の検索クエリに必要な本を見つけることができない場合、この検索クエリのテキストをエラーのテキストで表示することを覚えていますか？同様に、クエリ「何とか何とか」に対して何も見つかりませんでした。この「何とか何とか」の代わりに、アラート付きのJavaScriptコードがあります。開発者は入力フィールドの検証を作成し、これが検索クエリに含まれるJavaScriptからサイトを保護する方法であると判断しました。そして、彼はエラーテキストを逃れませんでした。そこで検索クエリ値を変更することで、URLを介した検証をバイパスすることができました。



興味を引くために、セッションcookieの値を表示できるようになりました。これには、<script> alert（）</ script>の代わりに、URLに別のコードを置き換える必要があります：<script> alert（document.cookie）</ script>



これで遊んでみましょうあなた自身。 :)



バグを見つけた場合は、開発者に連絡する必要があります-彼らはそれを修正します。



エラーを閉じる方法はたくさんあります。テキストをエスケープするだけではありません。 JavaScript自体が一部のCookieを認識しないようにすることもできます。このため、Cookieには「httpのみ」という特別なパラメータがあります。 TRUEに設定されている場合、JavaScriptは、そのようなCookieが設定されていることをまったく検出できず、プロジェクトでXSSを見つけたとしても、それを読み取って攻撃者に転送することはできません。



これらはすべて、XSSの脆弱性を防ぐための操作の完全なリストからはほど遠い、ほんの小さなものです。上記のように、テスト中にXSSが検出された場合は、プログラマーに相談することをお勧めします。



セキュリティテストについて詳しく知りたい場合は、クライアントサーバーアーキテクチャの構造をよりよく理解し、実際のWebアプリケーションの脆弱性を見つける最も効果的な方法を理解して磨きたい場合は、私のコース「セキュリティテスト」にアクセスしてください。あなたが必要とするすべての情報は私のプロフィールにあります。



あなたは水なしで有用で必要な理論と多くの実際的な例と仕事だけを見つけるでしょう。さまざまな脆弱性が詰め込まれた多くのWebページを探索します。最終的な作業は、作業プロジェクト、またはGoogle、Facebook、Twitterなどの巨人のWebアプリケーションの1つに関する大規模な調査です。