2

私はphpでセッションを保護する方法を読みましたが、いくつかありますが、ユーザーエージェント、IP、およびポートをセッションに追加して両方を暗号化するほど効果的ではありません。セッションハイジャックを防ぐ良い方法は何ですか? 私は次のステップを踏むことを考えました：

  1. PHPSESSIDキーをidのような一般的なものに完全に変更します
  2. ページごとにトークンを生成してページに配置し、セッションと同様に検証します。これにより、検証のためにセッションのみに依存することが減ります。
  3. 短いセッションの有効期限を追加します。
  4. セッション ID にさらに変数を追加して暗号化すると、セッション ID が長くなり、解読が難しくなります。おそらく、RSA暗号化を使用するでしょう。
  5. ユーザーがセッションを終了できるように、ログアウト ボタンを配置します。
  6. JavaScript を使用して時間をカウントします。5 分を超えると、ユーザーにセッションを続行するよう警告します。
  7. セッションを Cookie のみに保存します。

私が聞いた問題点は次のとおりです。ページごとにトークンを使用する場合、戻るボタンを無効にする必要がありますか? 何故ですか？

他にもいくつか不明な点がありますか？セッションをデータベースに保存する方が安全ですか? なぜ？SSL を使用するとどの程度安全になりますか? セッションIDを非常に迅速に再生成することはどうですか?

暗号化キーの総当たり攻撃を防ぐシステムはどれですか (セッション ID を推測する大量の試行でサーバーをフラッディングしようとするユーザーの IP を特定することは役に立ちますか?)

セッションの再生成はどのように機能しますか?古いセッション キーは自動的に破棄されますか?ハッカーが古いセッション キーを取得した場合、それは引き続き機能しますか? 侵入テスターに​​なる方法を学んでいるので、セッションのセキュリティを理解することは重要ですか?

更新 私はこれを行うことを考えました：キーを使用したセッションIDの対称暗号化キーを使用してポストフィールドにあるランダムに生成されたトークンの対称暗号化

ランダムに生成されたトークンもセッション ID に追加され、暗号化されます。

リクエストに応じて、これらの変数を取得する必要があります: $_SESSION['PHPSESSID'] (ランダムに生成されたトークンが暗号化されています) $_POST['RandomlyGeneratedToken']

キー A でセッション ID を復号化し、キー B でランダムにトークンを復号化します。次の 2 つのチェックを行います。 -トークンが最初に送信されたリクエストのトークンと同じかどうかをチェックします。-トークンがセッション ID に存在するかどうかを確認します。

ハッカーの可能性: - セッション ID を強引に攻撃する。私のセッションIDは十分に長いので、彼には時間がかかります. 異なるセッションIDを持つ同じIPからの大量のリクエストフローを検出し、スリープ機能で彼を遅くするシステムを採用することができました.

- トラフィックを傍受し、ユーザーからセッション ID とトークンを取得し、それらを送信しようとします。うーん...リクエストごとにセッションIDを再生成し、特定のページでセッションをすぐに期限切れにする必要があります..1分かもしれません..しかし、彼はどのくらいの速さで盗聴できますか?

4

1 に答える 1

5

「PHPSESSIDキーを完全にidのような一般的なものに変更してください」

これは、難読化によるセキュリティであり、その弱点です。ユーザーは自分のCookieを表示し、これをバイパスするためにセッションIDに使用されているCookieをまとめるだけで済みます。

「ページごとにトークンを生成し、それをページに配置してから、セッションと同様に検証します。」

これは興味深いアイデアです。しかし、ユーザーが複数のページを開いている場合はどうなりますか？複数のトークンをサポートできますか？トークンはいつ期限切れになりますか？

「短いセッションの有効期限を追加します。」

良い考えですが、これは、ページに長時間滞在してから更新を押しただけで、ログアウトが早すぎることに気付くユーザーに影響を与える可能性があります

「セッションIDに変数を追加して暗号化すると、解読が長くなりにくくなります。おそらくRSA暗号化を使用します。」

なぜRSA暗号化を使用するのですか？SHAのような一方向のものでハッシュしてみませんか？塩または初期化ベクトルを追加することを忘れないでください

「ログアウトボタンを押して、ユーザーがセッションを終了できるようにします。」

誰がログアウトボタンを押したことがありますか？;-)

「JavaScriptを使用して時間をカウントします。5分を超えると、セッションを続行するようにユーザーに警告します。」

はい

「セッションをCookieのみに保存してください。」

これを行わないでください。常にデータサーバー側を保存してください。Cookieはクライアント側に保存されるため、操作できます

他のコメントについて：セッション変数をデータベースに保存できます。これにより、IPアドレスなどの他のものを確認できます（ただし、カスタムセッション処理機能を使用してIPなどを確認できます：http：//php.net /manual/en/session.customhandler.php）。ただし、データベースを使用していて、セッションIDを頻繁に再生成する場合（たとえば、ページが読み込まれるたびに）、ユーザーが更新ボタンをすばやく押すと、サーバーがデータベースで更新するよりも速くIDが再生成されることがわかります。セッションは失われます。

「セッションの再生成はどのように機能しますか、古いセッションキーは自動的に破棄されますか」

はい、カスタムコードを記述しない限り、カスタムコードによって異なります。

私の回答がある程度役に立ったことを願っていますが、ベストプラクティスに従うために、セッション管理に関するOWASPのガイドラインに従うことをお勧めします： https ：//www.owasp.org/index.php/Session_Management_Cheat_Sheet

編集

トークンとはどういう意味ですか？セッションIDのようなトークンを意味しますか？それはどのような価値を提供しますか？トークンはセッション変数ですか？その値はサーバー側に保存されているため、これは意味がありません。キーは、悪用を防止しようとしているphpsessidです。

また、あなたの論理を理解しないハッカーの能力を決して期待しないでください。彼らがそれを理解したいのなら、彼らはそうするでしょう。

最後に、なぜそれほど多くのセキュリティが必要なのですか（これに反対票を投じないでください）。十分なセキュリティ（特定の基準に従っている場合）などがあります。おそらく、このプロジェクトを外部委託する外国政府のハッカーから保護する必要はないでしょう。簡単にグーグルで検索できるチュートリアルや、上記で提供したOWASPなどのガイドラインで概説されているベストプラクティスに従ってください。それで十分でしょう:-)

編集 「また、最適なストレージはデータベースだとおっしゃっていますか？ブルートフォーシングに対して説明した最後の方法はどうですか？」

データベースセッションストレージは必ずしも最適ではありません。セッションデータを共有する必要がある複数のWebサーバーの負荷を分散する場合など、必要なときに使用します。

ブルートフォース攻撃を阻止する2つの方法は、1）セッションIDが非常に長いこと、および2）セッションIDを頻繁に再生成することです。

于 2013-03-16T07:28:04.113 に答える