Sicurezza accesso al sito (abbastanza sicuro?)

4

Sto realizzando un sito più grande per la prima volta, quindi la sicurezza conta davvero, a differenza delle mie schede davvero pessime con forse 10 utenti. Quindi volevo chiedere se il modo in cui sto facendo è abbastanza sicuro per un'applicazione semi-grande in cui sono coinvolti i soldi.

Il sito è scritto in PHP, il database è MySql. Questo è il login corrente.

Prima di tutto, ho un long key di 128 caratteri e una session key salvati nella configurazione locale.
Su ogni sito che interagisce con le sessioni (ad esempio il pannello di controllo utente) ho questo frammento all'inizio del codice:

session_start();
if (empty($_SESSION)) {
    session_regenerate_id(true);
}

Dopo che mi collego al database, sfuggi tutte le stringhe e leggi i dati.
Dopo di ciò, confronto le due password che ho ottenuto con SHA-512 e il sale di prima:

public static function hashValue($str) {
    for ($x = 0; $x < 10000; $x++) {
        $str = hash('sha512', $str . self::$salt);
    }

    return $str;
}

Se tutto è corretto, $_SESSION[$sessionkey] viene impostato con l'ID utente dal database (anche se la chiave della sessione lunga non dovrebbe essere necessaria perché il client non può cambiare localmente il $_SESSION vars, IIRC. )
Se il sito è protetto (come in, gli utenti non loggati non hanno accesso) questo codice viene chiamato per reindirizzare nuovamente all'indice se non sono loggati:

if (!isset($_SESSION[$sessionkey])) {
    header("Location: ?view=default");
    exit;
}

Questa applicazione è sicura? Ho letto da qualche parte che è meglio avere un sale generato a caso per ogni utente, salvato nel database. E 'davvero necessario, considerando che previene solo un po' meglio il brute forcing, che comunque non dovrebbe essere un problema con un captcha?

    
posta nn3112337 12.02.2016 - 11:02
fonte

1 risposta

23

Lo scenario peggiore da proteggere è un utente malintenzionato che compromette completamente il server e ottiene il codice sorgente, la configurazione e il dump del database. Tienilo a mente.

Questo è lo scenario in cui un sale dovrebbe proteggere le tue password. La forzatura bruta remota non è compromessa da una salata (che è comunque inutile su tutto tranne le password più banali dovute alla larghezza di banda della rete limitata).

Alcuni problemi:

  • Un "salt" che è lo stesso per tutte le password è chiamato pepper e non aumenta la sicurezza molto quando l'hacker lo sa.
  • SHA512 è un algoritmo di digest del messaggio, non un algoritmo per le password di hashing. Il problema con SHA512 è che è troppo veloce, consentendo all'utente malintenzionato di forzare il database delle password rubato molto rapidamente. Quello che vuoi è un algoritmo intenzionalmente lento come bcrypt. PHP ha un'implementazione predefinita facile da usare che può generare, memorizzare e applicare automaticamente il sale per te.
  • Gli ID di sessione lunghi, unici e impossibili da indovinare sono necessari, perché quando un utente malintenzionato può indovinare l'ID di sessione di un utente che ha effettuato l'accesso può dirottare la propria sessione. Il sistema di gestione delle sessioni di PHP presuppone che qualsiasi richiesta che includa l'ID di sessione di un utente precedentemente autenticato provenga da tale utente autenticato. In generale, devi fare affidamento sugli ID di sessione che vengono generati automaticamente da PHP e sostituirli con i tuoi solo quando sei sicuro di sapere cosa stai facendo.
  • Punto minore: "Dopo che mi collego al database, sfuggi tutte le stringhe e leggi i dati." Escaping di tutti gli input utente con mysqli_real_escape_string sarebbe sufficiente in teoria , ma in pratica è facile dimenticare qualche raro caso limite dove le stringhe fornite dall'utente finiscono nelle query del database. Una pratica migliore è eseguire tutte le query di database con istruzioni preparate che utilizzano ? segnaposto e bind per tutte le variabili. In tal caso l'API mysqli esegue l'escape per te, che è molto più affidabile, soprattutto perché è a conoscenza del contesto in cui verranno utilizzate le stringhe di escape. Come ulteriore vantaggio, presenta anche alcuni vantaggi in termini di prestazioni e leggibilità.
risposta data 12.02.2016 - 11:21
fonte

Leggi altre domande sui tag