XSSが多くのWebサイトに影響を与えるのはなぜですか？
記事によると、私は世界中のすべてのウェブサイトの65％がXSSに苦しんでいると読みました。開発者がそれを見つけて修正できないのはなぜですか？
理解してください。私はセキュリティや技術の出身ではありません。
XSSはコードインジェクションの一種です。つまり、攻撃者はサイトが提供する信頼できるコード（HTML、CSS、JavaScript）に独自の悪意のあるコード（通常はJavaScript）を挿入します。これは、動的に作成されたコード（SQLステートメント、HTMLページなど）が原因で発生するという点で SQLi に似ています。
しかし、SQLiを解決するための確立された手法（つまり、パラメーターバインディングの使用）はありますが、XSSではさらに困難です。 XSSを防ぐには、ユーザーが制御するすべての入力を適切にエスケープする必要があります。これは、思ったよりもはるかに困難です。
- エスケープルールはコンテキストに依存します。つまり、HTML、HTML属性、XHTML、URL、スクリプト、CSSコンテキストはすべて異なるエスケープルールを持っています。
- これらのコンテキストはネストすることができます。つまり、
<a href=javascript:XXX>は、HTML属性内のURLコンテキスト内のJavaScriptコンテキストです。 - その上、文字のエンコーディングルール（UTF-8、UTF-7、latin1、...）があり、これもコンテキスト固有です。
- 出力を構築するとき、コンテキストとエンコーディングを知っておく必要があります。ほとんどのテンプレートエンジンは適切なHTMLエスケープをサポートしていますが、多くの場合、周囲のコンテキストを認識していないため、コンテキスト固有のエスケープルールを適用できません。
- それに加えて、ブラウザはエスケープまたはエンコーディングに関してわずかに異なる動作をすることができます。
- それとは別に、ロジックとプレゼンテーションを適切に分離していない成長したコードでHTMLフラグメントがデータベースに格納されていることがよくあります。特定の値が既にHTMLクリーンであるか、エスケープする必要があるかは、開発者にとって必ずしも明確ではありません。
XSSから保護するためのいくつかの簡単な方法（特にContent-Security-Policy）がありますが、これらは最新のブラウザーでのみ機能し、開発者が明示的に有効にする必要があり、多くの場合、コード（インラインスクリプトの削除など）。
それでも、適切な知識を持つ開発者がいて、XSSをすでに処理している最新のツールキットを使用してゼロから始めることができる場合は、正しく実行できる可能性があります。残念ながら、多くの場合、作業を続ける必要があるレガシーコードがあります。また、開発は通常、XSSをまったく認識していないか、すべての落とし穴を知らない開発者によって行われます。
そして、Web開発がコストと時間に非常に敏感な環境で行われている限り、これが変わる可能性は低いです。この環境の目的は、コードを短時間で、少ないコストで機能させることです。企業は通常、誰が最も安全な製品であるかではなく、機能と市場投入までの時間で競争します。また、XSS保護は現在、追加コストを意味するだけで、多くのマネージャーにとって明らかな利点はありません。
簡単そうですが難しい
まず第一に、攻撃面は巨大です。ユーザー入力をHTMLのどこにでも表示する場合は、XSSを処理する必要があります。静的HTMLで純粋に構築されていない限り、これはほとんどすべてのサイトが行うことです。
これと、XSSは扱いやすいように見えるかもしれないが、そうではないという事実を組み合わせてください。 OWASP XSS防止のチートシート は4 000語の長さです。そのすべてのテキストを収めるには、かなり大きなシートが必要です。
XSSはコンテキストによって動作が異なるため、複雑さが生じます。 JavaScriptに信頼できないデータを挿入する場合は1つ、属性値に挿入する場合は1つ、タグの間に挿入する場合は別のことを行う必要があります。OWASPは、すべて異なるルールを必要とする6つの異なるコンテキストと、いくつかのコンテキストをリストします。データを挿入しないでください。
一方、開発者は常にパナケアと銀の弾丸を探しています。彼らは、すべての困難な作業を単一のsanitize()関数に削除して、信頼できないデータを常に呼び出し、1日で呼び出すことができ、実際のプログラミングを続けることを望んでいます。しかし、そのような関数の多くはコーディングされていますが、どれも機能しません。
繰り返しますが、XSSは扱いやすいように見えるかもしれませんが、そうではありません。主な危険は、その文の最初の部分にあり、2番目の部分にはありません。考えられている単純さは、開発者が独自の自家製ソリューション-一般化、不完全なブラックリスト、および誤った仮定で満たされた独自のsanitize()関数-を作成することを奨励しています。 URLで_javascript:_を除外しましたが、_vbscript:_について考えましたか？または_javaSCripT :_？引用符をエンコードしましたが、実際に属性値を引用符で囲むことを覚えていますか？そして、文字エンコーディングはどうですか？
状況はSQLiとよく似ています。 addslashes、_mysql_escape_string_、_mysql_real_escape_string_のいずれの名前でも、すべてを管理する1つの衛生機能を探し求めていました。それは、実際に問題の複雑さを受け入れるのではなく、神々をなだめるための正しい関数を儀式的に呼び出すことで十分であると人々が考えるカルトカルトの安全保障です。
したがって、開発者がXSSに気付かずに気づいているのは危険ではありません。それは彼らが状況を制御下に置いたと彼らが思っているということです。
しかし、なぜそれが難しいのですか？
Webは、構造（HTML）、プレゼンテーション（CSS）、およびダイナミクス（JavaScript）がすべて、_.html_ファイルに入れる長いテキスト文字列に混在するという問題に悩まされています。つまり、あるコンテキストから別のコンテキストに移動するために通過できる多くの境界があるということです。
繰り返しますが、これはSQLiの場合と同じです。そこで、1つの文字列に命令とパラメータ値を混在させます。 SQLiを停止するには、2つを完全に分離する必要があり、決して混合しない、つまりパラメーター化されたクエリを使用する必要があることがわかりました。
XSSのソリューションも同様です。
- スクリプトをHTMLから分離します。
- HTMLのインラインスクリプトをオフにします。
2番目のパート コンテンツセキュリティポリシー を実行する簡単な方法を作成しました。 HTTPヘッダーを設定するだけです。しかし、最初の部分は難しいです。古いWebアプリの場合、スクリプトをHTMLから外科的に解きほぐすよりも、完全に書き直す方が簡単な場合があります。ですから、その魔法sanitize()に依存して最高のものを期待する方が簡単です。
しかし、朗報は、新しいアプリは多くの場合、可能な限りCSPを使用するというより厳密な原則に従って開発されており、ほとんどすべてのブラウザーでサポートされていることです。脆弱なサイトの割合を0％に下げるつもりはありませんが、今後60％から大幅に減少することを期待しています。
TL; DR：これはかなり長い怒りに変わりました。ここに多くの有用な情報があるかどうかわからない-明確な分析が必要な場合は、Steffen Ullrichsのすばらしい回答を読んでください。
セキュリティとXSSに関する私の意見のセット：
- プログラミングのルール：すべてを知ることはできません。遅かれ早かれ、間違いを犯すことになります。
- プログラマーのルール：プログラマーは1日12時間働きます：3は他のプログラマーとランダムに話し合っています、3は他のことを考えています、3は何をコーディングすべきかについて話し合っています、3プログラミングしています....プロジェクトは1日12時間行われますほとんどノンストッププログラミングの。
- XSSは単純です。そして、XSSを待っている入力はたくさんあります。
- セキュリティはまだ最後であり、ほとんどの場合、不十分であると見なされています。
あなたの同様の投稿への回答で述べたように（ SQLインジェクションは17歳です。なぜまだそこにあるのですか？ ）：
人間の愚かさの修正がないため、SQLiの一般的な修正はありません
開発者は時々怠惰または不注意になり、そのため開発者は開発中のアプリケーションをチェックしなくなります。
もう1つの一般的な理由は、開発者がセキュリティの問題があることを認識していないことです。彼らはセキュリティトレーニングを受けたことがないので、潜在的なセキュリティの脅威とそうでないものを知りません。そして、侵入テストが重要であることを理解していない会社にとって、このセキュリティ知識の欠如はそれ自体潜在的な脅威です。
SQLIやXSSなどの単純なセキュリティ問題は、会社がコードのレビューとテストに時間を費やすことを決定した場合にのみ修正されます。それまでは、すべてのWebサイトの65％がグローバルにXSS脆弱性の被害を受けています。
根の問題
Webは、安全な複数執筆者や豊富な対話を可能にするように設計されていません。 1990年代後半まで、プレゼンテーションからコンテンツを分離することについて誰も話しませんでした。その時点で、QWERTYキーボードのように、基本的に既存のシステムでは理由もなく立ち往生していました。誰も「ウェブを壊す」ことを望んでいなかったため、間違いがコピーされ、ブラウザを超えてブラウザに移植されました「素数ベクトル」。
悪化要因
2005年までは、特定のWebサイトで見た事実上すべてが、サイトを管理する人々によって作成または承認されていました。 「Web2.0」の動きが進み、人々がやり取りを要求したとき（少なくともコメントを追加してください！）、これらの機能を既存のサイトに追加するというプレッシャーは非常に大きかったです。 Webの人々は、彼らが何も知らないタスク、つまり安全な対話を達成するというボスの要求を満たすためにできることを行いました。そしてしばらくの間、おそらく長すぎて、彼らはそれを手放しました。何人の人が侵入者警報を購入しますbefore彼らは侵入されさえしましたか？
モダンタイムズ
CSPを使用すると、別のボールを落とすことによる危害の可能性が大幅に減少します。これは、名前を付けて保存、コピー、ヘッダーなしでキャッシュされるなどの理由で、検証と衛生管理を忘れてはならないという意味ではありませんが、2、3時間の労力でLOTをより安全にできることを意味します。はい、ヘッダーは長々としたもので、最初は紛らわしい形式ですが、グロックするのにかかる1〜2時間と、サイトのテストにかかる数時間を費やします。警告なしのサイレント実行（ルックアップ）を実行できるため、CSPのテストは本当に簡単です。
CSPを導入して従来の対策を講じた場合、ハードドライブの回転が停止するとこれらの古いブラウザーは停止し、私たちは皆、安全で幸せに暮らし続けます...
他の人は、人間が他の人間のために設計したシステムを取り巻く古典的な問題に触れました：現実は怠惰であり、時には愚かさと「なぜこれが私に起こるのでしょうか？」傲慢。
ああ、私のシステムのパッチに何時間費やしているか、さらに重要なことには、システムにパッチを適用するために割り当てられた時間/リソースを確保するために、管理者と戦う必要があります。
そして私はその点で幸運です：システムにパッチを適用するために組織の管理者と戦うことに苛立ちを感じていますが、多くの場所ではシステムを開発するために開発者を雇いますが、基本的な（そして退屈な）メンテナンスは投資に値するものであるとは考えていませんシステムが崩壊するまでシステムを停止させておき、違反の途中で修正を追跡する方が安い場合が多いのに、なぜシステムを維持するために技術者に毎月の保持料を支払うのでしょうか。
１ポンドの治療よりも優れた予防のオンスは、多くの場合、人々がペニーワイズで、ポンドバカであることに後退します。
とはいえ、システムを管理する人ができる最善のことは、確実な災害（または非災害）復旧計画を立てることです。コードバージョンを制御し、サーバーの展開設定をプロビジョニングスクリプトで自動化し、データベースのバックアップを作成します。そうすれば、システムがダウンした場合でも、退屈な災害ではなく、クリーンアップが迅速になります。
SDLCのコード実装フェーズでのSQLIやXSSなどの危険なセキュリティ脆弱性の正確な検出は、プログラミング言語のタイプに限定されます。
- このような脆弱性の静的分析は、PHPで最も広く行われています。
- 一部の動的メソッドは、テストまたは展開フェーズでファジー技術を採用しています。
残念ながら、どちらの方法も精度の点でまだかなり制限があります。さらに、XSSおよびSQLIの脆弱性はコンピューターアプリケーションを対象としており、ソフトウェア開発者には知られていない非常に多くの偽装形態で現れる可能性があります。したがって、それは愚かさの問題ではないと思います。安全なプログラミングのために開発者をすでに訓練している企業もあるが、これらの脆弱性を完全にブロックすることはできないと確信できる。そのような重大な攻撃を防ぐために必要なことはもっとたくさんあることに同意します。