0

キャッシュされたデータを通常のphpファイルに保存し、データを配列に保存するキャッシュライブラリがあります。

キャッシュファイルの例:

cache_userID.php:

$userCache['userID']=2354654654;
$userCache['userName']=foo;
$userCache['userPass']=salted-and-hashed-pass;

それは魅力のように機能します。したがって、DBクエリを保存するために(上記の例のように)ユーザーデータを保存するためにそれを使用することを考えています。私はすでにそれをテストしました、そしてそれはDBからフェッチするよりも著しく速いページロード時間をもたらします(それが私がそれをしたい理由です)。

しかし、これが本当に安全かどうかはわかりません。パスワードやその他の機密情報はソルトされ、ハッシュされます。誰もがこのデータを盗むことができるでしょうか?ソースコードにアクセスするためのFTPの詳細がある場合を除いて(そうではありません)。

4

3 に答える 3

7

いいえ!

パスワード(またはまだ機密性の高いパスワードハッシュ)を保存する余分な場所はすべて、漏洩する可能性のある別の場所です。これがSSLページがキャッシュされない理由の1つです。機密情報をキャッシュしてはならないためです。

優れた認証コード(SSHで見られるようなもの)は、パスワードがスワップ不可として保存されているメモリ領域をマークして、オペレーティングシステムがディスクに書き込めないようにする作業にも使用されます。

このキャッシュから機密データが漏洩するリスクは低いかもしれませんが、これを行うことでリスクが高まります。このデータをローカルPHPファイルに配置することで、ローカルファイルインクルードの脆弱性からアクセスできるようになります。実際にパスワードを画面にエコーアウトするには、ローカルファイルを含めるだけでは不十分な場合があります。このキャッシュが存在する前は、パスワードハッシュにアクセスするために、SQLインジェクションの脆弱性または完全なサーバーの侵害がおそらく必要でしたが、今ではそれらローカルファイルインクルードがハッシュにアクセスできます。

ページの読み込み速度を向上させるために、機密性の低い他のデータを複数の場所に保存することは問題ありませんが、パスワードとパスワードハッシュは立ち入り禁止にする必要があります。

認証トークンを保存することで、認証されたユーザーのページが読み込まれるたびにパスワードハッシュを計算して検索する必要がなくなります。これは、ログイン時にランダムに生成され(したがって、予測が困難です)、短命である必要があります。これはまさにPHPセッションIDであり、パスワードを比較する最初のチェックの後で、ユーザーが適切に認証されていることを確認するのに完全に適切です。


データベースにクエリを実行し、ページが読み込まれるたびにパスワードハッシュを計算する場合は、クライアントのどこかに、おそらくCookieにパスワード(または場合によってはパスワードハッシュ)を保存しておく必要があり、この機密データが送信されていることに気付きました。すべてのページリクエストに対してインターネット経由で。これは一般的に悪い習慣であり、すべてのページにSSLを使用していない限り、パスワード(またはパスワードハッシュ)がユーザーのハードドライブに保存され、中間プロキシになる可能性があります。


PS

ローカルファイルを含めることが、データベースからの単純なKey-Valueルックアップよりも著しく高速である理由に興味があります。私の推測では、ネットワークでひどい遅延が発生しているか、ユーザーテーブルで競合が発生しています。どちらかが本当に修正する必要があります。

于 2012-06-17T14:44:40.917 に答える
2

ファイルに<?phpデータが含まれている限り、ユーザーはFTPアクセスがないか、任意のファイルを読み取ることができるセキュリティホールがない限り、PHPソースコードを表示できないため、データは安全です。

ただし、キャッシュフォルダをドキュメントルートの外に移動するか、Webサーバー構成(たとえば、deny from all.htaccess)を介してキャッシュフォルダへのhttpアクセスをブロックすることにより、キャッシュフォルダを保護する必要があります。

于 2012-06-17T14:17:31.240 に答える
2

キャッシュファイルがwwwでアクセス可能な場所にない限り、十分に安全である必要があります(コードに欠陥がないと仮定します)。コンテンツを隠すPHPタグに依存しないでください...エンジンが失敗してこのデータを公開する可能性があります(まれですが、実際に発生します)。

しかし...これが良い考えだったとしたら、誰もがそれをやっていないのではないでしょうか?何かを知りたいときはいつでも、ユーザーのすべてのデータが本当に必要ですか?これがより効率的だと思うなら、それは非常に単純なアプリケーションでなければなりません。なぜあなたのデータベースはとても遅いのだろうか。適切なインデックスなどを設定しましたか?

于 2012-06-17T14:20:54.410 に答える