ユーザーが投稿したデータ

多くの PHP のプログラムで最も脆弱な部分は、言語自体に起因するものではなく、 単にセキュリティを考慮して書かれていないコードの問題です。そのため、 指定したコードの部分の意味を常に時間をかけて吟味し、 予想外の変数が投稿された場合に有り得る損害を確かめる必要があります。

例1 危険な変数の使用

<?php
// ユーザーのホームディレクトリからファイルを削除します... または他の誰
// かのディレクトリかも?
unlink ($evil_var);

// 彼らのアクセスのログを書き込む.. または違うかも?
fputs ($fp, $evil_var);

// 何かちょっとしたことを実行.. または rm -rf *?
system ($evil_var);
exec ($evil_var);

?>
常に注意してコードをテストし、Webブラウザから投稿された全ての変数 について次のような点を確認してください。
  • このスクリプトは、意図したファイルのみを受け付けるか?
  • 例外的なまたは意図したもの以外のデータにより実行することが可能 か?
  • このスクリプトは意図した以外の方法で使用することが可能か?
  • このスクリプトは、悪い意味で他のスクリプトと組み合わせて使用す ることが可能か?
  • トランザクションは適切に記録されているか?

スクリプトを書いた後ではなく、書いている時にこれらの質問を適宜行う ことにより、セキュリティ改善のために不幸にして書き直しが必要になる ということを避けることができます。こうした考慮をまず行うことにより、 システムのセキュリティを保証できるわけではありませんが、改善の一助 にはなりえます。

入力データの出所や有効性、完全性を曖昧にする便利な設定を無効にし、 セキュリティを強化してください。暗黙的な変数の生成や未検証の入力は、 インジェクション攻撃やデータ操作といった脆弱性につながる可能性があります。

かつては register_globalsmagic_quotes (これらは両方、PHP 5.4.0 で削除されています) のような機能が、ユーザーの入力から自動的に変数を生成したり、 データを不完全な形でエスケープしたりすることで、セキュリティリスクを拡大することに貢献していました。 PHP ではそうしたリスクはなくなったものの、 入力処理の管理を誤れば、同様のリスクは依然として存在します。

error_reporting(E_ALL) を有効にし、未初期化の変数を検知し、入力を検証してください。 型安全を強制し、意図しない型変換を防止し、セキュリティ全体を改善するために、 strict モード (PHP 7 で導入された declare(strict_types=1)) を利用してください。