-2

私がセッションについて読んで知っていることは、セッション ID のハイジャックなどのすべてに対して、それらが実際には信頼できないということです。そこで、自分のプロジェクトではセッションを使用しないことに決めました。通常の Cookie を使用して、最善を尽くすことを望みます。

つまり、基本的に私がセットアップしたのはセッションのようなものですが、うまくいけばクラックするのは難しくなります. 残念ながら、私はそれをクラックするのが難しいように構築することができないようです. したがって、基本的には、これは Cookie とセッションのどちらを選択するかというよりも、セキュリティの問題であると思いますが、ストレート テキストでこれを見つけることはできないようです。

セッション Cookie で何をハッシュし、どのようにハッシュする必要がありますか? ハッシュアルゴリズムが衝突する可能性があることを読んだことがありますが、攻撃者が実際にクッキーに含まれているものと衝突する文字列を作成できるのはほんの数秒です。私が尋ねようとしているのは、この情報を Cookie に保存する適切な方法と、実際にどの情報をそこに保存する必要があるかということです。

基本的にhttpOnly、攻撃者がクッキーを手に入れることができるはずがないことはわかっていますが、このプロジェクトでは使用しない可能性があり、おそらく使用しないと思われるSSLため、古いタップ方法が利用可能です。ここに棒と石で超高層ビルを建てようとしていることは知っていますが、それでも尋ねる価値はあります。

4

2 に答える 2

3

セッションを完全に回避することの問題は、一部の値をユーザーが設定できないようにすることです。たとえばis_logged_in、ユーザーが認証に成功した場合にのみ設定されるセッション変数がある場合、Cookie を使用してこれを安全に実装するのは難しいでしょう。問題は、ユーザーが独自の Cookie を設定して (クライアント側から取得されるため)、パスワードなしでログインできることです。

現在、ユーザーの資格情報を Cookie に保存し、すべての要求に対して認証を行うことで、このアプローチを使用できますが、これにも多くの問題があります。まず、資格情報をプレーンテキストでサーバーに送信する頻度を制限することをお勧めします。セッションを使用する場合は、一度だけ送信します。第 2 に、このアプローチは、パスワードが暗号化されずにローカル コンピューターに保存されることを意味します (Web サイトの保存されたパスワードは通常、マスター パスワードで暗号化されます**)。したがって、このアプローチは間違いなくユーザーの全体的なセキュリティを悪化させます。

ログオンすることでこれらの問題を軽減し、ログイン システムで暗号化された Cookie を設定することができます (対称暗号化を使用) これらはすべてのリクエストで復号化および認証され、すべてのリクエストで安全に送信でき、ローカル コンピュータの Cookie に保存する方が安全です。ただし、ここではかなりの複雑さを追加しています。

したがって、セッションの使用を継続することをお勧めしますが、セキュリティの問題が発生した場合は必要に応じて読んでください。


**最近、Chrome は保存されたパスワードをプレーンテキストで保存し、マスター パスワードでパスワードを暗号化するオプションがないことが判明しました (こちら を参照)。これにより、一部のセキュリティ機能が単なる「お芝居」(つまり、実際に具体的な追加セキュリティを追加せずに安全に見えるだけ) であるかどうかについて、オンラインで議論が始まりました。

于 2013-09-08T10:20:28.693 に答える
1

実際には、(セッションからの) Cookie を Cookie に置き換えたいと考えています。意味がありません!

于 2013-09-08T11:02:46.743 に答える