php - romualdfons - romualfons

Importancia de la clave secreta de sesión en el marco web Express

Question

Estoy bastante confundido por la importancia de un secreto de sesión . Estoy incursionando en el desarrollo web con Express y Node, y por el momento, intento implementar un inicio de sesión simple. El siguiente código se toma del ejemplo de sesiones en 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());

Utiliza "keyboard cat" como secreto de sesión. Muchas de las cosas que he visto sobre secretos de sesión me recomiendan que cambie esto a algo personalizado. Ahora tengo 3 preguntas específicas sobre esto.

1. ¿Por qué no he visto esto antes cuando estaba trabajando con PHP?
2. ¿Para qué se usa el secreto de la sesión exactamente?
3. Digamos que cambio la clave de la sesión. Mi código es de código abierto. ¿No va a cambiar esto ser un poco redundante en ese caso? No veo pidiendo al usuario una clave personalizada como una opción.
4. Estaba pensando en generar un UUID aleatorio para completar la clave. ¿Hay problemas con esto? (en términos de seguridad)

Answer 1

1. Porque PHP no es Nodejs. La gestión de sesiones en PHP es diferente de la gestión de sesiones en el nodo: el nodo nunca muere, a diferencia de PHP, que el daemon del servidor invoca constantemente (Apache, IIS, qué es lo que tiene), le pide que genere algún contenido y finaliza su proceso. El nodo es el equivalente de Apache más PHP.
2. Se usa para encriptar la cookie de sesión para que pueda estar razonable (pero no 100%) seguro de que la cookie no es falsa, y la conexión debe tratarse como parte de la sesión más grande con express.
3. Es por eso que no colocas la cadena en tu código fuente. Lo convierte en una variable de entorno y lo lee en process.env ("SESSION_SECRET") o utiliza un archivo .env con https://npmjs.org/package/habitat , y se asegura de que esos archivos nunca toquen su repositorio (svn / git exclusion / lo ignora) para que sus datos secretos permanezcan en secreto.
4. el secreto es inmutable mientras se ejecuta su aplicación de nodo. Es mucho mejor crear una oración larga y divertida que un UUID, que generalmente es mucho más breve que "I didn''t think I needed a secret, but the voices in my head told me Express needed one" .

Cómo uso las sesiones:

archivo .env (siempre en mi archivo .gitignore para que nunca llegue a mis repositorios públicos):

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());

Ese bit de CSRF asegura que las solicitudes de página provengan de su propio sitio, no las solicitudes de cURL o las incrustaciones en los sitios web de otras personas. http://expressjs.com/api.html#csrf para obtener más información sobre eso.

Answer 2

Creo que el punto principal se pierde en las otras respuestas, que es si el parámetro secret está haciendo que la administración de la sesión sea más segura. se discute muy bien en esta pregunta de Security.StackExchange: ¿Por qué no es seguro almacenar la ID de sesión en una cookie directamente?

Recomiendo leerlo (no solo la respuesta más votado allí es relevante).

Intentando resumirlo: no reducirá significativamente las posibilidades de que una sesión sea adivinada y secuestrada en caso de que los ID de sesión sean números aleatorios grandes, pero obviamente ayudará mucho si los ID de sesión son personalizados como el incremento de ID, que es posible en ExpressJS .

Los usuarios pueden usar cualquier ID de sesión que deseen. Quizás alguien sienta que debería usar un número de aumento automático de la base de datos SQL, no importa, porque protegemos su decisión desinformada al firmar el valor, alargando la clave.

Answer 3

Mi confusión fue entre las sesiones del lado del servidor y las sesiones del lado del cliente. Antes de hoy, no sabía nada del lado del cliente. Una explicación clara de la diferencia se encuentra a continuación.

¿Por qué la sesión de CherryPy no requiere una clave secreta?

Pensando en el modelo del lado del servidor, estaba muy confundido donde se requeriría el cifrado en las sesiones.