ガイドの冒頭で、データ フィルタリングは、あらゆる言語およびプラットフォームにおける WEB アプリケーション セキュリティの基礎であると述べました。これには、アプリケーションへのデータ入力とアプリケーションからのデータ出力の検証が含まれます。優れたソフトウェア設計は、開発者が次のことを行うのに役立ちます。
データ フィルタリングが回避できないことを確認する、
違法な情報が正当な情報に影響を与えないことを確認する、
識別するデータのソース。
データ フィルタリングをバイパスできないようにする方法についてはさまざまな見解があり、そのうちの 2 つは他の見解よりも一般的であり、より高いレベルの保証を提供します。
スケジュール方法
この方法は、単一の PHP スクリプト (URL 経由) でスケジュールされます。他の操作は、必要に応じて include または require を使用して含められます。このアプローチでは通常、各 URL にディスパッチ用の個別の GET 変数を渡す必要があります。この GET 変数は、スクリプト名を置き換えるより単純化された設計と考えることができます。例:
http://a.org/dispatch.php?task=PRint_formdispatch.php は唯一のルート ファイル (ドキュメント ルート) です。これにより、開発者は 2 つの非常に重要な作業を行うことができます:
dispatch.php の先頭にいくつかのグローバル セキュリティ処理を実装し、これらの処理がバイパスできないようにします。
特に一部の特殊な目的の制御フロー操作において、データ フィルタリングを実行する必要がある場所を簡単に判断できます。
dispatch.php スクリプトの詳細については、次の例を参照してください:
これが公的にアクセス可能な唯一の PHP スクリプトである場合は、次のことを確認してください。このプログラムの設計により、最初のグローバル セキュリティ処理がバイパスできないことが保証されているということです。また、開発者は特定のタスクの制御フローを簡単に確認できます。たとえば、コード全体を閲覧しなくても簡単にわかります。$form_valid が true の場合、end.inc は process.inc がインクルードされる前であり、false に初期化されたばかりであるため、ユーザーに表示される唯一のものです。 process.inc の内部ロジックによって true に設定されると判断できます。それ以外の場合は、フォームが再度表示されます (関連するエラー メッセージが表示される可能性があります)。
注意
(dispatch.php ではなく)index.php などのディレクトリ指定のファイルを使用する場合は、http://a.org/?task=print_form のような URL アドレスを使用できます。
ApacheForceType リダイレクトまたは mod_rewrite を使用して、URL アドレス http://a.org/app/print-form を調整することもできます。
含まれるメソッド
もう 1 つの方法は、すべてのセキュリティ処理を担当する単一のモジュールを使用することです。このモジュールは、すべてのパブリック PHP スクリプトの先頭 (または最先頭) に含まれています。次のスクリプトを参照してください security.inc
[/code]
次のコードは、$_POST['num'] が整数であることを確認します。
[code]