私はC#.netで書かれたeコマースWebサイト(CMSを使用せず、非常に多くのコードを使用)で働いていますが、セキュリティは長い間優先されていませんでした。現在の私の使命は、XSS違反を見つけて修正することです。レンダリングされたHTMLに直接書き込まれたフィルターされていないデータがたくさんあります。
すべてのページを読み取る必要なくコードを修正するための最善の戦略は何ですか?
私は次の4つのステップのプログラムを提案します。このプログラムでは、大きな問題に取り組むときに、最小限の保護を提供するために、まずぶら下がっている果物を選びます。
次のHTTP応答ヘッダーを設定すると、XSS保護機能が組み込まれたブラウザーがオンになります。
_X-XSS-Protection: 1; mode=block
_
これは決して防水ではなく、反射されたXSSに対してのみ役立ちますが、それは何かです。 IE(驚き、驚き)の一部の古いバージョンには、実際には事態を悪化させる可能性があるバグのあるフィルターがあるため、一部のユーザーエージェントを除外する必要がある場合があります。
アプリでインラインJavaScriptを使用しない場合は、 [〜#〜] csp [〜#〜] が役立ちます。 _script-src 'self'
_を設定すると、(a)スクリプトタグが自分のドメインのスクリプトのみを含むように制限され、(b)インラインスクリプトが無効になります。したがって、攻撃者が<img onerror="alert('XSS')">
を挿入できたとしても、ブラウザはスクリプトを実行しません。ヘッダーに使用する値を自分の用途に合わせて調整する必要がありますが、リンクされたMDNリソースがそれを支援するはずです。
しかし、これも防水ではありません。 CSPを実装していないブラウザーを使用するユーザーを支援することは何もありません( ここ を参照)。また、ソースがインラインスクリプトで散らかされている場合は、クリーンアップするか、CSPの使用を控えるかを選択する必要があります。
John W はコメントで良い提案をしています:
また、これは.NETであるため、非常に迅速かつ簡単な変更でオンにすることができます ASP.NET Request Validation これにより、さまざまなXSS攻撃をキャッチできます(ただし、100%ではありません)。
別の言語で作業している場合は、代わりに Webアプリケーションファイアウォール の使用を検討してください( xehpuk で推奨)。 WAFの設定がいかに簡単かは、保護するアプリケーションによって異なります。フィルタリングを本質的に困難にすることをしている場合(たとえば、GETでHTMLを渡すか、POSTパラメータ))、フィルタリングを構成する価値はありません。
しかし、繰り返しになりますが、WAFは役立つかもしれませんが、それでも防水ではありません。
自動化されたXSSスキャナーを使用して、既存の脆弱性を見つけ、修正します。補足として、独自の手動テストを実行できます。これは、見つけやすい脆弱性の修正に貴重な時間を集中させるのに役立ち、初期段階で最も大きな効果を発揮します。
しかし、これは3回目の防水ではありません。どれだけスキャンしてテストしても、何かを見落とすことになります。したがって、残念ながら、このリストにはポイント#4があります...
はい、「すべてのページを読む必要があります」。ソースを確認し、XSSの問題を適切に処理するある種のフレームワークまたはテンプレートライブラリを使用して、データを出力するすべてのコードを書き直します。 (おそらくフレームワークを選択し、#3ですでに行った修正のためにそれを使い始める必要があります。)
これには多くの時間がかかり、a **の面倒ですが、実行する必要があります。明るい面からそれを見てください-あなたがそれにいる間、あなたはいくつかの追加のリファクタリングを行う機会があります。最終的には、セキュリティの問題を解決しただけでなく、より優れたコードベースも得られます。
簡単な解決策はありません。一番下に「簡単な」解決策の提案がありますが、ここで説明する多くの警告があることを覚えておいてください。しかし、最初に、全体像から始めて、私たちの道を進んでいきましょう。
私の経験では(多くのレガシーシステムで作業してきた)、「セキュリティは長い間優先されていなかった」ということは、システムに隠れているセキュリティ問題がいくつもある可能性があることを意味します。 XSSは1つの問題に過ぎないと私は確信しています。だから、誰かがすでにこれらの上にいることを知らない限り、私は自分自身を心配します:
数値は優先順位を意味するものではありません。これらはすべて最優先事項です。
開始点
最も重要なことは、これを「制度的に」修正することです。これは最も難しい作業ですが、最も重要なことでもあります。すべてのXSS脆弱性を修正するために数週間を費やしても、セキュリティが最下位の優先事項であり続ける場合、問題は、次に開発者がフィルターされていないデータをブラウザーに出力したときに再び発生します。
XSSの脆弱性に対する最善の保護策は、セキュリティを真剣に考えることを知っている開発者に、XSSエスケープを適切に処理するテンプレートエンジンを使用してもらうことです。覚えておくべき重要な点は、XSSでは入力ではなく出力でフィルタリングする必要があるということです。これを一方向の問題として捉えるのは簡単です。「ユーザーデータが入力に入ったときにユーザーデータをクリーンアップすれば、問題ありません」。しかし、これはすべての攻撃ベクトル、特にSQLi経由で追加されたXSSから保護するわけではありません。ただし一般的に、XSS保護が開発者が毎回行うことを忘れてはならないものである場合、それは忘れられてしまいます。そのため、最善の策は、XSS保護をシステムに組み込むことです。これがテンプレートエンジンの出番です。すべての有能なテンプレートシステムは、デフォルトで自動的にXSSフィルタリングを適用し、XSSのフィルターをしない必要があるかどうかを明確に通知する必要があります。
特にXSSの脆弱性に対処するためにテンプレートエンジンを含めるようにシステムをリファクタリングすることはおそらくないでしょうが、これを可能にする制度上の問題を修正するために何かをしなければ、これを理解することも重要です。そもそも問題が発生するので、問題が再発するだけで、これを修正するのに数週間は無駄になります。
最初の実用的な手順
@アンダースは彼の答えにいくつかの素晴らしい出発点を持っています。 CSPとXSSヘッダーはどちらも同じように機能します。つまり、ブラウザーにXSS保護クライアント側を有効にするように指示します。 (@Andersが述べたように)これらはブラウザに依存し、特に古いブラウザではまったくサポートされない場合があることに注意してください。特に、IEによるCSPのサポートは、IE11( https://stackoverflow.com/questions/42937146/content-security-policy-does-not-work-in-internet)までさえもごくわずかです-エクスプローラ-11 )
その結果、これらの手順は適切な開始点ですが、主要なセキュリティとしてこれらの手順に絶対に依存することはできません。問題を解決する必要があります。優れた自動スキャンツールを入手することは、間違いなく開始する最良の方法です。それはあなたにいくつかの即時のアクションアイテムを取得します。
部分的なソリューション
あなたが持っているかもしれないもう一つのオプションは、アプリケーションの全面的にXSSフィルタリングを置くことです。私は通常これをお勧めしませんが、あなたのための最善の策は多層的な応答だと思います。ここでの考え方は、クライアントから受信するすべてのデータ(URLデータ、POSTデータ、Cookie、REQUESTヘッダーなど)をチェックするアプリケーションのブートストラッププロセスにコードを追加することです。次に、いくつかのフィルタリングを実行して一般的なXSSペイロードを検出し、見つかった場合はすべて一緒に要求を拒否します。
ブラックリストフィルタリングの問題は、非常に信頼できない可能性があることです。 OWASP XSSフィルター回避チートシート を読むと、XSS脆弱性を確実にフィルターで除外するのがいかに難しいかがわかります。ただし、これはすべてのリクエストを保護するための迅速な方法であるため、ケースによっては価値がある場合があります。ただし、注意すべき重要な問題の1つは、これによりWYSIWYGエディターが機能しなくなることです。それはあなたにとって問題かもしれませんし、そうでないかもしれません。