1

Playがクライアント側でセッションデータを保持していることを読みました。

セッションとフラッシュのデータはサーバーに保存されないが、Cookieを使用して後続の各HTTPリクエストに追加されることを理解することが重要です。これは、データサイズが非常に制限されており（最大4 KB）、文字列値のみを保存できることを意味します。

私はWEBの経験がないので、いくつか質問があります。

1）安全ですか？

2）この種のセッションで機密データを保存することはどの程度合理的ですか？

クライアントがリクエストデータを変更することは可能です（セッションIDなしでセッションデータを変更します）。そのような状況の影響を防ぐためにPlayに組み込まれたメカニズムはありますか？クライアントがセッションデータを変更し、リクエストサーバーがこのデータを読み取ろうとした後はどうなりましたか？

Cookieは秘密鍵で署名されているため、クライアントはCookieデータを変更できません（または無効になります）。

しかし、それはどういう意味ですか？クライアントがセッションデータを変更すると仮定します。次の後にサーバー側で何が起こったのか：

String foo = session(bar)

fooはnullになりますか？ジャンクランダム文字列？例外がスローされますか？

4

1 に答える 1

4

セッションに対するこの「RESTful」アプローチは、十分に安全です。セッションを管理するためのより安全で高速なアプローチがあるという問題。

Cookieはおそらく署名されていません。これに非対称暗号を使用すると、リソースが大幅に浪費されます。Cookieがハッシュメッセージ認証コードまたはHMACで保護されている可能性が高くなります。開発者がHMACを「署名」と呼んでいると考える場合、その単語の使用法が明らかに間違っているため、セキュリティ上の大きな問題が発生する可能性があります。

HMACをセッションIDとして使用する場合の最大のセキュリティ問題は、単一の秘密鍵を使用してすべてのセッションを構築している可能性があることです。この秘密鍵は、必要に応じて何年にもわたって、マシンのクラスターを使用してブルートフォースオフラインにすることができます。あなたの秘密が巨大で、最低限でも約1,024バイトであることを確認してください。ディレクトリトラバーサルまたは別の攻撃を使用してこの秘密鍵をファイルから読み取ることができる場合、攻撃者は自由に独自のセッション状態を構築でき、完全な侵害につながる可能性があります。

最も安全なセッションIDは大きなランダム値であり、おそらく32バイトで十分です。この番号は、データベースからセッション状態を取得するために使用されます。できれば、memcachedのようなローカルネットワークでホストされている非常に高速な非リレーショナルデータベースから。

パフォーマンスの観点から、セッションへのHMACアプローチは、HTTPリクエストごとに追加の帯域幅を消費するため望ましくありません...したがって、すべてのhttpリクエストの速度が低下し、クライアントリソースとWebサーバーの帯域幅が消費されます。

リクエストを満たすために必要な最小値のみを送信する必要があります。複雑さはセキュリティの敵であり、大きなランダム値は非常に単純です。

于 2013-01-10T17:30:19.170 に答える