あのCGIがクラックされてしまった理由：スパム時代のサニタイズ開発手法（1/2 ページ）

Perlをはじめとする言語では、フォームとパイプ処理に十分な注意をしなければならない。その理由には、Webからローカルリソースへのアクセスを極力制限する必要があるからだ。

[平田豊，ITmedia]

　オンライン・ムック「スパム時代のサニタイズ開発手法」の前回「Perlは悪くない――CGIセキュリティホールの落とし穴」は、WebサーバにおけるCGIスクリプトの仕組みについて解説した。日ごろ見掛けるニュース情報を読み解くために、セキュリティーホールが生まれてしまう基本情報として理解しておきたい。

CGIスクリプトのセキュリティ

　CGI（Common Gateway Interface）スクリプトは、「Perlは悪くない――CGIセキュリティホールの落とし穴」でも触れたように、Perl言語で作られることが多い。しかし、それはPerlというスクリプト言語がCGI作成のために手軽だから、という事情が大きい。

　Perl（Practical Extraction and Report Language）は、ラリー・ウォール氏が開発したスクリプト言語の実行環境ソフトウェアであり、テキスト処理に向いている。また歴史も古いため、インターネット上で利用率が高く、Perlで動作するモジュールも多数フリーウェアとして公開されている。このため、Perlを使って手軽にネットワークアプリケーションを構築することが可能なのだ。

　そうとはいえ、CGIが流行りだした当時、そのキッカケとなったスクリプトがPerlで作られていたから……、という理由が大きいかもしれない。当時はC言語でも、CGIスクリプトが多く作られていたこともあり、筆者もC言語でコーディングした経験がある。しかし、C言語では文字列処理が比較的柔軟性に欠けるため、CGIスクリプトをプログラミングするには不向きであると感じた。

　CGIスクリプトではブラウザ上にユーザから入力されたデータを受け取り、サーバ上で処理を行い、その結果をブラウザ側へ返すのが主な処理となる。

　この一連の処理の流れでは、データの扱いが想定されたもので動作すればよいが、思わぬ文字列を入力された場合、セキュリティホール発覚となる可能性があるのだ。

　このような問題が後を絶たないのは、クライアントからどのような文字列（データ）が渡されてくるか、パターンが無限大にあって特定困難だからだ。サーバ側の開発者もソフトウェアの評価において、すべてのパターンについてテストができているわけではない。このため、想定されたテストから漏れていたパターンについて、悪意あるユーザーが気付いてしまうとセキュリティホールとして明るみに出るわけだ。

ファイルパスの盲点

　概して、サーバ上のファイルにアクセスする処理そのものは、十分に注意しなければならない。

　ここではセキュリティホールのあるCGIスクリプトのサンプルとして、サーバ側でファイルをオープンするプログラムを示す（関連リンク）。

• index.html
• test.cgi

　関連リンク先のCGIスクリプトは、ユーザーが入力したファイルをサーバ側で読み取り、表示させるというものだ。CGIスクリプト側では、スクリプト本体が特定のディレクトリを基点とし、data/ディレクトリ下のファイルを読み込む。リスト1にファイルを読み込んでいる個所のコード（スクリプト）を示した。