codeなにがし::なぜ開発者は脆弱性のあるコードを量産してしまうのか

なぜ開発者は脆弱性のあるコードを量産してしまうのか: okdt

ソースコードID：　317
登録日時：　2007/09/11 11:43
最終更新日時：　2007/10/15 10:26
アクセス数：　2008
タグ：　セキュリティ xss sqlインジェクションサニタイズ言うな

0 users

説明

XSSやSQLインジェクションなどの危険なデータによる被害を防ぐために、どの時点で何をすべきか。

ソースコード

履歴表示コピペ用

XSSはツメの問題というよりは、構造設計の問題だと考えると設計段階でかなりの程度メンテナンシビリティの高い安全策構築が可能になります。

１．XSSはデータのリスクというよりは、ブラウザ表示のリスクであることを認識することが必要です。

２．出力を、変数のまま、内容をフィルタリングできないechoなどの安直な関数を使用するところに大きな問題があります。

３．入力値の検証（数字か、英字か、全角か、など）はある程度有意義ですが、それはXSS対策として完結するものではありません。"javascript:"という文字列を英字を使わずにデータとして格納させる方法はたくさんあります。

４．システムへの入力のルートはきっと予想以上にたくさんあります。フォーム、cockie、環境変数、データベース、RSSフィード、アドレスバー、ブラウザのaddonでさえ何か影響するかもしれません。

ここでの論点は、考えられる入力ルート全部に対し、いちいち完全にフィルタリングすることを目指す設計は得策ではないということです。

そこで、構造上の対策は、ブラウザに出力する関数を作成し、出力をその関数のみに委ねることです。echoなんぞをあちこちで使ってはいけません。HTML出力を許可するなどの例外的な出力バリエーションがあるなら、モードを定義すれば良いでしょう。

基本的に、ホワイトリストを作成し、心配なら一部ブラックリストを列挙します。バリエーションがあるならそれもここでコントロールします。ホワイトリストを通過したものの、ブラックリストに引っかかったものがあれば、必ずログに残し、後日ホワイトリストをメンテナンスします。

本題の「なぜ開発者は脆弱性のあるコードを量産してしまうのか」ですが、それは、脆弱でないコードにするために何かするにしても、どのタイミングで、どんな処理をすべきかを理解していないからだと思います。

sanitize(サニタイズ)は「受け入れる段階で」いわば太陽滅菌してできるだけリスクを減らすことを目指すという思想である（つまり上記のとおりそれには限界があります）のに対し、validationは「実際に利用する段階で」、それぞれのリスクを回避または軽減することによってデータを有効なもの（valid）にするという考え方です。

SQLインジェクション対策でも同じ考え方を適用できます。