2012-01-04 10 views
13

私は、フレームワークがセッションIDをアプリケーションキーでハッシュすることでセッション固定の問題を解決しているが、セッションハイジャックを防ぐためのメカニズムを提供しているのか、それとも実装者に委ねられているのか、Play!フレームワークにはセッションハイジャックを防ぐためのメカニズムが組み込まれていますか?

+0

これまでのところ私は「はい」と「いいえ」を持っていますので、明らかに矛盾した情報があります。 – marchaos

+0

私はまだこの質問には答えられていないと感じていますが、残念ながら私はいかなる場合でも賞金を授与しなければなりません。誰かが決定的な答えを返すことができれば、それは素晴らしいだろう。 – marchaos

答えて

3

プレイのドキュメントにはセキュリティに関するセクションがありますので、重複するのではなく、ここにリンク - http://www.playframework.org/documentation/1.2.4/securityがあります。

それは

  • XSS
  • SQLインジェクション
  • セッションセキュリティ
  • クロスサイトリクエストフォージェリ

あなた自身を実装する必要がいくつか、そうでない人をカバーしています。

セッションハイジャックに関する特定の質問は自動です。

セッションは署名されていても暗号化されていないキー/値のハッシュです。その は、あなたの秘密が安全である限り、 サードパーティがセッションを偽造することはできません。

+0

答えをありがとう。私は本当にキー値をハッシュする方法を見ていないし、アプリケーションキーに署名することは、誰かがあなたのクッキーを盗んでそれを使用するのを防ぎます。おそらく私は何かを欠いているでしょうか? – marchaos

+0

誰かがそれを改ざんするとハッシュを知らないので、ハッシュ値が無効になり、Playはセッションが無効になったことを知るためです。 – Codemwnci

+2

改ざんをしないとどうなりますか?あなたのクッキーを嗅ぎ、その中の値を変更しないと、ハッシュがまだ有効なので(クッキーに保存されていると仮定して)、あなたの値を使って認証できます。 – marchaos

3

いいえ、セッションCookieをキャプチャできるとすぐにセッションのハイジャックを防止する方法はありません(途中でスニッフィング/マンを通じて)。 は、例えば、にはいくつかの方法がそれは難しくあります

  • HTTPSのみ
  • application.session.httpOnlyの設定を使用してapplication.conf

でそれが難しくする一つのapproacheは以下のとおりです。 - あなたのサイトにアクセスしているユーザーが同じハッシュを作り直しているかどうかをあなたのコントローラにチェックすると、セッション内にもip/user-agent/resolution/other stuffまたはそのハッシュを保存します。プロキシを使用している人がいるクラスタリングのためにオンザフライでipを変更します。あなたが使用することを試みることができる

少しトリック:(最近のブラウザでのみ動作します) ユーザがログインすると、HTML5のローカルストレージにいくつかのものを格納します。 Ajax呼び出しを修正して、ローカルストレージからこの情報を提供してください。情報が欠落しているか無効である場合は、セッション全体を無効にすることができます。しかし、チェックはHTML5ブラウザからのリクエストに対してのみ適用されることを確認する必要があります。

これはちょっと役立ちます。

+0

ipとユーザエージェントを格納するのは悪い考えです。 http://stackoverflow.com/questions/969330/including-user-ip-addr-for-hash-cookie-value-bad-idea – marchaos

+0

あなたは私が言ったことをリンクアドレスにしている "唯一の本当の問題はクラスタリングのために即座にipを変更するプロキシを使用している人々」 ユーザエージェントのハッシュを保存することは何もありません。セッション中にそれが変更されると、セッションがハイジャックされるためです。 これはどれくらいのエネルギーをあなたがこれに当てはめるのか、それが本当に価値があるのか​​によって決まります。 機密データの変更/削除は、SSLを介してのみ可能で、パスワードを提供することによってのみ可能です。 –