Creazione di sessioni PHP sicure

Question

Creazione di sessioni PHP sicure

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

18

Ho già creato e perfezionato sia i sistemi di registrazione che i sistemi di accesso, tuttavia sono convinto che la parte difficile sia quando si crea una sessione. Per quanto ne so, ciò è dovuto sia ad Hijacking che alla fissazione. Che in tutta onestà non comprendo pienamente il concetto di.

Ho navigato su internet tutto il giorno e ho fatto una grande quantità di ricerche. i seguenti articoli mi sono stati utili fino ad ora:

Come creare sessioni a prova di proiettile

Guida alla sicurezza di PHP: Sessioni

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

Quando una password utente è abbinata e hanno confermato la propria identità utilizzando lo script di accesso, viene chiamata la seguente funzione. La sessione viene avviata all'inizio 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 una semplice conferma della registrazione dell'utente. Sto assegnando la sessione a un singolo agente utente e indirizzo IP. Vedo come l'User Agent sia abbastanza inutile in quanto può essere facilmente falsificato, ma ritengo sia meglio averlo piuttosto che non averlo.

È evidente per me che gli utenti con IP mutevoli / dinamici verranno disconnessi ... ma tutti quelli che mi hanno detto questo non sono riusciti a presentarmi 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 alla 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 o dove posso andare e apportare miglioramenti. Questo è tutto molto nuovo per me e al momento almeno sto cercando di imparare questo nel mio tempo libero. È tutto nuovo per me, e voglio garantire il miglior lavoro.

php

posta TuKritical 13.11.2012 - 02:10

fonte

3 risposte

Leggi altre domande sui tag php

Quali sono le precauzioni di sicurezza prudenti da prendere per i viaggi di lavoro da parte di persone con accesso a informazioni sensibili? Come posso cancellare in modo sicuro le unità flash USB?

score 15 · Answer 1

Innanzitutto, STOP USANDO MD5! È una funzione di hash rotta ed è stata interrotta per molti anni. Inoltre devi usare un hmac, chiamare direttamente md5 è vulnerabile ad un attacco con estensione di lunghezza.

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

L'utente malintenzionato avrà sempre l'user-agent e questo valore è molto facile da applicare alla forza bruta. Testare questo valore non è in alcun modo forma o forma una "misura di sicurezza". È come avere una variabile is_attacker=no e assicurarsi che questo valore sia "no", che è A JOKE! Quando vedo un programmatore fare questo odore di sangue, se effettivamente pensano che questo aiuti a migliorare la sicurezza quindi hanno probabilmente commesso altri errori.

Imposta le 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)

score 2 · Answer 2

Questa potrebbe essere solo un'opinione personale ...

Vorrei memorizzare le informazioni sulla sessione in un database e farvi riferimento da un token memorizzato in un cookie. non hai più bisogno della var "valida" dal momento che il database incrocia il riferimento al token e si assicura che sia ancora all'interno della vita 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 è il modo migliore.

Il tuo token può essere generato quando l'utente esegue il login e, se lo desideri, rigenerato su qualsiasi caricamento della pagina, se desideri mantenerlo in ciclo.

l'agente utente e l'addr remoto non sono una buona base per un token poiché possono essere molto comuni per molte persone. Pensa come un proxy 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 è di mantenere la quantità di informazioni nella sessione o nei cookie al minimo e nel modo più oscuro possibile. Sarebbe difficile capitare di 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ù postazioni. In tal caso, user agent e IP possono aiutare a identificare i tentativi di accesso simultanei.

score 0 · Answer 3

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

In termini di utilizzo del $ Server Remote Address 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 gli altri utenti che si trovano su un indirizzo IP fisso o su un intervallo di indirizzi IP questo può contribuire a rendere più difficile il crack, specialmente se viene utilizzato anche SSL. L'IP remoto non è una bacchetta magica in termini di sicurezza, ma nulla è nel cyber spazio. La combinazione di più metodi di sicurezza aiuta tutti. Cercando di creare un profilo utente con il quale le variabili $ del server rimangono costanti e quale modifica può aiutare a sapere quando chiudere l'utente e chiedere la password in un modo più tempestivo e facile da usare. Se l'utente è disconnesso, qualsiasi tentativo di forza bruta sulle altre variabili $ del server come l'agente utente o la codifica del linguaggio dovrà semplicemente attendere fino al momento in cui l'utente reale effettuerà nuovamente il login.

Anche il modo in cui gestisci più sorgenti di accesso ha i suoi problemi, e se l'utente desidera 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 chiedere nuovamente la password in seguito. Come amministratori e anche con una perfetta sicurezza informatica, il modo in cui gli utenti gestiscono le loro password continueranno ad essere un problema e necessiteranno di qualche possibilità di entrare e ripulire il caos quando ciò accadrà.