web-dev-qa-db-ja.com

htaccessでリダイレクトすると機密ページに十分なセキュリティが提供されますか?

MySQLデータベースのログイン詳細でファイルを作成しました。 .htaccessを使用して、すべてのユーザーを/Config/config.phpから/index.phpにリダイレクトします。これで十分安全だと思います。つまり、ユーザーが/Config/config.phpを表示できないようにするのに十分なものは何ですか。

12
vakus

これは、正しく設定されていれば、適切なセキュリティを提供できます。

私は1つの一般的な欠陥を考えることができます。Apacheとリライトルールを使用すると、同じファイルを指し、リダイレクトされないURLを構築できることがよくあります。たとえば、/Config/config.phpリダイレクト、ただし//Config//config.php ではない。これは、書き換えルールがバリエーションではなく正確なURLに一致するためです。

セキュリティのためにリダイレクトを使用するときのもう1つの一般的なエラーは、リダイレクトにヘッダーを送信することですが、ページのレンダリングを妨げません。その後、攻撃者はLocationヘッダーを削除してページにアクセスできます。ただし、これは通常アプリケーションのエラーであり、Apacheを使用してリダイレクトを行う場合ではありません。

より良い方法は、設定ファイルをWebルートの外に置くことです。だからあなたはindex.phpサブディレクトリpublic、およびconfig.phpこのディレクトリの外。これにより、構成が公開される可能性が低くなります。

28
Sjoerd

Config.phpのセットアップ方法では、たとえWebブラウザーを介してこのファイルにアクセスできたとしても、ユーザーが資格情報を表示できないようにする必要があります。

この例 から借用した次の構成ファイルを考えます。

<?php
return (object) array(
    'Host' => 'localhost',
    'username' => 'root',
    'pass' => 'password',
    'database' => 'db' );
?>

ユーザーがこのページに直接移動すると、空白の画面が表示されます。これは、このスクリプトの何も実際にページに印刷されないためです。情報が漏洩することはありません。

このような方法で設定をセットアップすることをお勧めします。何らかの理由で.htaccess失敗しても実際には問題になりません。

11
Shadow

番号。

次のシナリオについて考えてみます。

  1. 誰かがサーバーを再構成し、再ダイレシングを無効にします。おっとっと。 .htaccessはもはやあなたを保護しません。
  2. 誰かが.htaccessファイル内のリダイレクトルールよりも優先されるリダイレクトルールをサーバー構成に追加します。喜びがない!
  3. 誰かがサーバーを再構成し、htaccessファイルを無効にします。繰り返しになりますが、もはや保護はありません。
  4. 誰かが誤って.htaccessファイルを削除しました。繰り返しになりますが、もはや保護はありません。

数4年前に別のサーバーに移行していたときに、実際に4番目の問題が発生しました。htaccessファイルをコピーするのを忘れていました。ありがたいことに、数時間後に気づきましたが、害はありませんでした。しかし、間違いは常に起こります。あなたはそれらを計画する必要があります。

これらすべての問題は、htaccessファイルを使用して実装するソリューションに当てはまります。サーバーの構成にアクセスできる場合は、そこにディレクティブを配置します。また、HTTP基本認証の追加レイヤーで構成エンドポイントを保護します(アクセスするためにhttpsを使用していると仮定すると、かなりのセキュリティが追加されます)。

Config.phpが(サードパーティのソフトウェアパッケージの一部ではなく)自社開発である場合、ログインページphpスクリプト内にリダイレクトします。

4
Out of Band

他で指摘したように、リダイレクトはブラウザからアクセスしたときにのみリダイレクトされるため、リダイレクトだけでは役に立ちませんが、includerequireあなたが今やるかもしれません。一部のユーザーがこのようなファイルをサーバーにアップロードできる場合は、それほど大変な作業ではありません。あなたのウェブサイトのフォルダの外に置いて、.htaccessAllowoverride all

外部に置くことができない場合は、指定したディレクトリへの直接アクセスを削除することもできますpublic_html

0
Abhishek Gurjar