Важность секретного ключа сеанса в веб-среде Express Web

Я очень смущен важностью секретности сеанса . Я вскакиваю в веб-разработку с помощью Express и Node, и на данный момент я пытаюсь реализовать простой логин. Нижеприведенный код берется из примера сеансов в Express.

// Required by session() middleware // pass the secret for signed cookies // (required by session()) app.use(express.cookieParser('keyboard cat')); // Populates req.session app.use(express.session()); 

Он использует «клавиатурную кошку» как секрет сеанса. Многие из вещей, которые я оглядывал вокруг секретов сессии, рекомендую мне изменить это на что-то обычай. Теперь у меня есть 3 конкретных вопроса.

  1. Почему я не видел этого раньше, когда работал с PHP?
  2. В чем секрет секретности сеанса?
  3. Скажем, я меняю ключ сеанса. Мой код с открытым исходным кодом. Не изменится ли это в этом случае немного избыточно? Я не вижу, чтобы пользователь запрашивал пользовательский ключ в качестве опции.
  4. Я подумывал создать случайный UUID для заполнения ключа. Есть ли проблемы с этим? (с точки зрения безопасности)

Solutions Collecting From Web of "Важность секретного ключа сеанса в веб-среде Express Web"

Я думаю, что в других ответах основной вопрос отсутствует, а именно, является ли secret параметр более безопасным для управления сеансом. он хорошо обсуждается в этом вопросе Security.StackExchange: почему не удается сохранить идентификатор сеанса в cookie напрямую?

Я рекомендую прочитать его (не только главный проголосовавший ответ есть).

Пытаясь подвести итог: это не приведет к существенному уменьшению шансов на угадание и захват сеанса в случае, если идентификаторы сеанса представляют собой большие случайные числа, но, очевидно, это значительно поможет, если идентификаторы сеансов являются обычными, например, инкрементными идентификаторами, что возможно в ExpressJS .

Пользователи могут использовать любые идентификаторы сеансов, которые они хотят. Возможно, кому-то кажется, что они должны использовать автоматически увеличивающийся номер из базы данных SQL, это не имеет значения, потому что мы защищаем их неосведомленное решение, подписывая значение, удлиняя ключ.

  1. Поскольку PHP не является Nodejs. Управление сеансом в PHP отличается от управления сеансом в узле: узел никогда не умирает, в отличие от PHP, который постоянно вызывается вашим демоном сервера (apache, IIS, что у вас есть), попросил сгенерировать некоторый контент, а затем завершить его процесс. Узел является эквивалентом Apache plus PHP.
  2. Он используется для шифрования файла cookie сеанса, поэтому вы можете быть достаточно (но не на 100%) уверенным, что файл cookie не является поддельным, и соединение должно рассматриваться как часть более крупного сеанса с выражением.
  3. Вот почему вы не помещаете строку в свой исходный код. Вы делаете его переменной окружения и читаете его как process.env («SESSION_SECRET») или используете .env файл с https://npmjs.org/package/habitat и убедитесь, что эти файлы никогда не касаются вашего репозитория (svn / git исключение / игнорирует), так что ваши секретные данные остаются секретными.
  4. секрет является неизменным при запуске вашего приложения-узла. Гораздо лучше просто придумать длинное смешное предложение, чем UUID, который, как правило, намного короче, чем "I didn't think I needed a secret, but the voices in my head told me Express needed one" .

Как я использую сеансы:

.env (всегда в моем файле .gitignore, чтобы он никогда не попадал в мои публичные репозитории):

 SECRET="This is my funky secret oh my god it has ninja turtles" 

app.js:

 var express = require('express'), env = (function(){ var Habitat = require("habitat"); Habitat.load(); return new Habitat(); }()), app = express(); app.use(express.compress()); // gzip all the things. If possible. app.use(express.bodyParser()); app.use(express.cookieParser()); app.use(express.cookieSession({ key: "mysite.sid", // seeing this tells you nothing about the actual secret: secret: env.get("SESSION_SECRET"), cookie: { maxAge: 2678400000 // 31 days } })); app.use(express.csrf()); 

Этот бит CSRF гарантирует, что запросы страниц поступают с вашего собственного сайта, а не cURL-запросы или внедряются на сайты других людей. http://expressjs.com/api.html#csrf для получения дополнительной информации об этом.

Моя путаница заключалась в сеансах на стороне сервера и на клиентских сессиях. До сегодняшнего дня я не знал о стороне клиента. Ниже приводится четкое объяснение разницы.

Почему сеанс CherryPy не требует секретного ключа?

Думая о модели на стороне сервера, я был очень смущен, когда в сеансах требуется шифрование.