Questa area di amministrazione è abbastanza sicura?

Non implementare il proprio gestore di sessioni. Utilizza $ _ SESSION , è stato scritto e verificato da persone che hanno un'ottima conoscenza della sicurezza. Non conosco nemmeno la complessità di come funziona il gestore di sessioni, ma sulla base delle poche informazioni che ci hai fornito di non sicuro .

SQL Injection è utile per ottenere dati dal database. Abbiamo le password HASH perché nel caso in cui un utente malintenzionato ottenga questi dati, saranno costretti a crackare l'hash prima che sia utile. Tuttavia, nel tuo caso, non importa che tu sia vulnerabile a CWE-257 , l'autore dell'attacco puoi semplicemente estrarre l'ID di sessione dal database e utilizzarlo per l'autenticazione.

Potrei anche ottenere l'accesso come amministratore perché non hai fatto menzione di OWASP a9 - Protezione del livello di trasporto insufficiente . Sei anche vulnerabile a Clickjacking , ogni app web è di default. CSRF o "sessione di equitazione" era già menzionato.

Abilita i flag di sicurezza "httponly", "secure". Puoi farlo per $ _SESSION configurando PHP .

Una strategia di difesa approfondita è di pianificare il fallimento e limitare l'accesso dell'amministratore. Non consentire il caricamento di file o l'esecuzione di codice . Questo è il motivo numero 1 per cui le istanze di Wordpress vengono violate, una volta che si è amministrati su un sito Wordpress, si ha l'esecuzione di codice remoto sul server. Wordpress ha anche implementato il proprio gestore di sessione a un certo punto, e avete indovinato, era molto insicuro.

1. Le password devono essere sottoposte a hash, non crittografate. La routine più preferibile sarebbe probabilmente bcrypt. Il parametro di ripetizione deve essere regolato in modo che l'hashing delle password richieda ... ad esempio ... 200 millisecondi, per rallentare la forza bruta offline della password. (offline significa che il tuo sistema è stato compromesso e l'hash è stato ottenuto) (200 millisecondi significa che il tuo hardware, cloud noleggiati o cluster potrebbero eseguire gli hash molto più velocemente)

2. Il diagramma mi sembra ragionevole.

Suggerimenti aggiuntivi

• Impedisci la forza bruta online . (significato in linea usando i tuoi programmi php, verrebbe usato solo se non hanno una copia dell'hash (come in, se non possono usare la forza bruta offline))

• Impedisci gli attacchi CSRF : qualsiasi chiamata al tuo programma che abbia effetti collaterali dovrebbe richiedere una chiave casuale speciale proveniente da una precedente richiesta con lo stesso cookie, questo per impedirti di visitare una pagina web che ha una forma invisibile con un'azione che punta al comando di eliminazione del tuo sito web, che viene eseguito immediatamente da javascript. O nel caso di richieste get che causano effetti collaterali, potrebbe essere necessario visualizzare solo un'email che ha un tag immagine da attaccare in questo modo.

• Impedisci attacchi XSS : qualcuno potrebbe iniettare JavaScript o HTML in alcune colonne che causano l'esecuzione di JavaScript esterno, eventualmente l'invio di cookie, il contenuto corrente della pagina o qualsiasi altro contenuto sul tuo sito utilizzando la tua sessione, ed è possibile che le cose possano essere modificate / cancellate.

• La gestione della sessione descritta presenta carenze. Vedi la risposta di Rook .

Questa non è una lista esaustiva.

Consiglio di guardarsi attorno in questo sito Web sulla sicurezza IT. Espande davvero la tua conoscenza della sicurezza.

Dichiarazione di non responsabilità: sono un programmatore in più lingue, ma non in PHP. Sono un appassionato di sicurezza, ma non necessariamente un esperto.

Non dimenticare di includere anche controlli non tecnici, come la separazione dei compiti (che richiede più di un'approvazione dell'amministratore per apportare modifiche critiche) e una traccia di controllo per la responsabilità.