私は、フレームワークがセッションIDをアプリケーションキーでハッシュすることでセッション固定の問題を解決しているが、セッションハイジャックを防ぐためのメカニズムを提供しているのか、それとも実装者に委ねられているのか、Play!フレームワークにはセッションハイジャックを防ぐためのメカニズムが組み込まれていますか?
答えて
プレイのドキュメントにはセキュリティに関するセクションがありますので、重複するのではなく、ここにリンク - http://www.playframework.org/documentation/1.2.4/securityがあります。
それは
- XSS
- SQLインジェクション
- セッションセキュリティ
- クロスサイトリクエストフォージェリ
あなた自身を実装する必要がいくつか、そうでない人をカバーしています。
セッションハイジャックに関する特定の質問は自動です。
セッションは署名されていても暗号化されていないキー/値のハッシュです。その は、あなたの秘密が安全である限り、 サードパーティがセッションを偽造することはできません。
いいえ、セッションCookieをキャプチャできるとすぐにセッションのハイジャックを防止する方法はありません(途中でスニッフィング/マンを通じて)。 は、例えば、にはいくつかの方法がそれは難しくあります
- HTTPSのみ
- application.session.httpOnlyの設定を使用してapplication.conf
でそれが難しくする一つのapproacheは以下のとおりです。 - あなたのサイトにアクセスしているユーザーが同じハッシュを作り直しているかどうかをあなたのコントローラにチェックすると、セッション内にもip/user-agent/resolution/other stuffまたはそのハッシュを保存します。プロキシを使用している人がいるクラスタリングのためにオンザフライでipを変更します。あなたが使用することを試みることができる
少しトリック:(最近のブラウザでのみ動作します) ユーザがログインすると、HTML5のローカルストレージにいくつかのものを格納します。 Ajax呼び出しを修正して、ローカルストレージからこの情報を提供してください。情報が欠落しているか無効である場合は、セッション全体を無効にすることができます。しかし、チェックはHTML5ブラウザからのリクエストに対してのみ適用されることを確認する必要があります。
これはちょっと役立ちます。
ipとユーザエージェントを格納するのは悪い考えです。 http://stackoverflow.com/questions/969330/including-user-ip-addr-for-hash-cookie-value-bad-idea – marchaos
あなたは私が言ったことをリンクアドレスにしている "唯一の本当の問題はクラスタリングのために即座にipを変更するプロキシを使用している人々」 ユーザエージェントのハッシュを保存することは何もありません。セッション中にそれが変更されると、セッションがハイジャックされるためです。 これはどれくらいのエネルギーをあなたがこれに当てはめるのか、それが本当に価値があるのかによって決まります。 機密データの変更/削除は、SSLを介してのみ可能で、パスワードを提供することによってのみ可能です。 –
これまでのところ私は「はい」と「いいえ」を持っていますので、明らかに矛盾した情報があります。 – marchaos
私はまだこの質問には答えられていないと感じていますが、残念ながら私はいかなる場合でも賞金を授与しなければなりません。誰かが決定的な答えを返すことができれば、それは素晴らしいだろう。 – marchaos