13

私のアプリでは、zentask に示されているものと同じセキュリティを実装しています。

public class Secured extends Authenticator {

@Override
public String getUsername(Context ctx) {
    return ctx.session().get("email");

}

@Override
public Result onUnauthorized(Context ctx) {
    ctx.flash().put("error", "please login to proceed");
    return redirect(routes.Application.index());
}

}

ユーザーが認証されると isuser session().put("email", email);

2 つの問題があります。最初:ユーザーがログアウトを使用せずにアプリを離れたときにセッションを無効にする方法は? 2番目のより深刻な問題は、Firefoxプラグインcookies manager+を使用してCookieを調べたことです。Cookieをコピーして後で貼り付けることができるため、最初にログインしなくてもメソッドにアクセスできます。基本的にセッションを盗むことができます

4

4 に答える 4

40

Play フレームワークはステートレス セッションを使用します。サーバー側に保存される状態はなく、すべての状態がセッション Cookie に保存されます。セッションを検証するために、Play は秘密鍵を使用してセッションに署名し、セッション cookie を含むリクエストが到着したときに署名を検証します。ユーザーがセッション データを改ざんした場合 (たとえば、セッションのメール アドレスを別のユーザーのメール アドレスに変更した場合)、署名が一致しないため、Play はセッション cookie を拒否します。

はい、Cookie をコピーして後で使用できます。ただし、Cookie を変更することはできません。これは、「盗む」ことができる唯一の Cookie は自分のものであることを意味しますが、自分から盗むことは実際には盗むことではありません。いいえ、XSS などの他の脆弱性を利用しない限り、セッションを盗むことはできませんが、セッション トークンもこれに対して脆弱です。

デフォルトでは、Play は「セッション」Cookie、つまりブラウザを閉じると有効期限が切れる Cookie を作成するように設定されています。したがって、ユーザーがブラウザを終了すると、ブラウザはすべてのセッション Cookie を削除し、ユーザーはログインしなくなります。これは、セッション トークンについても同じです。

注意すべき考慮事項が 1 つあります。それは、サーバーが状態を保持するため、セッション トークンもサーバーで期限切れになることです。Play で使用されるようなステートレスな署名付きセッションはそうではありません。ただし、セッションの作成時にタイムスタンプをセッション内に保存し、そのタイムスタンプが getUsername() メソッドで構成された有効期限よりも古いものではないことを確認することで、有効期限メカニズムを自分で実装できます。タイムスタンプは署名されたセッションに保存されるため、署名を変更しない限りタイムスタンプを改ざんすることはできないため、この単純なメカニズムは非常に安全です。より高度な解決策は、リクエストが来るたびにそのタイムスタンプを更新するフィルターを実装して、ユーザーがログインしたときではなく、最終アクセスに基づいて有効期限が切れるようにすることです。

于 2013-08-06T02:23:35.770 に答える
7

Zentask の例に従って、サーバー上のセッションを無効にすることはできません。セッション Cookie は構成ファイルの秘密鍵で署名されますが、同じ値から同じ署名付き Cookie が生成されます。すでにわかっているように、誰かがユーザーから Cookie を盗んだ場合、ユーザーもあなた (サーバー) も、泥棒がユーザーのアカウントに「ログイン」するのを防ぐことはできません。

現在、基本的に 2 つのオプションがあります。

  1. ユーザーに関して既に持っている揮発性の情報を Cookie に保存します。この情報は、あなたとユーザーだけが知っていて、随時変更されます。例は、パスワード ハッシュの一部です。ユーザーがパスワードを変更すると、その情報は無効になり、古いセッション Cookie はすべて無効になります。この方法の欠点: ユーザーが保存された情報を変更しない場合、Cookie は長期間、場合によっては永久に有効になります。
  2. サーバー側のセッション管理を作成します。このためには、データベース、キー値キャッシュなどを用意する必要があります。そこには、セッション用にランダムに生成された (暗号的に安全な) キー、ユーザーの名前/ID、およびセッションが自動的に無効になる日付を保存します。Cookie 盗用に対するセキュリティを向上させるために、IP アドレスを保存することもできます。次に、セッション キーを Cookie に書き込む必要があります。ユーザーがログアウト ボタンをクリックすると、現在のセッション (または、このユーザーのすべてのセッション) が無効になります。
于 2013-05-12T14:38:20.613 に答える
4

  • セッション ID を生成するモジュールを 1 つ用意することをお勧めします。このモジュールでは、createSessionId() などのメソッドを使用できます。このメソッドで保持するセッション ID を生成するロジック。

  • (userId + providerId(Facebook/Google-OAuth/UsernamePassword/Any Provider の場合) + 現在のタイムスタンプ + UUID) の組み合わせとしてセッション ID を作成し、このセッション ID を作成した後、いくつかのアルゴリズムで暗号化します。これにより、セッションIDが得られます

  • これによる利点は次のとおりです。

    • セッション ID の生成には時間がかかりますが、だれもそれを理解できません。
    • 別の利点は、 createSessionId() メソッドでいつでもセッション ID を作成 する暗号化ロジック/戦略を変更できることです。

  • Playframework のセッションに関するもう 1 つの問題は、セッションの有効期限がないことです。
    • これを処理するために、ユーザーがログインするとすぐに、タイムスタンプをセッションに保存できます。
    • リクエストごとに、セッションのタイムスタンプを確認します。タイムスタンプが 30 分前よりも大きい場合は、セッションを無効にします。タイムスタンプが 30 分以内の場合は、セッションのタイムスタンプを現在のタイムスタンプとして更新します
于 2013-07-21T16:23:22.640 に答える
4

単純にユーザー ID を Cookie に入れることは、まったくセキュリティではありません。ご指摘のとおり、Cookie の値は誰でも発明できます。

セッション:代わりに、Cookie に任意の (ランダムなどの) 値を入れてから、サーバーでマッピング テーブル内のユーザーの ID を検索する必要があります。この任意の値は頻繁に変更する必要があるため、通常、ログイン セッションは 30 分間持続します。ログインごとに新しい任意の値が提供され、その値はセッション ID と呼ばれます。

無効化:セッションは、一定期間 (たとえば 30 分間) 要求がない場合、ルックアップ テーブル (サーバー側) からそのエントリを削除することによって無効化されます。テーブルにないセッション ID を持つすべてのリクエストは、認証されていないリクエストのように扱われ、再度ログインするよう求められます。ユーザーがログアウトを忘れても問題ありません。

ハッキング:値は任意であるため、将来のセッション ID がどうなるかをハッカーが事前に知る方法はありません。セッション盗用に対しては依然として脆弱ですが、それははるかに困難です。ハッカーは、セッション ID が使用されているときにのみそのセッション ID を見つける必要があり、その後、特定の時間だけ使用できます。これを防ぐために、特定の IP アドレスからの特定のセッションのリクエストのみを許可するなど、いくつかの手順を実行できます。また、すべてのリクエストでもセッション ID をすばやく循環させることができますが、これにはマイナス面もあります。一般に、ログインごとに一意のセッション ID を提供することで、特にこれが HTTPS 経由で行われる場合は、ほとんどの認証ニーズに十分対応できます。

永続性:特定のセッション期間 (30 分など) で同時ユーザーの数が少ない場合は、必ずしもこれをデータベースに入れる必要はありません。これをメモリに維持することはオーバーヘッドが少ないですが、サーバーを循環させると、すべてのユーザーが再度ログインする必要があるという欠点があります。セッション ID をデータベースに入れる場合は、サーバーの起動時にすべての古いセッションを消去できることを確認する必要があります。

ユーザー情報:ユーザーの電子メール アドレスを Cookie に入れることにはまだ価値がありますが、ログインするための「デフォルト」ユーザー ID としてのみ使用されます。これは、ユーザーが認証されていることを示すものではなく、ユーザーの便宜のためにのみ扱われるべきです。

于 2013-05-12T14:38:05.470 に答える