¿Cuándo deben usarse las sesiones del lado del servidor en lugar de las sesiones del lado del cliente?

  

Por ejemplo, ¿es seguro colocar un token csrf en una cookie del lado del cliente, ya sea que esté cifrada o no?

Sí. OWASP llama a este método Double Submit Cookies . Aunque nunca lo he visto en la práctica.

La razón por la que esto es seguro es que los tokens CSRF son valores temporales. Por ejemplo, si almacena una contraseña cifrada en una sesión del lado del cliente, eso sería bastante malo (dependiendo de la clave y del cifrado). Un atacante puede robarlo, descifrarlo y luego tener la contraseña del usuario. Para el token CSRF, un atacante no gana nada. Además, no afecta la seguridad del servidor si un atacante o usuario cambia la cookie, todo lo que sucederá es que el token no funciona.

  

¿en qué circunstancias no sería seguro almacenar los datos de la sesión en la cookie?

Hay dos cosas de las que preocuparse aquí:

• Un usuario o atacante puede cambiar los datos en la cookie y el servidor no tendría idea de que esto sucedió, aceptando los datos modificados (por ejemplo, puede contener un valor como isAdmin:0 , que puede cambiarse a isAdmin:1 ).
• La cookie puede contener información confidencial que un usuario o atacante puede leer

Para resolver el primer punto, se puede usar un MAC, para resolver el segundo punto, los datos de las cookies deben estar cifrados.

Antes de crear sesiones del lado del cliente, debe preguntarse si realmente lo necesita (lo que puede ser el caso si tiene varios servidores que necesitan compartir el mismo estado de sesión, por ejemplo, por razones de escalabilidad). Los datos de sesión se manejan tradicionalmente en el lado del servidor por una razón: contiene datos que el cliente no debería poder leer o cambiar. Es más fácil hacerlo simplemente no enviándolo al cliente.

Configurar un sistema complejo para almacenar el lado del cliente de datos de sesión es difícil, y muchas cosas pueden salir mal al hacerlo. Si no es necesario, simplemente almacene el lado del servidor de datos.

  

¿Cuándo deberían habilitarse las sesiones del lado del servidor en lugar del lado del cliente?   sesiones?

No puedo pensar en una situación en la que quieras algo del lado del cliente que no sea la "experiencia de usuario".

Los identificadores de sesión siempre deben estar del lado del servidor porque el servidor debe validar si la sesión es válida o no.

  

¿Es seguro colocar un token CSRF en una cookie del lado del cliente, ya sea   cifrado o no?

Un token anti CSRF debe contener datos generados aleatoriamente, esto es mucho más "barato" que generar una cadena cifrada, siempre que la cadena sea lo suficientemente larga y aleatoria.

No creo que almacenar el token anti CSRF en una cookie sea suficiente.

Recomiendo crear un sistema en el que se envíe un token anti CSRF desde un campo de entrada oculto y se transmita en el encabezado. Ambos deben verificarse en el lado del servidor.

Aquí hay un ejemplo en PHP:

function generateToken($key) {
  $token = base64_encode(openssl_random_pseudo_bytes(16));
  $_SESSION['csrf_' . $key] = $token;
  return $token;
}


function checkToken($key, $value) {
  if (!isset($_SESSION['csrf_' . $key]))
    return false;
  if (!$value)
    return false;
  if ($_SESSION['csrf_' . $key] !== $value)
    return false;

  unset($_SESSION['csrf_' . $key]);
  return true;
}


  if ($_POST and $_POST['action'] == "something")
  {
    $header_token = apache_request_headers()['X-Anti-Csrf-Token'];
    $post_token = $_POST['token'];
    $post_token = str_replace(" ", "+", $post_token);

    if ($header_token == $post_token)
    {
        if (checkToken('settings', $post_token))
        {   
           // ok; do something

        }
     }
     else
     { 
         // wrong; do something
     }


 }

Enviando el encabezado antes de procesarlo:

   <script>
    $("#some_div").submit(function(event) {
      event.preventDefault();

      var $form = $(this),
        url = $form.attr('action');

      var posting = $.ajax(url, {
        type: 'POST',
        processData: true,
        dataType: "text",
        beforeSend: function (xhr) {
        xhr.setRequestHeader('X-Anti-CSRF-Token', $('#token').val());
    }

Este fragmento de código generará el token y lo colocará en un campo de entrada oculto.

<input id="token" type="hidden" value="<?php echo generateToken('settings'); ?>">