2017-11-03 11 views
0

ノード/エクスプレスアプリを構築していて、express-sessionmongo-connectモジュールを使用してセッションを保存し、再起動時にそれらを永続させます。どのように、いつノード/エクスプレスクッキーのシークレットを生成しますか?

ただし、サーバーを再起動するたびに新しいCookie IDが生成されます。私はここでは16文字のランダムに生成された文字列である私のセッションコードである、私のセッションの秘密まで問題を狭めてきました:

app.use(session({         
    secret: dbops.randomString(16), // generate a 16 random char string 
     saveUninitialized: false, 
     resave: true, 
     store: new MongoStore({ 
      db: thisDb, 
      ttl: 14 * 24 * 60 * 60 
     }) 
})); 

を問題は、私のrandomString機能である - 私は、静的な文字列に置き換えるとき私のセッションはサーバーの再起動によって持続します。私のクッキーの秘密はどうすればよいですか?私はちょうど長いランダム化された文字列を選択し、ENV変数に格納する必要がありますか?

私はCookieのSIDがとにかくランダムに生成されるように見えるので、私は文字列の目的にはまだ一般的に混乱していると思います。

答えて

1

典型的なセッションクッキーは、このようなものになります。

s%3Al3ozSdvQ83TtC5RvJ.CibaQoHtaY0H3QOB1kqR8H2A 

をそれはこれより長くなりますが、フォーマットはほとんど同じです。

  • s%3Aは、署名されたクッキーであることを示します。
  • l3ozSdvQ83TtC5RvJはセッションIDです(これはサーバー上のreq.session.idにチェックして確認できます)。
  • CibaQoHtaY0H3QOB1kqR8H2Aが署名です。あなたが署名一般的に

    を生成するために使用されるパスワードのようなビットとしてsecretと考えることができ

、署名は、テキストが正しい場所に由来することを確認するために使用されます。誰かがテキストを改ざんする可能性がありますが、secretがわからないため、正しい署名では署名できません。クッキーのコンテキストでは、クッキーの「起源」はサーバー自体であるため、返されるクッキーは送信されたクッキーと同じものであることを確認する方法を提供します。

しかし、誰かがセッションクッキーを変更すると、データベースのIDと一致しないため、セッションIDがもはやログインしなくなるため、実際には関係のないセッションIDのコンテキストでは、だからなぜ彼らに署名するのを悩ませますか?

ランダムセッションIDを生成することは、実際には非常に困難です。ランダムに見えても、誰かがそれを推測することはまだ可能かもしれません。署名は、この問題を解決するのに役立ちます。「ランダム」IDがあまりランダムではない場合、他のユーザーのセッションIDを推測する誰かを止めるにはどうすればよいですか?

これを仮説的な極端にしましょう。ランダムなセッションIDを使用するのではなく、カウントアップするだけで、最初のセッションはIDが1、次のセッションは2となります。誰かがセッションIDを推測するのは簡単ですが、セッションを乗っ取るだけでは不十分です。彼らはまた、このような何かを得るために、それに署名できるようにする必要があるでしょう:

s%3A432.D5egYRj1G7sJyfbyB7jDh7Gf 

ここでセッションIDが432であると推測することは困難ではないだろうが、ハッカーが行うことができませんでした署名を知らなくてもその知識を持つものだから、たとえあなたが 'ランダム'な部分を推測することができたとしても、シグネチャはクッキー値を推測することを困難にします。

express-sessionについては、secretの名前は秘密にする必要があります。再起動の間に同じままにする必要があります。気づいたとおり、署名はすべて無効になり、古いセッションCookieはすべて拒否されます。要求が常に同じノードに送信されるという保証がないため、クラスター内のノード間でも同じ値を設定する必要があります。

secretの代わりに使用できるkeysの設定にも注意する必要があります。 keysを使用すると、既存のすべてのセッションをただちに無効にすることなく、シグニチャの生成に使用されるsecretを変更できます。アイデアは、キーの配列(秘密)を指定することです。最初の署名のみが署名の生成に使用されますが、すべてのエントリはクッキーの受信署名のチェックに有効です。アイデアは、単に古い秘密を必要とする限りアレイに含めることができ、セッションが使用されていないと確信したら削除することができます。

長い乱数化された文字列を1つだけ選択してENV変数に格納する必要がありますか?

かなりです。それは夢中にする必要はありませんが、誰かが推測するのが難しい必要があります。これはパスワードのようなものですが、覚えておく必要がないという利点があります。理想的には、コードの中で生産に使用されているsecretを保持し、環境変数を使用することは、それを達成する1つの方法です。

+0

この非常に徹底した消化可能な回答には十分に感謝することはできません。私は数時間にわたりグーグルで語っています。これは私が見つけた最も適切な説明です。ありがとうございました! –

関連する問題