116

MySQLデータベースにデータを格納する小さな PHP アプリケーションがあります。現在、ユーザー名とパスワードは PHP コードにハードコーディングされています。たとえば、コードがリポジトリでも利用できるため、私があまり好きではない状況です。

私が持っている最良のアイデアは、データをコードから構成ファイル (リポジトリから除外) に移動し、何らかの方法でエンコードすることです。そのため、直接読み取りはできません (難読化)。問題を解決するためのより良い使いやすい方法はありますか?

$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
if (!$link) { 
    die('Could not connect: ' . mysql_error());
}
mysql_select_db('mydb');

範囲: 堅牢でありながら使いやすいソリューションを確立したいと考えています。合理的なセキュリティが必要ですが、ここでは機密性の高いデータを扱っていません。

注: 関数の使用は推奨されなくなりました。Stack mysql_connectOverflow の質問Why should I use mysql_ functions in PHP?を参照してください。*。コード例を変更することもできましたが、一部のコメントがこれを参照しているため、変更しませんでした。ただし、質問の本来の性質は有効なままです。

4

9 に答える 9

69

あなたが言ったように、最も簡単な方法は、構成ファイルを使用することです。

多くのフレームワーク ( Zend、CakePHP、Kohanaweb.configなど) がこれを使用しており、最も一般的な方法です (ファイルを含むASP.NET などの非 PHP 環境でも)。これにより、サイトのファイルをコピーするだけで、環境から環境へと構成値をコピーすることもできます。これは、サーバー設定の環境変数 (非常にすぐに失われて忘れられる可能性がある) に依存するよりも利点があります。

パスワードは誰でもアクセスできるファイルではないため、パスワードの難読化について心配する必要はありません。これが意味することは、a) Web サーバーに構成ファイルを提供しないように指示する ( IISは既にweb.configファイルでこれを行っており、コンテンツの代わりに HTTP 404.8 ステータスを提供している) か、b) 提供されている Web の外に移動することです。ディレクトリ。誰かがあなたの設定ファイルを見ることができたら、それはあなたのソースコードにあるよりも悪いことです.

また、構成ファイルのベース (空/デフォルト) バージョンを用意し、それを環境ごとに分けて、運用、開発、およびテスト プラットフォーム用に異なる構成ファイルを作成できるようにすることもお勧めします。

環境変数は、これらの環境を区別する最も一般的な方法です。以下のコードのようになります。

// Check if it's been set by the web server
if (!empty($_ENV['ENVIRONMENT'])) {
    // Copy from web server to PHP constant
    define('ENVIRONMENT', $_ENV['ENVIRONMENT']);
}

if (!defined('ENVIRONMENT')) {
    // Default to development
    define('ENVIRONMENT', 'development');
}

// Load in default configuration values
require_once 'config.default.php';

// Load in the overridden configuration file for this environment
require_once 'config.' . ENVIRONMENT . '.php';

もう 1 つの非常に一般的な方法は、XML 構成ファイルを使用し、必要な値だけを読み込むことです (構成ファイルのキャッシュされたコピーをメモリに保存します)。これは、PHP ファイルの任意のインクルードを許可するのではなく、特定の値のみをロードするように非常に簡単に制限することができ、私の意見では全体的により良い解決策ですが、上記の方法で正しい方向に進むことができます。

おそらく、 VCSにファイルを無視させたいでしょう。一方、ファイルのスケルトン、または妥当なデフォルト値 (もちろん、後者はログイン データには適用されません) をバージョン管理したい場合もあります。これに対処する一般的な方法は、テンプレート構成ファイルをチェックインすることです。インストール手順は、そのファイルを実際の構成ファイルの場所にコピーし、そこでカスタマイズします。これは、手動のプロセスでも自動化されたプロセスでもかまいません。

（主な質問とは多少関係ありませんが、環境に定数を導入すると、ライブSMTPの代わりに偽のメールの実装を延期するなど、他のクールなことを行うことができますが、もちろんこれは構成ファイルでも実行できます）

于 2013-02-26T12:22:21.677 に答える
47

Apacheを使用している場合、仮想ホスト構成に情報を保存することは、非常に優れたソリューションの1つです

SetEnv  MYSQL_USER     "xx"
SetEnv  MYSQL_PASSWORD "y2wrg435yw8"

$_ENV[]データは、コードで使用するために簡単に取得できます。

于 2013-02-26T12:24:11.997 に答える
11

他の人が言及したように、ソース管理外の別の構成ファイルに入れます（明らかに、これはソース管理下にあるコードで言及されます）。

また、ディレクトリが誤って公開された場合に備えて、 config.iniではなくconfig.phpというファイル名を付けることをお勧めします。つまり、ファイルはダウンロードされず、何も返されません。

于 2013-02-26T12:33:37.623 に答える
6

12factorの方法が価値があると思われる場合は、構成を環境に保存することをお勧めします。

これには、テスト中または非実稼働環境でまったく同じコードを記述できるという追加の利点があります。データベースなどを変更したい (または変更する必要がある) 場合、コードを変更する必要はありません。環境変数を変更するだけで準備完了です。

于 2013-02-26T15:44:24.323 に答える
2

パスワードをコードから構成ファイルに移動して、パスワードがリポジトリに存在しないようにすることをお勧めします。構成ファイルとそれを復号化するPHPコードを持っている人は、いつでもコードを実行してクリアテキストのパスワードを取得できるため、構成ファイルで暗号化するという考えには疑問があります。おそらく、パスワードをプレーンテキストとして構成ファイルに保持し、構成ファイルを不正アクセスから保護する方法を検討する方がよいでしょう。

于 2013-02-26T12:25:17.263 に答える
2

良い質問。最も機密性の高い部分（キー/パスワードなど）を環境変数として移動することもできますが、それでは問題をサーバー構成（おそらくリポジトリにもある）に委ねることになります。

また、データベースのようなもののパスワードを避けて、パスワードを少なくし、代わりにファイアウォールの背後で保護することもできます。これらはどれも完璧な解決策ではありませんが、私が知っているアプローチです。

于 2013-02-26T12:26:17.047 に答える
2

私がすることは、config.php.dist のようなリポジトリにサンプル構成ファイルのみを保存し、実際の config.php をバージョン管理下に置かないことです。

于 2013-02-26T12:21:32.790 に答える
1

関数parse_ini_fileを使用して、いつでも構成iniファイルを作成できます。

于 2013-02-26T12:25:38.767 に答える
1

ここでは、このすべての問題は見られません。リポジトリを共有している場合、おそらくパスワードと構成をハードコーディングしたくないでしょう。代わりにデフォルトのものを提供する必要があります：

host: localhost
user: root
pass: root
name: db

本当に必要な場合は、.iniファイルを使用して解析できますが、ソース コードで設定されている配列に比べて非常に遅くなる可能性があり、あまり意味がありません。

覚えておいてください: あなたが信頼できるのはソース コードだけです。

于 2013-02-26T12:28:54.480 に答える