クロスサイトスクリプティング

非永続型（またはリフレクテッド型）クロスサイトスクリプティングの脆弱性は^、ウェブの脆弱性の中で最も基本的なタイプです。^{[ 9 ]}これらの脆弱性は、ウェブクライアントから提供されたデータ^{（最も一般的にはHTTPクエリパラメータ（HTMLフォーム送信など） ）}が、コンテンツを適切にサニタイズすることなく、サーバーサイドスクリプトによってすぐに使用され、そのユーザーに対する結果ページを解析および表示する場合に発生します。[10] ^{[ 11 ]}

HTML 文書は、制御文、書式設定、実際のコンテンツが混在するフラットで連続的な構造になっているため、適切な HTML エンコードなしで結果のページに含まれる検証されていないユーザー提供データは、マークアップ挿入につながる可能性があります。^{[ 9 ] [ 11 ]}潜在的な攻撃経路の典型的な例は、サイト検索エンジンです。文字列を検索すると、通常は検索文字列がそのまま結果ページに再表示され、何を検索したかが示されます。この応答で HTML 制御文字が適切にエスケープまたは拒否されない場合、クロスサイトスクリプティングの脆弱性が発生します。^{[ 12 ]}

反射型攻撃は通常、電子メールまたは中立的なウェブサイトを介して行われます。おとりとなるのは、信頼できるサイトを指し示す一見無害なURLですが、実際にはXSS攻撃の脆弱性が含まれています。信頼できるサイトがこの脆弱性の影響を受ける場合、リンクをクリックすると、被害者のブラウザで注入されたスクリプトが実行される可能性があります。

永続的（または保存型）XSS脆弱性は、クロスサイトスクリプティングの脆弱性のより深刻な亜種です。これは、攻撃者によって提供されたデータがサーバーに保存され、適切なHTMLエスケープ処理なしに、通常のブラウジング中に他のユーザーに返される「通常の」ページに永続的に表示される場合に発生します。この典型的な例は、ユーザーが他のユーザーが読むためのHTML形式のメッセージを投稿できるオンラインメッセージボードです。^{[ 11 ]}

例えば、会員同士がプロフィールを閲覧して興味を引く相手を探す出会い系サイトがあるとします。プライバシー保護のため、このサイトでは全員の実名とメールアドレスを非公開にしています。これらはサーバー上で秘密に保管されています。会員の実名とメールアドレスがブラウザに表示されるのは、会員がログインしている時だけで、他の会員の情報は閲覧できません。

攻撃者であるマロリーがサイトに登録し、サイト上で見かける人々の本名を突き止めたいとします。そのため、彼女は他のユーザーが自分のプロフィールにアクセスした際にブラウザ上で実行されるスクリプトを作成します。このスクリプトは、彼女自身のサーバーに短いメッセージを送信し、サーバーはこの情報を収集します。

そのため、「理想の初デートについて教えてください」という質問に対し、マロリーは（普通に見えるように）短い回答をしますが、回答の最後に名前とメールアドレスを盗むためのスクリプトを記述します。スクリプトが<script><script>要素で囲まれている場合は、画面には表示されません。次に、出会い系サイトのメンバーであるボブが、初デートの質問に対するマロリーの回答が掲載されている彼女のプロフィールにアクセスしたとします。ブラウザによってスクリプトが自動的に実行され、ボブの実際の名前とメールアドレスがボブ自身のコンピュータから直接盗まれます。

持続型 XSS 脆弱性は、攻撃者の悪意のあるスクリプトが自動的にレンダリングされ、被害者を個別に標的にしたり、第三者の Web サイトに誘導したりする必要がないため、他のタイプの脆弱性よりも深刻な場合があります。特にソーシャル ネットワーキング サイトの場合、コードはアカウント間で自己増殖するように設計され、クライアント サイドワームの一種を作成します。^{[ 13 ]}

インジェクションの手法は多岐にわたります。場合によっては、攻撃者はウェブ機能自体に直接アクセスする必要すらなく、脆弱性を悪用できることもあります。ウェブアプリケーションが受信するデータ（電子メール、システムログ、インスタントメッセージなど）のうち、攻撃者が制御できるものはすべて、インジェクション攻撃の経路となり得ます。

XSS脆弱性は、当初、すべてのデータ処理をサーバー側で行うアプリケーションで発見されました。ユーザー入力（XSS攻撃の脆弱性を含む）はサーバーに送信され、その後、Webページとしてユーザーに返送されます。ユーザーエクスペリエンスの向上へのニーズの高まりにより、プレゼンテーションロジックの大部分（JavaScriptで記述されている場合もある）をクライアント側で実行し、 AJAXを使用してサーバーからオンデマンドでデータを取得するアプリケーションが普及しました。

JavaScript コードもユーザー入力を処理して Web ページコンテンツにレンダリングしていたため、 DOMベースのクロスサイトスクリプティングと呼ばれる、反射型 XSS 攻撃の新しいサブクラスが現れ始めました。DOM ベースの XSS 攻撃では、悪意のあるデータは Web サーバーに触れません。むしろ、完全にクライアント側で JavaScript コードによって反射されます。^{[ 14 ]}

DOM ベースの XSS 脆弱性の例としては、2011 年に多数のjQueryプラグインで発見されたバグが挙げられます。^{[ 15 ]} DOM ベースの XSS 攻撃に対する対策には、従来の XSS 対策と非常によく似た対策が含まれますが、JavaScriptコードで実装され、Web ページ内に含まれます (入力検証とエスケープなど)。^{[ 16 ]}一部のJavaScript フレームワークには、この攻撃や他のタイプの攻撃に対する対策が組み込まれています。たとえば、AngularJSなどです。^{[ 17 ]}

自己XSSは、被害者を騙してブラウザで悪意のあるJavaScriptコードを実行させるソーシャルエンジニアリングに依存するXSS脆弱性の一種です。攻撃者がコードを実行できるようにする影響を受けるWebサイトの欠陥ではなく、ユーザーをソーシャルエンジニアリングしてコードを実行させるため、技術的には真のXSS脆弱性ではありませんが、適切に実行された場合、通常のXSS脆弱性と同じリスクをもたらします。^{[ 18 ]}

変異型 XSS は、攻撃者が一見安全に見えるものを挿入し、ブラウザがマークアップを解析する際に書き換えや変更が行われる場合に発生します。これにより、Web サイトのアプリケーション ロジック内で検出やサニタイズが非常に困難になります。例としては、閉じられていない引用符のバランス調整や、CSS の font-family プロパティで引用されていない値に引用符を追加することなどが挙げられます。^{[ 19 ]}

信頼できない文字列を HTML ドキュメント内のどこに配置する必要があるかに応じて使用できるエスケープ方式はいくつかあり、HTML エンティティ エンコーディング、JavaScript エスケープ、CSS エスケープ、URL (またはパーセント) エンコーディングなどがあります。^{[ 20 ]}リッチ データを受け入れる必要のないほとんどの Web アプリケーションは、エスケープを使用して XSS 攻撃のリスクをかなり簡単に排除できます。

XMLの重要な5文字のみにHTMLエンティティエンコーディングを実行するだけでは、多くの種類のXSS攻撃を防ぐには十分ではないため、セキュリティエンコーディングライブラリの方が通常は使いやすい。^{[ 20 ]}

一部のウェブテンプレートシステムは、生成するHTMLの構造を理解し、適切なエンコーダーを自動的に選択します。^{[ 21 ] [ 22 ]}

特定のウェブアプリケーション（フォーラムやウェブメールなど）の多くの運営者は、ユーザーがHTMLマークアップを利用できるようにしています。ユーザーからHTML入力（例えば、）を受け取る場合、出力エンコーディング（例えば、）では不十分です。なぜなら、ユーザー入力はブラウザによってHTMLとしてレンダリングされる必要があるからです（つまり、ではなく、と表示される）。このような状況では、ユーザーからHTML入力を受け取る際にXSS攻撃を防ぐのははるかに複雑です。多くの場合、信頼できないHTML入力は、潜在的に悪意のあるJavaScriptコードが含まれていないことを確認するために、 HTMLサニタイズエンジンを通して処理する必要があります。<b>very</b> large&lt;b&gt;very&lt;/b&gt; largevery large<b>very</b> large

例えば、ユーザーが入力した場合

< span style = " color : blue;" > Hello world </span> <script> alert ( " XSS " ) </script>

すると、マークアップを処理するアプリケーションは、入力が表示されるときにスクリプトをエスケープして許可する場合があります。<span>

< span style = "color: blue;" > Hello world </span> & lt; script > alert( " XSS " ) < /script >

多くの検証は、<p> 、<h1>、 <h2>などの特定の「リスクのある」HTMLタグを解析（ブラックリスト化）するか、特定のタグのみを許可し、他のタグを削除またはエスケープすることによって行われます。<iframe><link><script>

このアプローチにはいくつかの問題点があります。例えば、一見無害に見えるタグが省略されることがありますが、正しく利用すればXSS攻撃につながる可能性があります。

もう1つの一般的な方法は、ユーザー入力から「」と「'」を削除することですが、ペイロードは難読化によって隠蔽できるため、これも回避できます。

コンテンツフィルタリング以外にも、クロスサイトスクリプティング対策として、不完全な方法も一般的に用いられています。その一例として、Cookieベースのユーザー認証を処理する際に、追加のセキュリティ制御を用いることが挙げられます。多くの Web アプリケーションは、個々の HTTP リクエスト間の認証にセッション Cookie を使用していますが、クライアント側のスクリプトは一般的にこれらの Cookie にアクセスできるため、単純な XSS 攻撃によってこれらの Cookie を盗むことが可能です。^{[ 23 ]}この特定の脅威 (XSS 問題全般ではなく) を軽減するために、多くの Web アプリケーションは、セッション Cookie を最初にログインしたユーザーの IP アドレスに紐付け、その IP アドレスのみがその Cookie を使用できるようにしています。^{[ 24 ]}これは、ほとんどの場合 (攻撃者が Cookie だけを狙っている場合) 効果的ですが、攻撃者が被害者と同じNAT されたIP アドレスまたはWeb プロキシの背後にいる場合、または被害者がモバイル IPを変更している場合は、明らかに機能しなくなります。^{[ 24 ]}

Web 2.0やAjax の開発者は JavaScript の使用を必要としますが、 ^{[ 26 ]}一部の Web アプリケーションはクライアント サイド スクリプトを必要とせずに動作するように記述されています。^{[ 27 ]}これにより、ユーザーは必要に応じて、アプリケーションを使用する前にブラウザでスクリプトを無効にすることができます。このようにして、潜在的に悪意のあるクライアント サイド スクリプトがエスケープされずにページに挿入されても、ユーザーは XSS 攻撃の影響を受けなくなります。

一部のブラウザやブラウザプラグインでは、ドメインごとにクライアントサイドスクリプトを無効にするように設定できます。この方法は、スクリプトがデフォルトで許可されている場合は、ユーザーが悪質なサイトだと認識した後にしかブロックできないため、効果が限定的です。すべてのスクリプトと外部インクルージョンをデフォルトでブロックし、ドメインごとにユーザーが有効にできるようにする機能の方が効果的です。これは、Internet Explorer (バージョン 4 以降) では「セキュリティゾーン」と呼ばれる設定で、Opera (バージョン 9 以降) では「サイト固有の設定」を使用することで、長い間可能でした。^{[28] Firefoxやその他の}Geckoベースのブラウザ向けの解決策は、オープンソースのNoScriptアドオンです^。これは、ドメインごとにスクリプトを有効にする機能に加えて、スクリプトが有効になっている場合でも XSS 保護を提供します。^{[ 30 ]}

すべての Web サイトのすべてのスクリプトをデフォルトでブロックすることの最も重大な問題は、機能性と応答性が大幅に低下することです (クライアント サイド スクリプティングは、リモート サーバーに接続する必要がなく、ページやフレームを再読み込みする必要がないため、サーバー サイド スクリプティングよりもはるかに高速です)。^{[ 31 ]}スクリプト ブロックのもう 1 つの問題は、多くのユーザーがそれを理解せず、ブラウザを適切に保護する方法を知らないことです。さらに、多くのサイトはクライアント サイド スクリプティングなしでは動作しないため、ユーザーはそのサイトの保護を無効にせざるを得ず、システムを脆弱性にさらすことになります。^{[ 32 ]} Firefox の NoScript 拡張機能を使用すると、ユーザーは特定のページからのスクリプトを選択的に許可し、同じページの他のスクリプトを禁止することができます。たとえば、example.com からのスクリプトは許可し、同じページで実行しようとしている advertisingagency.com からのスクリプトは禁止することができます。^{[ 33 ]}

トラステッド型^{[ 34 ]}は、値が信頼できるものとして商標登録されているかどうかを確認するようにWeb APIを変更します。プログラムが信頼できる値のみを商標登録している限り、JavaScript文字列値を制御する攻撃者はXSSを引き起こすことはできません。トラステッド型は、ブルーチームによる監査が可能になるように設計されています。  

別の防御アプローチとしては、Web ページ内の XSS 悪意のあるコードを削除する自動ツールを使用することがあります。これらのツールは、静的解析やパターンマッチングの方法を使用して潜在的に悪意のあるコードを特定し、エスケープなどの方法を使用してそれらを保護し ます。^{[ 35 ]}

Cookie がSameSite=Strictパラメーターとともに設定されている場合、すべてのクロスオリジンリクエストから削除されます。 とともに設定されている場合SameSite=Lax、すべての「安全でない」クロスオリジンリクエスト (つまり、読み取り専用の意味を持つ GET、OPTIONS、および TRACE 以外のリクエスト) から削除されます。^{[ 36 ]}この機能は、 Google Chromeではバージョン 63 以降、Firefox ではバージョン 60 以降で実装されています。^{[ 37 ]}