第6章 入力・注入対策
SQL注入: #2 設定における対策
エラーメッセージの抑制
故意にデータベース(またはドライバ)エラーを起こすことで、HTMLページに出力されるエラーメッセージの内容から様々な情報を取得されるおそれがある。
例えば、次のような内容である。：
- 入力データ中のシングルクォート「'」等の特殊記号に対してアプリケーションが無防備であること。すなわちSQL注入攻撃を許すおそれがある
例えば、OS:Windwos Webサーバ：IIS DB：MS SQL Server の例
Microsoft OLE DB Provider for ODBC Drivers(0x80040E14)
[MicroSoft][ODBC SQL Server Driver][SQL Server]文字列 " and
password=''の前で引用符が閉じていません。 - 攻撃者が送り込んだ文字列がうまくSQL文の中に組込めたか否か。
このような情報を見ながら、攻撃者はSQL注入の試行錯誤を行う - DBテーブル名、カラム名、検索条件、演算式の途中の値等。
攻撃者が攻撃文字列を用意する際の具体的な手がかりとなる - データベーステーブルの内容の一部。これは上記(3)の特殊なケースである。演算式の一部としてデータベーステーブルの内容を取り出させておき、わざとエラーを起こさせることによって値をエラーメッセージ中に表示させるものである
このように、ユーザに不必要なエラーメッセージを表示することは、SQL注入攻撃の足がかりとなるのみでなく、エラーメッセージそのものにデータベーステーブルの内容の一部を表示させ、情報が盗み出されるおそれがある。
そのため、不必要なエラーメッセージがHTMLページに出力されないよう、処理系の設定およびアプリケーションプログラミングを行うべきである。
(1) アプリケーション実行環境における対策例
アプリケーション実行環境によって、エラーメッセージの出力をコードに記述して制御する場合と環境設定ファイルにより制御を行う場合がある。例えば、PHPは設定ファイルにエラーメッセージの出力に対して出力方法や出力レベル等の設定を記述することができる。
PHPにおけるエラーメッセージ設定
php.iniファイル内のディレクティブを設定する。
■画面へのエラーメッセージ出力設定
- display_errors=Off
- ：エラーをHTMLとして画面出力するかどうかを定義する
- display_startup_errors=Off
- ：PHPの初期動作時点で起きるエラーをHTMLとして画面出力するかどうかを定義する。display_errorsをOffにするならこちらもOffにするべきである。
■エラーレベル設定
- error_reporting=E_ALL：
- E_ALL
- ：すべてのエラーメッセージを出力する
- E_ERROR
- ：致命的な実行時のエラーを出力する
- E_RECOVERABLE_ERROR
- ：回復可能な実行時のエラーを出力する
- E_WARNING
- ：実行時の警告を出力する
- E_PARSE
- ：コンパイル時の構文解析エラーを出力する
- E_NOTICE
- ：実行時の情報を出力する
- E_STRICT
- ：コード互換性のための情報を出力する
- E_CORE_ERROR
- ：PHPの初期動作時点で起きる致命的なエラーを出力する
- E_CORE_WARNING
- ：PHPの初期動作時点で起きる警告を出力する
- E_COMPILE_ERROR
- ：致命的なコンパイル時のエラーを出力する
- E_COMPILE_WARNING
- ：コンパイル時の警告を出力する
- E_USER_ERROR
- ：ユーザを用意したエラーを出力する
- E_USER_WARNING
- ：ユーザが用意した警告を出力する
- E_USER_NOTICE
- ：ユーザが用意した情報を出力する
■ログ出力設定
- log_errors=on
- ：エラーをログ出力するかしないかの設定
- log_errors_max_len=1024
- ：ログへのエラー出力量の最大値の設定
- error_log=[filename | syslog]
- ：エラーログの出力先の設定
(2) Webサーバにおける設定例
Webサーバにおけるエラーメッセージ出力に関する設定は、設定内容を変更する場合と設定ファイルにより出力方法や出力レベルを設定する場合がある。例えば、IISにおいては、標準のエラーメッセージ表示では詳細な情報が表示されてしまうのでカスタムのエラーページを用意することが可能である。また、Apacheにおいては設定ファイルにおいて出力方法や出力レベルを設定することが可能である。
Apacheにおける設定 - Apache 2.0.59の場合
- エラーログ設定
- ：ErrorLog logs/error.log
- ログレベル設定
- ：LogLevel warn
debug, info, notice, warn, error, crit, alert, emerg - サーババージョン表示設定
- ：ServerTokens Full
Full | OS | Minor | Minimal | Major | Prod - エラーメッセージ出力時のフッタ表示設定
- ：ServerSignature On
On | Off | EMail
独自エラーページの用意する。
(3) RDBMSにおける設定例
RDEBMSにおいてもエラーメッセージの出力先や出力レベルを任意に設定することが可能である。
DBアクセスに対するエラーの標準出力は避け、ログファイルに出力するように設定を行ったり、ユーザの個人情報、クレジットカード情報などを扱う際にはエラー出力を行うこと自体を禁止するように設定を行う必要がある。例えばPostgreSQLでは以下のような設定が可能である。
以下のディレクティブをpostgresql.confに記述する。
SILENT_MODE (boolean) default : off
silent_modeは、標準出力・標準エラー出力にログメッセージを出力するかしないかを設定します。syslogへの出力をしていない場合、一切のログ確認ができなくなります。
SYSLOG (整数) default : 0
syslogは、ログ出力先を制御する。
0 ：標準出力と標準エラー出力に出力する。OSのsyslogへの出力は無効です。
1 ：OSのsyslogと標準出力・標準エラー出力に出力する。
2 ：OSのsyslogにのみ出力する。
（一部のメッセージは標準出力・標準エラー出力にも出力される）
データベース接続アカウントの権限を最小限に
データベース接続アカウントに対して、不必要な命令まで実行可能な権限を与えている場合は、不正利用の被害が深刻化するおそれがある。
そのため、データベース接続アカウントには、必要な命令のみ実行可能な最小限の権限を与えるべきである。可能ならば、異なる権限のアカウントを複数用意し、データ参照系画面(selectのみ)とデータ更新系画面(insert、updateのみ)で、アカウントを使い分けるべきである。
危険なストアドプロシージャの停止
Microsoft SQL Server では、xp_cmdshellを使用してSQLからWindowsコマンドが実行可能であり、悪用されるとサーバ乗っ取りのおそれがある。
侵害例：
'; exec master..xp_cmdshell 'nc -l -p 666 -e cmd.exe'--
'; exec master..xp_cmdshell 'echo 1行目 >> bad.vbs'-- '; exec master..xp_cmdshell 'echo 2行目 >> bad.vbs'-- '; exec master..xp_cmdshell 'echo 3行目 >> bad.vbs'-- ： '; exec master..xp_cmdshell 'bad.vbs'--
'; exec master..xp_cmdshell 'del c:\*.* /F/Q/S'--
このため、xp_cmdshell をはじめとした悪用されると危険なストアドプロシージャは停止させるべきである。
