すでに何度も繰り返されていることは承知していますが、私が目にした回答はすべて非常にわかりにくく、互いに矛盾していたり、説明が不完全だったりしたので、利用可能なすべてのリソースを使用して自分でこれを実行しようとしていますが、どこかで迷ってしまったと思います。これをきっぱりと明確にしたいと思います。少し長くなるかもしれませんが、あらかじめご了承ください。
私のページの上部には小さなログインボックスがあり、ユーザーがログインしていない場合はそのまま表示されます。はログインすると、ログイン ボックスの代わりに、名前が記載された挨拶が表示されます。
セッションチェック
まず、ユーザーが「メンバー限定」コンテンツにアクセスできるかどうかを確認する方法の図を示します (これまでのところ、私の理解では)。 (このコードはページの上部に配置され、次のような変数をチェックして設定します$loggedin = true;
)
現状では、my$_SESSION['loggedin']
はユーザー名のみです。私の理解では、セッションは同じドメインから偽造またはハイジャックされる可能性があるため、これは非常に安全ではないことはわかっています (たとえば、攻撃者が別のユーザー名を含むセッションを作成すると、そのユーザーのものに即座にアクセスできるようになります)。ただし、セッションをどのように確認すればよいかわかりません。これを行うために考えられる唯一の方法は、ページがロードされるたびにデータベースに接続し、データベースから MD5 ハッシュまたは何かを確認する (そして更新する) ことですが、これにより大量の不要なサーバー トラフィックが発生すると想像されます。これよりも優れた方法があるはずです。
ログイン
ユーザーがログインしたときに何が起こるか (そして挨拶を表示するか、ログイン ボックスを表示するか) を示す図を以下に示します。
私はこの部分については大部分かなりしっかりしている(と願っています)のですが、後でデータベース内のハッシュ、Cookie 内のハッシュ、および新しく生成されたハッシュを使用してハッシュを再チェックし、Cookie が攻撃者によって作成されたものではないことを確認できるようにするには、MD5 ハッシュに何を含めるべきかわかりません。また、以下のコメントで述べたように、ユーザーが複数の場所(たとえば、携帯電話とラップトップ)からログインしたままにできるように、ハッシュでの IP アドレスの使用を廃止する予定です。
私の質問は次のとおりです:
- セッションが偽物でないことをどうやって確認すればいいですか?
- クッキーが偽物でないことを確認するにはどうすればいいですか?
- チェックが完了したら、ログイン方法は十分に安全になりますか?
- 何か重要なことを省略していませんか?
何かご質問がありましたら、コメント欄でお知らせください。できる限り多くの情報を提供して質問を編集させていただきます。
ベストアンサー1
ハイジャックすることはできませんコンテンツセッションの。中間者の場合は、同じセッション ID を使用してユーザーとして行動できます。ただし、この問題はあらゆる種類のセッションに当てはまります。
中間者攻撃を防ぎたい場合は、HTTPS を使用する必要があります。
HTTPS を使用すると、次のことが保証されます。
- 攻撃者が誰かのセッションIDを盗んで自分のものとして使うことは事実上不可能なので、セッションは偽物ではありません。
- 同じ理由で、あなたのクッキーは偽物ではありません
- ログイン方法は安全です。送受信されるデータはすべて暗号化されているため、攻撃者がサーバーから送受信されるデータを見たり、変更したり、傍受したりすることは事実上不可能です。
HTTPS の主な欠点は次のとおりです。
- 証明書を購入する必要があります
- 暗号化はネットワークトラフィックとリソース使用量の両方にいくらかのオーバーヘッドを追加します。
- HTTPS経由で送信されたデータはキャッシュされません