| ||||||||||
| 前のページ 1 2 3 | ||||||||||
| SQLエラーハンドリング | ||||||||||
クラッカーがコード中でSQLインジェクションに弱い部分を見つけるのによく使う方法は、開発者自身がよく使うようなツールを利用するものです。例えば、失敗したSQLクエリを特定するために、以下のように失敗したクエリをエコーし、データベースエラーを表示してスクリプトを終了させる開発者がたくさんいます。 | ||||||||||
mysql_query($query) | ||||||||||
エラーを見つけるには非常に便利なのですが、本番のサーバに配置されて使用される場合、このコードには問題点がいくつか存在します。(エラーは様々なことが原因となって実際に起こるのです。)エラーが起こった時にユーザを混乱させるだけでなく、アプリケーションやサイトについて非常に多くの情報を漏洩してしまいます。 例えば、エンドユーザにテーブルの構造やフィールド、GETやPOSTのパラメータと値の対応がばれてしまい、より悪質なSQLインジェクション攻撃を許す手がかりを与えてしまうことになるのです。実際、SQLエラーは偶然のSQLインジェクションで起こります。エラーが起こると、よりトリッキーなクエリを作るのに役立つ情報を与えてしまうのです。 情報を漏らさないようにするのに一番よい方法は、SQLエラーをとても単純なSQLエラーハンドラで処理することです。 | ||||||||||
function sql_failure_handler($query, $error) { | ||||||||||
このハンドラの関数はクエリとデータベースが生成したエラーメッセージを受け取ると、その情報をもとにエラー文を作ります。エラー文はhtmlspecialchars()関数で処理されることですべての文字がHTMLとして解釈されないことが保障され、ログファイルにつけ加えられます。 次の処理はスクリプトがデバッグモードかそうでないかで決まります。デバッグモードの場合、エラーメッセージが返され開発者が読めるようにディスプレイに表示されます。しかし本番環境では、そのメッセージは一般的なメッセージに変更され、Webサイト閲覧者に問題の原因がわからないようにしています。 | ||||||||||
| 前のページ 1 2 3 | ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||

