汚染検査

汚染チェックは、 Perl ^{[ 1 ]}、Ruby ^{[ 2 ]}、Ballerina ^{[ 3 ]}などの一部のプログラミング言語の機能で、悪意のあるユーザーがホストコンピュータ上でコマンドを実行するのを防ぐことでセキュリティを強化するように設計されています。汚染チェックは、主にSQL インジェクションやバッファオーバーフロー攻撃などの手法で攻撃される Web サイトに関連する特定のセキュリティリスクを強調します。

汚染チェックの基本的な考え方は、外部ユーザーによって変更可能な変数（例えば、Webフォームのフィールドで設定される変数）はすべて潜在的なセキュリティリスクとなるというものです。その変数が別の変数を設定する式で使用されている場合、その別の変数も疑わしいと判断されます。汚染チェックツールは、変数ごとにチェックを進め、外部入力によって影響を受ける可能性のある変数のリストを作成します。これらの変数のいずれかが危険なコマンド（SQLデータベースやホストコンピュータのオペレーティングシステムへの直接コマンドなど）の実行に使用されている場合、汚染チェッカーはプログラムが潜在的に危険な汚染変数を使用していることを警告します。コンピュータプログラマは、危険な入力に対して安全な対策を講じるようにプログラムを再設計することができます。

汚染チェックは、非干渉の完全な検証、またはより一般的な安全な情報フローの概念に対する保守的な近似と見なすことができます。^{[ 4 ]}システム内の情報フローは、そのシステムの単一の実行トレースを調べることによって検証することはできないため、^{[ 5 ]}汚染分析の結果は、それが適用されるシステムの情報フロー特性に関する近似的な情報を反映することになります。^{[ 6 ]}

以下の危険なPerlコードは、変数の値をチェックしないことで、大規模なSQLインジェクションの$name脆弱性を引き起こします。

#!/usr/bin/env perl my $name = $cgi -> param ( "name" ); # ブラウザから名前を取得... $dbh -> { TaintIn } = 1 ; $dbh -> execute ( "SELECT * FROM users WHERE name = '$name';" ); # SQLクエリを実行

汚染チェックが有効になっている場合、汚染された変数が SQL クエリで使用されているため、Perl はコマンドの実行を拒否し、エラー メッセージを表示して終了します。汚染チェックが有効になっていない場合、ユーザーは と入力することでfoo'; DROP TABLE users --、データベース テーブル全体を削除するコマンドを実行できてしまいます。より安全な方法は、$name の汚染された値を SQL文字列リテラルにエンコードし、その結果を SQL クエリで使用することです。これにより、 に埋め込まれた危険なコマンドが評価されないことが保証されます。これを実現するもう 1 つの方法は、プリペアド ステートメント$nameを使用して、クエリのすべての変数入力をサニタイズすることです。

注意すべき点の1つは、Perl DBIではTaintIn、データベースハンドルの属性を設定するとともに、 SQL文字列をチェックするための汚染モードを有効にする必要があることです。^{[ 7 ]}

Perlは少なくともバージョン3.0（1989年リリース）からsetuidスクリプトの汚染をサポートしていましたが^{[ 8 ]} 、汚染を単一のランタイムに統合するスイッチ^{[ 1 ]}が導入されたのはバージョン5.0（1994年リリース）になってからでした^{[ 8 ]}。-T

1996年、NetscapeはNetscape Navigator 3でJavaScriptのデータ汚染機能を実装しました。^{[ 9 ]}しかし、サポートは実験的なものと見なされていたため、出荷時には無効になっており（有効化するにはユーザーの介入が必要）、ページ作成者はその恩恵を受けるためにスクリプトを修正する必要がありました。他のブラウザベンダーは、この機能を実装しませんでした。

• CGIスクリプトの汚染チェックに関するW3Cのガイドライン
• perlsec - Perlセキュリティに関するドキュメント