各入力を明示的にサニタイズする必要がないように、XSS 攻撃を可能な限り集中的に防止する必要があります。
私の質問は、URL/リクエスト処理レベルですべての入力をサニタイズするか、提供する前に入力をエンコード/サニタイズするか、またはプレゼンテーション レベル (出力サニタイズ) でサニタイズする方が良いですか? どちらが優れているのか、その理由は?
各入力を明示的にサニタイズする必要がないように、XSS 攻撃を可能な限り集中的に防止する必要があります。
私の質問は、URL/リクエスト処理レベルですべての入力をサニタイズするか、提供する前に入力をエンコード/サニタイズするか、またはプレゼンテーション レベル (出力サニタイズ) でサニタイズする方が良いですか? どちらが優れているのか、その理由は?
注意する必要がある2つの領域があります。
特にSQLを含む、任意の言語のスクリプトの一部として入力を使用する場所。SQLの特定のケースでは、物事を処理するための唯一の推奨される方法は、パラメーター化されたクエリを使用することです(これにより、エスケープされていないコンテンツがデータベースに存在しますが、文字列と同じようになります。これが理想的です)。SQL文字列に直接置き換える前の文字の魔法の引用符を含むものはすべて劣っています(間違えやすいため)。パラメータ化されたクエリで実行できないことは、SQLインジェクションに対して保護されたサービスがユーザーに指定させてはならないことです。
出力として入力されたものを提示する場所。入力のソースは、直接(Cookie経由を含む)または間接(データベースまたはファイル経由)の場合があります。この場合、デフォルトのアプローチは、ユーザーに表示されるテキストを入力されたテキストにすることです。<
実際に引用する必要のある文字はとだけなので、正しく実装するのは非常に簡単です。&
すべてをラップし<pre>
て表示することができます。
しかし、それだけでは不十分なことがよくあります。たとえば、ユーザーが何らかのフォーマットを実行できるようにしたい場合があります。これは、間違いを犯しやすい場所です。この場合の最も簡単なアプローチは、入力を解析し、すべてのフォーマット命令を検出することです。他のすべては適切に引用する必要があります。フォーマットされたバージョンを追加の列としてデータベースに追加で保存して、ユーザーに返すときに多くの作業を行う必要がないようにする必要がありますが、ユーザーが入力した元のバージョンも保存して、検索できるようにする必要があります。 。それらを混同しないでください!本当に!アプリケーションを監査して、これが正しく行われていることを完全に確認します(または、さらに良いことに、他の誰かに監査を依頼します)。
ただし、SQLに注意することに関するすべてが引き続き適用され、決して安全ではない多くのHTMLタグ(たとえば、<script>
)<object>
と属性(たとえば)があります。onclick
あなたは仕事をするための特定のパッケージについてのアドバイスを探していましたか?その場合、本当に言語を選択する必要があります。上記のアドバイスはすべて完全に言語に依存しません。アドオンパッケージ/ライブラリを使用すると、上記の手順の多くを実際に非常に簡単にすることができますが、それでも絶対に注意する必要があります。