MySQLデータベースのログイン詳細でファイルを作成しました。 .htaccess
を使用して、すべてのユーザーを/Config/config.php
から/index.php
にリダイレクトします。これで十分安全だと思います。つまり、ユーザーが/Config/config.php
を表示できないようにするのに十分なものは何ですか。
これは、正しく設定されていれば、適切なセキュリティを提供できます。
私は1つの一般的な欠陥を考えることができます。Apacheとリライトルールを使用すると、同じファイルを指し、リダイレクトされないURLを構築できることがよくあります。たとえば、/Config/config.php
リダイレクト、ただし//Config//config.php
ではない。これは、書き換えルールがバリエーションではなく正確なURLに一致するためです。
セキュリティのためにリダイレクトを使用するときのもう1つの一般的なエラーは、リダイレクトにヘッダーを送信することですが、ページのレンダリングを妨げません。その後、攻撃者はLocation
ヘッダーを削除してページにアクセスできます。ただし、これは通常アプリケーションのエラーであり、Apacheを使用してリダイレクトを行う場合ではありません。
より良い方法は、設定ファイルをWebルートの外に置くことです。だからあなたはindex.php
サブディレクトリpublic
、およびconfig.php
このディレクトリの外。これにより、構成が公開される可能性が低くなります。
Config.phpのセットアップ方法では、たとえWebブラウザーを介してこのファイルにアクセスできたとしても、ユーザーが資格情報を表示できないようにする必要があります。
この例 から借用した次の構成ファイルを考えます。
<?php
return (object) array(
'Host' => 'localhost',
'username' => 'root',
'pass' => 'password',
'database' => 'db' );
?>
ユーザーがこのページに直接移動すると、空白の画面が表示されます。これは、このスクリプトの何も実際にページに印刷されないためです。情報が漏洩することはありません。
このような方法で設定をセットアップすることをお勧めします。何らかの理由で.htaccess
失敗しても実際には問題になりません。
番号。
次のシナリオについて考えてみます。
数4年前に別のサーバーに移行していたときに、実際に4番目の問題が発生しました。htaccessファイルをコピーするのを忘れていました。ありがたいことに、数時間後に気づきましたが、害はありませんでした。しかし、間違いは常に起こります。あなたはそれらを計画する必要があります。
これらすべての問題は、htaccessファイルを使用して実装するソリューションに当てはまります。サーバーの構成にアクセスできる場合は、そこにディレクティブを配置します。また、HTTP基本認証の追加レイヤーで構成エンドポイントを保護します(アクセスするためにhttpsを使用していると仮定すると、かなりのセキュリティが追加されます)。
Config.phpが(サードパーティのソフトウェアパッケージの一部ではなく)自社開発である場合、ログインページphpスクリプト内にリダイレクトします。
他で指摘したように、リダイレクトはブラウザからアクセスしたときにのみリダイレクトされるため、リダイレクトだけでは役に立ちませんが、include
& require
あなたが今やるかもしれません。一部のユーザーがこのようなファイルをサーバーにアップロードできる場合は、それほど大変な作業ではありません。あなたのウェブサイトのフォルダの外に置いて、.htaccess
Allowoverride all
。
外部に置くことができない場合は、指定したディレクトリへの直接アクセスを削除することもできますpublic_html
。