Problemi di sicurezza nell'esempio del codice funzione "Ricordami"

Question

Problemi di sicurezza nell'esempio del codice funzione "Ricordami"

#1 da (2 voti)
#2 da (0 voti)

1

Sono un principiante e questi possono essere molto ovvi per te, ma sto cercando di capire se ci sono problemi di sicurezza con questo esempio.

Oggi su Stack Overflow, ho visto il seguente post: PHP Sessions Accedi con ricordami .

La domanda riguarda la creazione di una funzione "Ricordami" per estendere la sessione auticata per le persone che hanno effettuato il login.

La risposta accettata era:

function setSession($username,$password,$cookie=null){
    // Other code for login ($_POST[]....)
    // $row is result of your sql query
    $values = array($username,$this->obscure($password),$row['id']);         
    $session = implode(",",$values);

    // check if cookie is enable for login
    if($cookie=='on'){
        setcookie("your_cookie_name", $session, time()+60*60*24*100,'/');
    } else {
        $_SESSION["your_session_name"] = $session;
    }
}

Quindi, la mia domanda non riguarda il modo in cui dovresti fare questo, ma sono corretto nei problemi di sicurezza che ho delineato di seguito per questo esempio di codice?

Usando il OWASP Top 10 come riferimento, questi sono i problemi che vedo:

Problema 1:

Per prima cosa possiamo supporre che $session abbia la password e il nome utente perché $value contiene il nome utente e la password dell'utente. Anche con questa linea:

setcookie("your_cookie_name", $session, time()+60*60*24*100,'/');

Il cookie ha ora le credenziali dell'utente. Un grosso errore per me, vedi Numero 3 per ulteriori informazioni.

Problema 2:

Ho letto questo articolo OWASP dove dicono che per prevenire CSRF dobbiamo generare un associato ID casuale alla SESSIONE o al cookie.

Ovviamente in questo codice non c'è un token o un ID univoco che mi sospetti.

Numero 3:

Possiamo anche immaginare che il sito possa essere vulnerabile a "Cross-Site Scripting (XSS)"

Infatti, se le credenziali dell'utente sono memorizzate in un cookie, possiamo eseguire uno script semplice e mostrare il cookie.

alert(document.cookie);

Domanda

Sono sicuro che potrebbe esserci un altro problema, ma ho esposto la cosa più ovvia per me. Ho ragione nei problemi che ho identificato? Ho perso altri grandi problemi di sicurezza con questo codice?

authentication xss session-management csrf

posta mpgn 09.08.2014 - 16:53

fonte

2 risposte

Leggi altre domande sui tag authentication xss session-management csrf

Carica solo in Android Che cosa significa proxyexec + cagefs.server nella e-mail X-Source-Args?

score 2 · Answer 1

La memorizzazione di dati sensibili in un cookie non è necessariamente pericolosa, dipende da come si configura il cookie. Il cookie deve essere configurato come cookie sicuro (limitato solo a HTTPS), deve essere impostato il flag HttpOnly per evitare lo scripting cross-side (il cookie non sarà disponibile da javascript) e il dominio deve essere impostato sul valore corretto in base al ambito del cookie. Usando queste impostazioni è OK inserire il nome utente nel cookie.

Riguardo agli altri dati nel cookie è possibile creare una tripletta di username, token di serie e token una tantum. Questa terzina è memorizzata nel database e nel cookie e può essere confrontata per autenticare l'utente. C'è un eccellente articolo che spiega questa tecnica sul blog di Barry Jaspan

Se desideri una misura di sicurezza aggiuntiva, puoi ulteriormente crittografare il valore del cookie con una chiave trovata sul server in modo che i dettagli come il nome utente e i token non possano essere letti sul browser anche dall'utente stesso. Tuttavia, se si dispone di un ambiente con bilanciamento del carico, è necessario assicurarsi che la chiave di crittografia sia condivisa tra tutte le istanze utilizzando il DB, ad esempio.

Per quanto riguarda l'implementazione specifica menzionata nell'esempio di codice, ci sono alcune preoccupazioni:

che cosa fa la funzione oscura? anche se ha una funzione unidirezionale, sarebbe più sicuro usare semplicemente un numero pseudo-casuale crittograficamente sicuro invece
qual è l'idea del parametro id riga? non è compreso e non è casuale
non è chiaro cosa significhi quando $ cookie non è 'attivo'. I valori di autenticazione vengono quindi memorizzati nella sessione anziché in un cookie. Se $ cookie! = 'On' significa che i cookie sono disabilitati, questa è una cattiva pratica, dal momento che l'ID di sessione sarà conservato nell'URL.

score 0 · Answer 2

Hai ragione con tutti questi problemi. Questa implementazione non è sicura e potrebbe portare a un furto di identità.

È ancora meno sicuro rispetto all'utilizzo dell'autenticazione di base HTTP in quanto tali cookie sono vulnerabili agli attacchi XSS.

Non ho potuto pensare a nessun altro problema oltre a quelli che hai fornito. (non sono abbastanza?). Bene, c'è l'id della voce dell'utente nel database nel cookie, quindi potrebbe aiutare in altri attacchi ... Poiché non ci sono informazioni su quella query, l'unico motivo per includere l'id della riga è cerca il database con esso al prossimo accesso, quindi potrebbe essere vulnerabile a un'iniezione SQL (non probabile, però)

Ci sono ancora troppi dettagli lasciati fuori da quel codice (come la funzione "oscura" (reversibile o hash?) o la query implicita SQL) che la risposta sembra un po 'debole. Voglio dire, quel codice imposta il cookie ma, come usa quel cookie?

E perché memorizza la password "oscurata" nella cache di sessione del server se non è abilitato "cookie abilitato"? Voglio dire, hai già le password memorizzate da qualche parte (database, LDAP, file semplici, ...) quindi non c'è bisogno di memorizzarlo di nuovo. Ciò aumenta il rischio di rubare quelle password, dato che tali dati non sarebbero criptati su una directory temporale sul server.