È un'implementazione insicura di sessioni multi-sito?

Question

È un'implementazione insicura di sessioni multi-sito?

#1 da (1 voti)

0

Ho un Magento multi-sito (una piattaforma eCommerce PHP). Gli account sono condivisi tra i siti, ma le sessioni non lo sono, quindi è necessario accedere a ciascun sito individualmente. Sono interessato a condividere queste sessioni.

Ho trovato una risposta sullo scambio di stack Magento. Condivisione di sessioni tra negozi con domini diversi . La raccomandazione è questa:

cookies.php

setcookie("frontend", htmlspecialchars($_GET['SID']), time() + 86400);

example1.com

<?php $sessionId = Mage::getSingleton('core/session', array('name' => 'frontend'))->getSessionId(); ?>
<img src="https://example2.com/cookie.php?SID=<?phpecho$sessionId;?>" style="display:none;" />

Sto cercando di comprendere le implicazioni di sicurezza di tutto questo. Se non sbaglio, questo URL diventa tutto ciò che è necessario per accedere come utente.

Tutti i nostri siti sono solo HTTPS, quindi penso che questo aiuti a impedire a chiunque stia ascoltando sul traffico di ottenere questo URL, corretto?

Un problema che potrei vedere è che se qualcuno è al computer fisico, avrebbe accesso a tale URL e potrebbe usarlo per accedere da un computer diverso, che altrimenti sarebbe impossibile senza la password. Scadere la sessione impedisce contro quello, però, giusto? Se è così, le sessioni sono al momento piuttosto lunghe, quindi i carrelli rimangono in vita più a lungo, quindi quanto dovrebbero essere brevi le sessioni?

In breve, Si tratta di un'implementazione non sicura di sessioni di accesso a più siti? In tal caso, questo approccio può essere reso sicuro?

authentication session-management

posta Goose 30.11.2017 - 21:03

fonte

1 risposta

Leggi altre domande sui tag authentication session-management

Funziona con token e sessioni utente [chiuso] Una sola password con token hardware

score 1 · Accepted Answer

Molti sistemi SSO funzionano in questo modo. Ma c'è un po 'più di un paio di linee di codice, in particolare:

utilizza i cookie per le sessioni con i soliti flag httponly e secure
quando viene ricevuta una richiesta per un servizio autenticato ma senza una sessione valida, reindirizza l'utente al SSO (questo richiede una certa gestione speciale attorno a POST e DELETE / PUT / PATCH se usato)
se una sessione esiste già sull'SSO o sull'autenticazione utente pass-user, reindirizza l'utente a una pagina di destinazione speciale nell'applicazione con un token nell'URL (perché questo è l'unico modo educato per ottenere dati tra domini)
nella pagina di destinazione, stabilisce un collegamento alla sessione, imposta il cookie di sesison e reindirizza alla pagina richiesta originariamente (nota che alcuni browser meno recenti ignoravano i cookie impostati in una risposta 302)

HTTPS [...] helps prevent anyone listening in on traffic from getting this URL, correct?

La parola chiave qui è "aiuta". Non impedisce all'URL di apparire nella cronologia.

so how short should the sessions be?

Cercare di risolvere un problema di perdita del cookie di sessione accorciando il timeout della sessione non è la strada giusta da percorrere. Un approccio migliore prevede che l'SSO restituisca un token monouso che l'applicazione può utilizzare per risolvere la sessione o autenticare l'accesso alla sessione, ad es. (su SSO)

if (authenticated()) {
    $secretsid=encrypt(session_id(), SERVERSIDEPASSWORD);
    $_SESSION['otp']=uniqid();
    $return_url=add_get_arg($app_landing_url, array(
      'secretsid'=>$secrestsid,
      'OTP='=>$_SESSION['otp'],
      'original_requested_url'=>$originally_requested_url)
    );
    header("Location: $return_url");
    exit;
}

e alla pagina di destinazione ....

if ($_REQUEST['secreetsid']) {
    $sid=decrypt($_REQUEST['secretsid'], SERVERSIDEPASSWORD);
    if (looks_like_a_valid_session($sid)) {
          session_id($sid);
          session_start();
          if ($_SESSION['otp']==$_REQUEST['otp']) {
             unset($_SESSION['otp']);
             header("Location: $_REQUEST[original_requested_url]");
             exit;
          } else {
             // bad OTP
             log_bad_session_transfer();
             exit;
          }
    } else {
          // might be naughtiness, might be a bug
          log_bad_session_transfer();
          exit;
    }
 } else {
    // must have got here by accident - send them back to SSO
    redirect_to_sso();
    exit;
 }

Un modo alternativo per risolvere / convalidare il token sarebbe quello di effettuare una chiamata HTTP diretta dalla pagina di destinazione all'SSO (cioè da server a server, non tramite il browser) e chiedergli di risolvere il SID in base al toekn ricevuto dal browser.