1

ユーザーが自分のクッキーをどのように操作できるのか疑問に思っています。

私が知っているように、CIはそれを知ることができ(Cookieの最後の関係cookie_value/unique_keyのため)、CIが発生するとCookieが更新されます。

そして彼はこれを記録します:

セッション Cookie データが予期したものと一致しませんでした。これはハッキングの試みである可能性があります

ポイントは、ログインデータを保存するためにネイティブphpセッションを使用することについて話す人もいますが、盗難のリスクは同じです(CI Cookieの場合はおそらくそれよりも少ないでしょう)。私が見ることができる唯一の違いは、ユーザーが CI Cookie セッションに保存されているデータを確認できることです。

CIセッションCookieは安全ですか?または、ネイティブ php セッションよりも安全性が低いのはなぜですか?

トラフィックの多いウェブサイトでは、負荷料金も抑えるように気をつけています。

下手な英語でごめんなさい..

CI セッションの検証を説明するために編集します。

機密データを保存したくない場合、セッション Cookie は暗号化されず、データベースにも保存されません。

CI 2.1.3 セッション ライブラリに従って、CI_Session::sess_read()135 行目でメソッドが宣言され、CI_Session::ses_write()235 行目でメソッドが宣言されます。

CI が Cookie を作成すると、このデータが配置されます

[array]
(
     'session_id'    => random hash,
     'ip_address'    => 'string - user IP address',
     'user_agent'    => 'string - user agent data',
     'last_activity' => timestamp
)

この配列をシリアル化し、md5 ハッシュ (シリアル化されたデータと構成で提供された暗号化キーから) を最後に置きます。

// if encryption is not used, we provide an md5 hash to prevent userside tampering
$cookie_data = $cookie_data.md5($cookie_data.$this->encryption_key);

そのため、CI への次の http リクエストからセッション ライブラリが初期化されるとき

それは実行し、次のことを自問します。

  1. 分離datahash、セッション cookie から
  2. md5hashに等しいmd5( data + encryption_key )ですか?
  3. dataアンシリアライズできますか?
  4. 最小限のデータはすべてここにありますか?
  5. このセッションは期限切れですか?
  6. IP は一致しますか?
  7. USER AGENT は一致しますか?

これらの答えのいずれかが NO の場合、CI セッションは破棄され、リセットされます。

この場合のPHPネイティブセッションに加えて、相対的なリスクを教えてください。

4

3 に答える 3

5

「この場合のPHPネイティブセッションに加えて、相対的なリスクを教えてください」に関する部分だけに答えてください。

セッションを盗む良い方法は、誰かのコンピュータにアクセスして Cookie をコピーし、自分自身に送信して (データベース テーブルを使用しているかどうかに関係なく!!!!!)、別のコンピュータでその Cookie を再利用することです。もちろん、すべての Web アプリケーションはこの攻撃に対して無防備です。

あなたが企業にいる場合、実際には@am05mhzのアイデアが好きですが、Webサーバーとまったく同じIPアドレスとして表示される可能性があり、ユーザーセッションのコピーを盗むことに成功し、彼になりすますことができます.. ...私の意見では、アイデアは興味深いと思いましたが、考えれば考えるほど、IP全体は価値がありません。

他のサーバー側のセッションベースのアプリでは、サーバー側のセッションにマップする Cookie (または Java で Cookie がオフになっている場合は jsessionid) を取得することで、これも可能になります。サーバー側のセッションをバックアップする Web ブラウザー マッピング。

いずれにせよ、https を使用していて、Cookie または http ヘッダーで正しい secureOnly フラグを使用している場合 (正確なフラグを覚えていない場合)、取得しようとしているのと同じくらい安全です。

セッション全体をクライアント側で送信する場合に本当に心配する必要があるのは、パスワードやクレジット カード番号などの重要なデータを絶対に入れないことだけです。

また、20 分後に Web サイトのユーザーをタイムアウトし、セキュリティ対策として Cookie を消去します。

誰かに役立つかどうかはわかりませんが、投稿すると思いました。

編集: ip のことを再検討します。http の場合、IP は非常にうまく機能するため、企業外の誰もがセッションを盗むことはできませんが、企業内の誰もがセッションを盗むことができます。(つまり、http 経由でログインした場合にセッション cookie を送信すると、データベース セッション ストレージを使用しているかどうかにかかわらず、非常に影響を受けやすくなります)。

ディーン

于 2013-12-09T17:21:29.147 に答える
1

セッションをデータベースに保存することを強くお勧めします。その方がより安全だからです。セッションを保存するには、まずこの目的のためにデータベース テーブルを作成する必要があります。

詳細については、ドキュメントの「セッション データをデータベースに保存する」セクションを参照してください。また、Cookie を暗号化することもできます。Hera はCodeIgniter セッションに関する別の回答であり、コメントで述べたようにサイトが遅くなることはありません。ユーザーのコンピューターに暗号化されていないセッション データを保存する場合、それはあまり良い考えではありません。そうしないことをお勧めします。それ。

于 2012-11-26T19:13:09.590 に答える
-1

CI ログオン Cookie は、値がデータベースに永続化され、Cookie に設定されてユーザーに返される、永続的なログオン (Remember me 機能) を実装します。両方の値が一致する場合、ユーザーは認証されます。この機能を使用しない場合でも、PHP セッションを使用して認証/承認関連のデータを保存する必要があります。セッション Cookie に対して httpOnly オプションを有効にすることもできます。

于 2012-11-26T19:02:33.137 に答える