「コード内のすべてのXSSを探す」ことは、コンピューターサイエンスの問題を解決したものですか？
基本的な理論の質問があります。クロスサイトスクリプティングをお探しですか？それとも未解決の問題ですか？それは、停止の問題、噴射の問題、または同様の既知のCSの問題を近似していますか？
または、XSSは扱いにくいものではありませんが、スクリプト化されたWebページへのソースとシンクの可能性、脆弱性に対するプログラマーの理解不足など、健全なソリューションのソリューションを妨げる大量のWebテクノロジーがあるため、見つけて修正するのは面倒です。 ？ （私はネイティブコードのNXビットに相当するものとしてコンテンツセキュリティポリシーを考えています）。
誰でも私に任意のリソース（アカデミアを含む）を教えてもらえれば幸いです。
Edit 2020-03-10：XSS問題は、技術的な問題として解決するのが「簡単」であるにもかかわらず、解決には程遠いです。 HackerOne によると、これは断然最も好ましい攻撃ベクトルです。さらに2019年には、ホワイトハットの間でますます人気の攻撃ベクトルになっています：2019年の38％対 2018 の28％。
私は正式な証明の専門家ではありませんが、少なくともあなたを正しい方向に向けることはできます。
XSS脆弱性の検索には、3つの要素があります。
- 信頼できないエントリポイントの有限セット。 XSSは、信頼できないデータを処理する場合にのみ発生します。あなたがしなければならない最初のことは、すべての信頼できないエントリーポイントを特定することです。 Webアプリケーションでは、これらは通常GETとPOSTパラメータおよびヘッダーです。しかし、環境変数、信頼できないデータベースコンテンツ、信頼できないローカルからフェッチされたデータなど、多くの間接/ 2次エントリポイントが潜在的に存在します。これらのソースが信頼できるかどうかは、アーキテクチャと保護対象の攻撃者の種類によって異なります。
- 動的に生成されたデータがサーバーの応答（つまり、Webサイト）に含まれる場所の有限セット XSSの脆弱性をトリガーするには、攻撃者は少なくとも1つによって解釈される悪意のある出力を作成できる必要がありますスクリプトコードとしてのブラウザエンジン。これが発生する可能性のあるすべての場所を特定するには、アプリケーションの出力層を分析し、動的に生成された出力がWebサイトに挿入される場所を確認する必要があります。
- 信頼できないエントリポイント（1）と潜在的に脆弱な出力場所（2）の間のすべてのパスデータフロー分析を実行すると、（1）と（2）を接続するすべてのパスを見つけることができます。各パスは、信頼できない入力を潜在的に脆弱なデータ出力場所に接続するため、XSSを許可する可能性があります。
それがあなたが使っているモデルです。次のステップは、識別されたすべてのパスをトレースし、XSSを防止する方法でデータを検証またはエンコードする関数を確認します。 XSSから保護するために、さまざまなタイプの出力場所にさまざまなタイプのフィルタリング/エンコーディングが必要になる場合があるため、これはトリッキーです。特定のパスの悪用から保護できるのは正しい方法だけです。
私が意図的にXSSに対する追加の保護メカニズムを無視したことに注意してください。これは第2の防御線と見なすことができます。
これはどういう意味ですか？はい、信頼できないエントリポイント、動的に生成されたすべてのデータ出力場所、およびそれらの間のすべてのパスを特定できれば、すべてのXSS脆弱性を見つけることができます。それでは、複雑なWebサイトにすべてのXSS脆弱性を見つける単一のソースコードスキャナーがないのはなぜですか？
これらの要件を満たすことは、実際には非常に複雑です。今日のWebアプリケーションは、数百万行のコードを含む膨大な量の異なるフレームワークで構成されています。エントリポイント-特に2次エントリポイント-は見過ごされやすく、多くの場合広大です。データフローは非常に複雑で、多くのフレームワークと関数を通過します。最新のコーディングパターン（リフレクションなど）では、データフロー分析がさらに困難になります。検証機能が特定のタイプのXSSから本当に保護するかどうかの判断は、特定のタイプの入力に対して複雑になる可能性があります。
したがって、理論的には実現可能であるように見えますが、ソースコードスキャナーはまだ存在せず、これらすべての問題を処理できます。つまり、多種多様なテクノロジスタックに対して、この一見単純なアプローチを実装することはまだできていませんでした。
2020年の時点では問題は解決していませんが、近づいています。 XSSの脆弱性は一般的ですが、通常、基本的なセキュリティ慣行に従わないサイトで発生します。サイトが優れたセキュリティ慣行に従っている場合、まれです。問題の大きな部分は、非常に単純なアプリケーションであっても、潜在的に脆弱な入力が数十または数百あることです。
XSSを修正する主なアプローチは次のとおりです。
自動エスケープを行う開発者ツール。例えばJSPでは、開発者はすべての入力をエスケープすることを覚えておく必要がありますが、新しいThymeLeafではエスケープは自動的に行われます。追加のエスケープが必要なページコンテキスト（<script>タグ内など）があるため、これは100％の修正ではありません。また、開発者はエスケープをオフにする必要がある場合があり、これにより脆弱性が生じる可能性があります。
ブラウザの改善。コンテンツセキュリティポリシーが主なものであり、CSSからスクリプトコンテキストを削除したり、コンテンツのスニッフィングを強化したりするなど、他の方法もありました。同じサイトのCookieなどの他のセキュリティ対策は、XSSにも役立ちます。
ペンテスト/監査ツール。最近、DASTとSASTはどちらもかなり良いものになっています。確かに商用ツールを購入すれば、オープンソースでもますます増えています。どちらも100％ではありません。 DASTは、アプリケーションの到達しにくいコーナーを見つけられないことがよくあります。 SASTは、さまざまな開発者テクノロジと格闘しています。ちなみに、理論的にはSASTは停止問題に悩まされていますが、実際には99％の時間は問題ではありません。
アクティブな防御-WAFなど。これらは一般に、XSSをブロックするのにかなり悪い時間を過ごしました。それらは一般に自動化された攻撃をブロックしますが、熟練した手動の攻撃者は通常それらを回避できます。 WAFがXSSを防御しようとするいくつかの事例があり、実際にXSSの欠陥が導入されています。
もちろん、モバイルアプリのオプションであるHTMLを使用しない場合、XSSは完全に解決された問題です。