RESTfulサービスのXSS防止
RESTfulサービスは現在、XMLスキーマとエンティティの検証を適用することにより、XSS攻撃から保護されています。どちらの場合も、これは次のような正規表現を介して行われます。
<xs:pattern value="[0-9]{1}[0-9a-z/\\ -]{0,7}" />
この検証は、XSSに対する信頼できる対策と見なすことができますか、それとも、さらなるセキュリティ対策を行う必要がありますか？
ここにはいくつかの角度があります：
（1）正しく生成された非HTML応答タイプを危険なHTMLとして誤って解釈する。 RESTサービスがJSONやXMLなどの応答を返していることを前提としています。 Content-Typeを使用し、最初の/ n /バイトに<htmlのような魔法の文字列があるため、ドキュメントをHTMLとして扱います。
最近のブラウザーでのこれに対する防御策は、ヘッダーX-Content-Type-Options: nosniffを使用することです。これは、すべての応答で一般的に行うのに適した方法です。すべてのケースをカバーするために、フォーマットにエンコードルールを使用して、HTMLと誤って解釈されない可能性のあるエンコード形式で、潜在的に機密性の高い可変テキストを入力しないようにすることができます。通常、これは<がJSONでエスケープする必要がある文字ではない場合でも、JSON文字列で\u003Cを<として書き込むことを意味します。とにかく、リテラル<を<にエンコードする必要があるので、XMLでそれをカバーできます。エンコーディングの引数があるその他の文字（攻撃は非常にわずかですが）は、+と{です。
（2）正しく生成されない応答、フォーマットの正しいエンコードが欠落しています。
入力検証は、詳細な防御手段であり、ビジネスルールを適用するための優れた方法です。しかし、それはしない注射の脆弱性から全面的に保護します。明示的にエスケープせずに文字列を追加してXMLまたはJSON応答をまとめると、攻撃者が不正な形式の応答を引き起こし、別の呼び出し元によって解釈される可能性があります。これはおそらく直接のXSSにはなりませんが、アプリ固有の論理的な問題を引き起こす可能性があります。
文字列を一緒に追加するたびに、コンテキストに適した形式の文字列エンコーディングを使用するか、より適切な方法として、それを自動的に行うデータ出力ライブラリ（標準のJSONまたはXMLシリアライザーなど）を使用します。これはあなたの応答が正しいことを確認し、セキュリティはその正確さの副作用です。
（3）XML文書タイプ。これは（1）と（2）の混合であり、インジェクションにより、XMLを別の種類のXMLとして解釈する可能性があります。 XMLインジェクションの問題が発生した場合、攻撃者はXHTMLまたはSVG名前空間を指すxmlnsを含む要素を応答に含める可能性があります。ドキュメントがWebブラウザーに直接読み込まれる場合は、そのサイトのオリジンで実行されるスクリプトコンテンツが含まれている可能性があり、XSSが存在する可能性があります。
（4）DOM XSS —クライアント側の応答の処理が悪い。 REST応答が、応答の値を取得してinnerHTMLをそれに設定するWebブラウザースクリプトによって消費されている場合でも、HTMLインジェクションの脆弱性があります。ほんの少し違う場所で。
Webサービスで使用されるcontent-typeは、応答を実行可能なJavaScriptコードとして解釈しないようにブラウザに指示する必要があります。たとえば、RESTful Webサービスは、使用されるマーシャリングタイプに応じて、application/jsonまたはapplication/xmlを使用できます。ボディのコンテンツに関係なく、攻撃者がこれらのコンテンツタイプでXSSを取得することは不可能です。
注意が必要なのは、誤ってcontent-typeをtext/htmlに設定するか、完全に省略することです。これにより、WebサービスでXSSが発生する可能性があります。