it-swarm.dev

Creazione sicura PHP sessioni

Ho già creato e perfezionato sia i sistemi di registrazione che quelli di accesso, tuttavia sono indotto a credere che la parte difficile arrivi quando si crea una sessione. Per quanto ne so, ciò è dovuto sia al dirottamento che alla fissazione. Di cui in tutta onestà non capisco fino in fondo il concetto.

Ho navigato su Internet tutto il giorno e ho fatto molte ricerche. I seguenti articoli mi sono stati utili finora:

Come creare sessioni a prova di proiettile

Guida alla sicurezza di PHP: Sessioni

Finora ho pochissimo, potrei davvero usare un po 'di aiuto e guida. Questo è ciò che ho ottenuto finora:

Quando una password utente viene abbinata e hanno confermato la loro identità utilizzando lo script di accesso, viene chiamata la seguente funzione. La sessione viene avviata nella parte superiore dello script di accesso.

function begin_session()
{
session_regenerate_id();
$_SESSION['valid'] = 1;
$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR']);
} 

Sto usando la variabile $ _SESSION ['valid'] come semplice conferma di accesso dell'utente. Sto assegnando la sessione a un singolo User Agent e indirizzo IP. Vedo come User Agent sia abbastanza inutile in quanto può essere facilmente forgiato, ma sento che è meglio averlo piuttosto che non averlo.

È evidente per me che gli utenti con IP cambianti/dinamici verrebbero disconnessi ... ma tutti quelli che mi hanno detto che questo non mi ha presentato un'opzione migliore o me lo hanno spiegato meglio.

Sto quindi utilizzando la seguente funzione per abbinare l'agente utente corrente all'agente utente originale registrato al momento della creazione della sessione.

    function authenticate()
{
session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR'])) {       
    session_destroy();
echo 'die';
    header('Location: http://website login page/');
    exit();     
}
}

Al momento a causa della mia mancanza di comprensione, non so da dove sono vulnerabile e dove posso andare e fare miglioramenti. Questo è tutto molto nuovo per me e al momento almeno sto cercando di impararlo nel mio tempo libero. Per me è tutto nuovo e voglio garantire il miglior lavoro.

18
TuKritical

Innanzitutto, FERMI DI UTILIZZARE MD5! È una funzione hash rotta ed è stata interrotta per molti anni. Inoltre devi usare un hmac, chiamare md5 direttamente è vulnerabile a un attacco di estensione di lunghezza.

Il test dell'indirizzo IP è problematico perché questo valore può cambiare se l'utente si trova dietro un bilanciamento del carico, che viene comunemente utilizzato da universi e uffici aziendali.

L'attaccante avrà sempre l'utente-agente e questo valore è molto facile da forzare. Testare questo valore non è in alcun modo forma o forma una "misura di sicurezza". È un po 'come avere una variabile is_attacker=no e assicurandosi che questo valore sia "no", che è UNO SCHERZO! Quando vedo un programmatore fare questo, sento l'odore del sangue, se in realtà pensano questo aiuta a migliorare la sicurezza, quindi probabilmente hanno commesso altri errori.

Imposta configurazioni della sessione php come segue:

session.cookie_httponly = 1 (helps mitigate xss)
session.session.use_only_cookies = 1 (prevents session fixation)
session.entropy_file = "/dev/urandom" (better entropy source)
session.cookie_lifetime = 0  (smaller exploitation window for xss/csrf/clickjacking...)
session.cookie_secure = 1 (owasp a9 violations)
15
rook

Questa potrebbe essere solo un'opinione personale ...

Conserverei le informazioni sulla sessione in un database e le farei riferimento tramite un token memorizzato in un cookie. non è più necessario il var "valido" poiché il database fa riferimento incrociato al token e si assicura che sia ancora entro la durata consentita.

Puoi scegliere di lavorare direttamente con il cookie o utilizzare il cookie per impostare le informazioni sulla sessione, se lo desideri. La sessione non è davvero necessaria. Più semplice è meglio.

Il token può essere generato quando l'utente accede e, se lo si desidera, rigenerato su qualsiasi caricamento della pagina, se si desidera mantenerlo in ciclo.

l'agente utente e l'add remoto non sono una buona base per un token poiché possono essere molto comuni per molte persone. Pensa come un delegato per un college o qualcosa del genere. Tutti avranno lo stesso IP. potresti creare qualsiasi stringa casuale e sarebbe sufficiente fintanto che è unica.

Qualunque cosa tu scelga di fare, l'idea di base è quella di mantenere la quantità di informazioni nella tua sessione o i cookie al minimo e il più oscuro possibile. Sarebbe difficile indovinare un token valido se si imposta la scadenza su un orario normale. Inoltre puoi tenere traccia dei tentativi falliti e bloccare i tentativi che si accumulano in un breve lasso di tempo.

Puoi anche avviare le persone se un account tenta di accedere da più posizioni. In tal caso, l'agente utente e l'IP possono aiutare a identificare i tentativi di accesso simultaneo.

2
Kai Qing

Attualmente mi trovo in una posizione simile, esaminando tutte le diverse opzioni e ripercussioni della sicurezza della sessione ed è una vera sfida bilanciare usabilità e sicurezza con potenziale debolezza sul server, nei trasporti e sul client. SSL è il modo migliore per proteggere il livello di trasporto e un'impostazione sicura dei cookie aiuta la protezione del client.

In termini di utilizzo dell'indirizzo remoto $ Server ci sono problemi. Per alcuni utenti questo valore cambia abbastanza regolarmente e un utente che deve reinserire la propria password ogni volta diventa fastidioso. Per altri utenti che si trovano su un indirizzo IP fisso o su un intervallo di indirizzi IP questo può aiutare a rendere più difficile il crack, specialmente se viene utilizzato anche SSL. L'IP remoto non è un proiettile magico in termini di sicurezza, ma nulla è nel cyber spazio. La combinazione di più metodi di sicurezza aiuta. Cercare di creare un profilo utente con cui le variabili $ server rimangono costanti e quali modifiche possono aiutare a sapere quando disconnettersi e chiedere la password in modo più tempestivo e intuitivo. Se l'utente viene disconnesso, qualsiasi tentativo di forza bruta sulle altre variabili $ server come l'agente utente o la codifica del linguaggio dovrà solo attendere fino a quando l'utente reale accede nuovamente.

Il modo in cui gestisci più fonti di accesso ha anche i suoi problemi, cosa succede se l'utente vuole effettuare il check-in dal lavoro, a casa o mentre è in giro? Avendo alcune informazioni su come l'utente utilizza il proprio account nei primi giorni, può aiutare a sapere quando chiudere la sessione e richiedere nuovamente la password in seguito. Come amministratori e anche con una perfetta sicurezza informatica, il modo in cui gli utenti gestiscono le loro password continuerà a essere un problema e richiederà alcune strutture per accedere e ripulire il disordine quando ciò accade.

0
Kevin Martin