なぜPHPアプリにセキュリティホールが多いのか?

大垣さんの連載がはじまったようです。

なぜPHPアプリにセキュリティホールが多いのか?

連載の一回目は、以下のような内容でした。

  • CVEに登録される脆弱性全体のうち、PHP AP関連は半数弱を占める。
  • PHP APの脆弱性の約4割は、Remote File Inclusionという深刻なもの。ただし、register_globals設定がOnの環境でのみ脆弱なものが多い。
  • つまり、register_globalsが、PHP APの脆弱性件数を底上げしている面がある。

今日の日記では、その記事を読んで、少し調べたこと、思ったことなどを書きます。

Remote File Inclusionについて

register_globalsがOnだからといって、Remote File Inclusionが可能になるなんて、一体どんなコード書いてるのよ? と思って、CVEで挙げられていたいくつかのAPを調べてみました。

それで判ったのは、ライブラリを狙う攻撃が多いことです。ライブラリとは、他のプログラムから呼び出されるだけで、通常はクライアントから直接リクエストを受けないプログラムを指しています。攻撃者は、そのライブラリに対して直接リクエストを送るのです。

以下はライブラリの先頭部分のコードの例です。多く狙われるのは、下記のように、ライブラリから他のプログラムを呼び出している文です。

<?php
require ($module_dir. 'hoge.class.php');

$module_dirは、通常はライブラリの呼び出し元から、設定ファイルなどに定義された固定の値が与えられます。しかし、ライブラリに対して直接アクセスが可能であり、かつregister_globalsがOnの場合は事情が異なります。

その場合、攻撃者はライブラリに直接アクセスし、GETパラメータなどで変数の値を自由に制御できてしまうのです。その結果は、「リモートの攻撃者による任意のコマンド実行」です。

APの利用側でできる対策は、以下の3つです。

1. ライブラリへの直接アクセスを禁止
2. register_globalsをOffにする
3. require文での外部URL指定を禁止
 (allow_url_fopenの設定)

上記3つはいずれもAP利用側の設定の話です。APの開発者サイドでできる対策は、大垣さんの記事に書かれているように、「register_globalsがOnの環境では動作しないAPを作成する」くらいなのでしょう。

なぜPHPには脆弱性が多いのか

記事中に記載されているCVEの脆弱性件数を見ると、上記のRemote File Inclusionを除いても、PHP AP関連は相対的に多いようです。CVEを見ると、SQLインジェクションXSS、etc. が並んでいます。

これには、以下のような事情があると思います。

1. そもそもPHP APの数が多い
 ⇒ 確たる統計はありませんが
2. ビギナーの開発者が多い
 ⇒ とっつきやすさゆえに?
3. フレームワークなど基盤の立ち遅れ
 ⇒ 後述します
4. 言語自体の問題
 ⇒ これも後述します

3のフレームワークの問題は、XSSでは適切なテンプレートエンジン、SQLインジェクションではPrepared Statementを備えたDB抽象化機能などの、整備・普及が遅れていたということを指しています。

4の言語自体の問題とは、まさにRemote File Inclusionで見たような問題です。つまり、APレベルでライブラリへの直接アクセスを禁止できない、register_globalsのような危険な設定が可能、require文のデフォルト動作が外部URL指定を許している、などの問題です。

この他にも、addslashesやstrip_tags関数などのマヤカシ関数や、NULバイトセーフでない関数の存在、permissiveなセッション管理方式、i18nの問題(文字列処理)など、問題は色々と挙げられると思います。

****

以上は私の私見です。大垣さんが今後の連載記事でどんなことを書いてくれるのか楽しみです。