web-dev-qa-db-ja.com

（Cookieに保存されている）キーを暗号化するとセキュリティが向上しますか？

シナリオ

  • ログイン時にマスターキーが入力され、$server_keyで暗号化されます
  • マスターキーは、永続化のために$_COOKIE['encrypted_key']変数として保存されるようになりました（ユーザーがページをロードするたびに入力する必要はありません）。
  • $server_keyはアプリサーバーの設定ファイル内に保存されます
  • データは最初に$_COOKIE['encrypted_key']を復号化して（$server_keyを使用して）復号化されるため、マスターキーが明らかになります
  • $_COOKIE['encrypted_key']はブラウザの終了時に破棄されます

脅威

攻撃者がユーザーのデバイス/ Cookieと暗号化されたデータ（アプリサーバーの構成ファイルではない）にアクセスする。

質問

マスターキーを$server_keyで暗号化し、$server_keyをアプリサーバーの構成ファイル内に保存することは意味がありますか？

推論

$server_keyのみ、または$_COOKIE['encrypted_key']のみを取得しても、何も侵害されません。攻撃者は両方を取得する必要があります。

更新

  • これはHTTPSの下にあります
  • リクエストごとにセッションフィンガープリントをチェックするため、セッションハイジャックは困難です。
encryptionphpxsscookiessession-management
3
IMB

脅威モデルは不完全です。あなたが見逃したもののいくつかはここにあります：

1）マスターキーとサーバーキーは静的な値のように見えます。つまり、Cookieの値は一定であり、Cookieの値を持っている人はだれでもサーバーにそれを再生して、そのユーザーのすべてのプレーンテキストデータを盗む（スパイダーする）ことができます。

1a）Cookieはプロキシなどの他の場所にも保存されます。

2）サーバーが危険にさらされている場合、攻撃者はマスターキースペースをブルートフォースで強制し、ユーザーごとにユーザーデータを復号化できます。これが成功する可能性は、マスターキーの長さと暗号化アルゴリズムに完全に依存します。

3）ユーザーはサーバーキーを取得できます。彼らはマスターキーを知っており、Cookieを表示できるため、サーバーキーをブルートフォースオフラインにすることができます。この場合も、成功の要因はキーの長さとアルゴリズムに依存します。

4）サービスが暗号化されたプレーンテキスト接続を介して配信されているかどうかは不明です。後者の場合、マスターキーとCookie値の両方が、同じネットワーク上の攻撃者によって観察される可能性があります。前者の場合、接続がダウングレードされるか、他の脆弱性が存在する可能性があります。

5）攻撃者がサーバーをハッキングした場合、受信したすべてのマスターキーのコピーを保持するようにログインコードを変更できます。違反が数か月/数年にわたって気付かれないことがよくあります。

6
wireghoul

$ server_keyの目的はCookieのリプレイを無効にすることです。リプレイはできますが、$ server_keyがわかりません

サーバーキーでマスターキーを暗号化しても、リプレイアタックは無効になりません。攻撃者は、暗号化されたマスターキーをサーバーに送信するだけで、攻撃者が必要とするデータを復号化することができます。サーバーが 混乱した代理 になります。攻撃者はこれを行うためにサーバーを危険にさらしたり、サーバーの鍵を入手したりする必要はありません。

この攻撃を制限するには、暗号化されたマスターキー内に有効期限とIPアドレスを追加します。つまり、Encrypt（MasterKey + Expiry + IP address）、サーバーは暗号化されたトークンを使用する必要があります。指定されたIPアドレス。

1
Lie Ryan