Quando dovrebbero essere utilizzate sessioni lato server invece delle sessioni lato client?

7

Dal punto di vista della sicurezza delle informazioni, quando dovrebbero essere abilitate le sessioni lato server invece delle sessioni lato client?

Da quanto ho capito, le "sessioni lato client sicure" sono cookie che contengono dati firmati in modo tale che l'utente può "guardare" il contenuto, ma non può modificarli senza che il server lo sappia. Sono un po 'confuso sul fatto che ciò implichi che i contenuti dei cookie siano crittografati, o che i contenuti siano leggibili dall'uomo. Flask, per esempio , crittografa i dati. Se i dati sono crittografati, in quali circostanze non sarebbe sicuro memorizzare i dati di sessione nel cookie? Ad esempio, è sicuro inserire un csrf-token in un cookie lato client, indipendentemente dal fatto che sia crittografato o meno?

D'altro canto, una "sessione lato server" ha due parti: un cookie contenente solo un ID di sessione e una voce di database contenente l'ID di sessione e i dati. In questa implementazione, l'utente non può accedere ai dati della sessione.

    
posta Matthew Moisen 25.02.2016 - 07:32
fonte

2 risposte

7

For example, is it safe to put a csrf-token in a client side cookie, whether it is encrypted or not?

Sì. OWASP chiama questo metodo Double Submit Cookies . Non l'ho mai visto in pratica però.

Il motivo per cui questo è sicuro è che i token CSRF sono valori temporanei. Ad esempio, se si memorizzasse una password crittografata in una sessione lato client, ciò sarebbe piuttosto negativo (a seconda della chiave e della crittografia). Un utente malintenzionato potrebbe essere in grado di rubarlo, decodificarlo e quindi avere la password dell'utente. Per il token CSRF, un utente malintenzionato non guadagna nulla. Inoltre, non influisce sulla sicurezza del server se un utente malintenzionato o utente modifica il cookie, tutto ciò che accadrà è che il token non funziona.

in what circumstances would it not be safe to store session data in the cookie?

Ci sono due cose di cui preoccuparsi qui:

  • Un utente o un utente malintenzionato potrebbe modificare i dati nel cookie e il server non avrebbe idea di ciò, accettando i dati modificati (ad esempio, potrebbe contenere un valore come isAdmin:0 , che può essere modificato in isAdmin:1 ).
  • Il cookie potrebbe contenere informazioni riservate che un utente o un utente malintenzionato potrebbe leggere

Per risolvere il primo punto, è possibile utilizzare un MAC, per risolvere il secondo punto, i dati dei cookie devono essere crittografati.

Prima di creare sessioni lato client, dovresti chiederti se ne hai davvero bisogno (il che potrebbe essere il caso se hai più server che devono condividere lo stesso stato di sessione, ad esempio per motivi di scalabilità). I dati di sessione vengono tradizionalmente gestiti lato server per un motivo: contiene dati che il client non dovrebbe essere in grado di leggere o modificare. È più facile da fare semplicemente non inviarlo al client.

L'impostazione di un sistema complesso per archiviare il lato client di sessione è difficile e molto potrebbe non funzionare correttamente. Se non è necessario, salva il lato del server di dati.

    
risposta data 25.02.2016 - 10:15
fonte
2

When should server side sessions be enabled instead of client side sessions?

Non riesco a pensare a una situazione in cui vorresti qualcosa di lato client diverso da "user experience".

Gli identificativi di sessione dovrebbero sempre essere lato server, in quanto il server dovrebbe convalidare se la sessione è valida o meno.

Is it safe to put a CSRF-token in a client side cookie, whether it is encrypted or not?

Un token anti-CSRF dovrebbe contenere dati generati casualmente, questo è molto "meno costoso" di generare una stringa crittografata, purché la stringa sia lunga e abbastanza casuale.

Non penso che sia sufficiente memorizzare il token anti-CSRF in un cookie.

Suggerirei di creare un sistema in cui un token anti-CSRF viene inviato da un campo di input nascosto e viene trasmesso nell'intestazione. Entrambi dovrebbero essere controllati sul lato server.

Ecco un esempio in 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
     }


 }

Invio dell'intestazione prima dell'elaborazione:

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

Questo pezzo di codice genererà il token e lo inserirà in un campo di input nascosto.

<input id="token" type="hidden" value="<?php echo generateToken('settings'); ?>">
    
risposta data 25.02.2016 - 08:08
fonte

Leggi altre domande sui tag