XSSはサーバー側またはクライアント側の脆弱性ですか？
私の同僚は、XSSはサーバー側の脆弱性であると主張しています。これはクライアント側の脆弱性だといつも思っていました。私たちのどちらが正しいですか、そしてなぜですか？
クロスサイトスクリプティング攻撃では、悪意のあるスクリプトがクライアントで実行されますが、実際の欠陥はアプリケーションにあります。これは必ずしもアプリケーション側のJavaScriptに欠陥がある可能性があるという点で、厳密にサーバー側の脆弱性であるとは限りませんが、一般的にはサーバー側のコードにあり、常にサーバーによって配信されるコードにあります。
現在主要なブラウザーに組み込まれているXSS保護やJavaScriptの実行を妨げるプラグインなどのクライアント側の緩和策がありますが、最終的にはXSSはWebアプリケーションの脆弱性であり、アプリケーション開発者が修正する必要があります。
クライアント（ブラウザー）の欠陥もサーバー（アプリケーション）の欠陥も利用せず、ユーザーの欠陥を悪用する別の形式のXSSがあることにも触れておきます。これはしばしばSelf-XSSと呼ばれ、インターネットからブラウザの開発者ツールコンソールにコピーして貼り付けたJavaScriptを実行する無能なユーザーの意欲を利用して、すべての希望に反して魔法のように許可するという約束に基づいています彼女は彼と友達にならず彼をブロックしたという事実にもかかわらず、彼は彼の元ガールフレンドのFacebookの投稿を読むようになりました。
それはクライアント側に現れますが、それはWebアプリケーションによってそれが許可されているためです。アプリケーションは、ブラウザに送り返すコードを検証しません。それがサーバー側の脆弱性である理由です。このように考えてください。 XSSの問題を修正するにはどうしますか？サーバー側のコードを修正するか、ブラウザを修正しますか？
クロスサイトスクリプティング（XSS） 攻撃は一般的に次のいずれかに分類できます。
- 保存されたXSS攻撃
- 反映されたXSS攻撃
- DOMベースのXSS攻撃
攻撃自体がクライアントで発生しています。単一のページまたはオフラインアプリケーションの場合、3つの攻撃タイプすべてがブラウザ自体に完全に現れる可能性があります。ただし、データがサーバーに格納されているか、サーバーから反映されている場合、サーバーは脆弱性を支援しています。
IE8では X-XSS-Protection が導入され、反映された攻撃の悪用が困難になりました。
用語は少し滑りやすいですが、通常「XSSバグ」はサーバー側の脆弱性のクライアント側の悪用です。
クロスサイトスクリプティングは、それ自体、セキュリティ上の問題ではありません。問題は、エンドユーザーの知らないうちに発生する可能性があることです。もちろん、ほとんどのサイトはこれが発生するようにコーディングされていません。つまり、クロスサイトスクリプティングをまったく使用していないか、またはこれが彼らのしていることであることを明らかにしています。 しかし、ユーザーが自分のコンテンツを投稿できる場合は、ページに任意のスクリプトタグを追加しないようにする必要があります。そうしないと、ページにデータが送信され、どこにデータを送信しているかがわかります。
これを防ぐには、ユーザーが作成したコンテンツを解析し、不要なタグ（スクリプトタグなど）を持たない「クリーンな」HTMLを生成して表示する必要があります。一部のサイトはこの機会を利用して、ユーザーにHTML以外の言語でコンテンツを作成させています。StackExchangeはMarkdownを使用しています。ただし、コンテンツを適切に解析する限り、HTMLを入力言語として使用することもできます。他の言語と同じ種類の解析/生成サイクルを実行するため、HTMLからHTMLへの適切な変換にはパフォーマンス上の利点はありませんが、開発者（および場合によってはユーザー）が学習する言語は1つ少なくなります。ただし、HTMLコンテンツをそのまま再利用する、または解析/生成サイクルの代わりに簡単な文字列置換を行うという誘惑に抵抗する必要があります。
「XSSバグ」とは、人々が任意のHTMLをサイトに投稿する方法を理解したときに起こることです。通常、これは、開発者が解析/生成サイクルを実行せずに直接HTML入力を使用するときに発生しますが、サイトのジェネレーターをだまして、意図していないHTMLを提供する方法を誰かが見つけた場合もあります。どちらの方法でも、最終結果は同じです。ユーザーが任意のHTMLを投稿できれば、それを使用してクロスサイトスクリプティングを実行できます。そのため、これをXSSバグと呼びます。しかし、このバグはXSS自体にはありません。任意のスクリプトを最初に投稿できるようにしたのはサーバーサイドコードにあります。
次の理由により、クライアント側ではなくサーバー側でできるだけ多くのものをフィルタリングすることが一般的にベストプラクティスです。
- パフォーマンス
- 責任（あなたが持ってはいけないデータを送信すると、その影響を制御することはできません）
- ユーザーの安全性（通常、ユーザーが使用しているクライアントのバージョンがわからない）
XSS攻撃はSQLインジェクションと大差ありません。どちらもユーザー入力を適切に制御していないことが原因です。 XSS攻撃は通常、データベースに保存され、システムを介してクライアントに配布されます。
XSS攻撃のフィルタリングは、ユーザー入力で実行する必要があります。通常、どのタイプのJavascript入力も受け入れないでください。たとえばプログラミングサイトの場合など、クライアントがJavaScriptを入力できるようにする必要がある場合は、最初にそれをエスケープする必要があります。
お役に立てば幸いです。詳細については、この記事をお勧めします。 https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
「基本的に、攻撃者は特別な形式の電子メールを作成することで、JavaScriptを埋め込むことができます。これにより、Yahooメールで電子メールが表示されたときに、被害者のブラウザーでスクリプトが実行されます。」とPynnonenはThreatpostへの電子メールで述べています。 「攻撃者は特別なアクセスを必要としませんでした。実際には、Yahoo Mailに登録しなくても攻撃を実行できます。被害者のYahooメールアドレスのみが必要です。」
木曜日に公開された脆弱性の説明で、Pynnonenは、Yahoo MailがYouTubeなどのホワイトリストサイトへのリンクを表示する方法を悪用することによって実行されるYahooのフィルターを通過して悪意のあるJavaScriptをこっそり悪意のあるdata- *属性でメールをフォーマットする方法を説明しました。_[enter preformatted text here][1]_
別のユーザー情報などをロードするためにURLまたは何も使用しないことに関心がある一部の人々を読んだことがあります（たとえば、Googleのチュートリアルの https://xss-game.appspot.com/ ）
これは知っておくと便利ですが、クライアント側のすべての関数とコードの一部は任意に実行できることを覚えておく必要があります。 XSSの検証と保護はサーバーから行われます。つまり、コンソール自体を開くことができます。
アイデアは、サーバーからの脆弱性となるクライアントからの悪意のあるコードの注入です。これにより、他のクライアントがクラッピースクリプトが埋め込まれたWebページを受信する可能性があります。フォーラムについて考えてみてください。その投稿にタグを保存してレンダリングしただけで誰かが作成した場合は、そのフォーラム投稿を閲覧した人のために任意にコードを実行させる可能性があります。
たとえば、stackoverflowが適切にエスケープされなかった場合、おそらく以下のw/google.comにリダイレクトされます。
window.location.href = ' http://google.com '（これがスクリプトタグで囲まれていることを想像してください。SEはそれらをフォーマットし、怠惰すぎてエスケープできません）
サーバー側の脆弱性で、クライアント側のアプリケーションを介して悪用される可能性があります。