1

私はPHPに不慣れではありませんが、認証には常にセッションを使用していました。今度はステートレス認証を行いたいので、セッションを使用できません。サーバーインスタンスが多数ある可能性があり、セッションデータを共有しないため、データベースにセッションテーブルがあります。以下：

  • クライアントのマシンにトークンを含むCookieを保存します
  • セッションテーブルにGUIDのようなトークン列を設定して、同じトークンを持つすべてのエントリにクライアントがアクセスできるようにします。
  • また、クライアントのIPを保存して、トークンが同じでIPが異なるユーザーがデータを読み取れないようにします。

このようなもの

id   | token        | ip         | key       | data
1    | a-guid       | 190.0.0.1  | username  | encrypted-data
2    | a-guid       | 190.0.0.1  | is_logged | more-encrypted-data 
3    | other-guid   | 190.2.2.2  | is_logged | some-more-data

したがって、トークンa-guidとip 190.0.0.1のCookieを持つユーザーは、ユーザー名と*is_logged*にアクセスできます。

しかし、セキュリティについてはよくわかりません。誰かがあなたのCookieとIPからトークンを取得でき、その人がCookieトークンとIPを使用してリクエストを送信できれば、アカウントに完全にアクセスできるようになります。

特別な考慮事項がありますか？

4

2 に答える 2

4

多くの人が持っているのと同じように、セッションのメカニズムについて誤解しているようです。PHPがセッションを追跡できるメカニズムはいくつかありますが、セッションを追跡する最も一般的な方法は、提案しているのとまったく同じメカニズム、つまり、いくつかの一意のトークンを持つプレーンな古い通常のCookieを使用することです。

PHPセッションがCookieを利用する方法と、Cookieが通常使用される方法との違いは、セッションがCookieに有効期限を設定しないことです（したがって、ブラウザを閉じると、通常、ブラウザはCookieを破棄します）。これは、提案された方法が対応する場所です）データとしてセッションID（提案されたトークンと同様）のみをCookieに入力します。

それでは、それは私たちをどこに残すのでしょうか？ええと、一つには...あなたが持っているセキュリティ上の懸念（提案されたトークンを傍受する）は、通常のセッション（セッションIDを傍受する）にも関連しています。このセキュリティ上の懸念を回避したい場合は、安全な転送（SSL / TLSを使用したHTTPS ）の利用を開始する必要があります。

そして、あなたが提案したように、中央セッションテーブルを使用する限り、これは確かに一般的なルートです。そして、あなたは何を知っていますか？PHPには、通​​常のセッションでこれを「簡単に」処理するためのメカニズムがすでに用意されていますsession_set_save_handler()。

SessionHandlerInterfaceこの関数を使用すると、適切と思われる永続ストレージの読み取りと書き込みを行う関数（または5.4以降はインターフェイスを備えたオブジェクト）を登録できます。これは、データベース内のセッションテーブルも意味する可能性があります。ただし、これらの関数/メソッドの記述には注意が必要です。しかし、おそらくWebやStackOverflowで良い例を見つけることができます。

于 2012-11-01T14:56:10.137 に答える
-1

認証時にランダムな文字列を作成し、これをセッションのDBに保存し、それを使用して上記の情報を暗号化するとどうなりますか？トークンを取得したサーバーは、保存されているシークレットを使用してセッションを復号化できますが、サードパーティによって偽造されることはありません。

Cookieに保存するのは、暗号化されたデータと、秘密を検索するために使用される値だけです。

于 2012-11-01T13:51:50.403 に答える