Quali sono le migliori pratiche per proteggere la sezione di amministrazione di un sito web? [chiuso]

Mi piacerebbe sapere quali sono le migliori pratiche per la protezione delle sezioni di amministrazione dei siti Web, in particolare da un punto di vista di autenticazione / accesso.

Ovviamente ci sono cose ovvie, come l'utilizzo di SSL e la registrazione di tutti gli accessi, ma mi chiedo dove sopra questi passaggi di base le persone considerano la barra da impostare.

Per esempio:

• Stai solo facendo affidamento sullo stesso meccanismo di autenticazione che usi per gli utenti normali? Se no, cosa?
• Stai eseguendo la sezione Admin nello stesso "dominio dell'applicazione"?
• Quali passi fai per rendere la sezione di amministrazione non scoperta? (o rifiuti l'intera faccenda dell'oscurità)

Finora, i suggerimenti dei rispondenti includono:

• Introdurre una pausa artificiale lato server in ogni controllo della password amministratore per prevenire attacchi di forza bruta [Developer Art]
• Utilizza pagine di accesso separate per utenti e amministratori utilizzando la stessa tabella DB (per interrompere XSRF e il furto di sessioni concedendo l'accesso alle aree di amministrazione) [Thief Master]
• Considera anche l'aggiunta dell'autenticazione nativa del server web all'area di amministrazione (ad es. Tramite .htaccess) [Thief Master]
• Considera l'idea di bloccare l'IP degli utenti dopo una serie di tentativi di accesso amministratore falliti [Thief Master]
• Aggiungi captcha dopo tentativi di accesso amministratore falliti [Thief Master]
• Fornire meccanismi altrettanto potenti (utilizzando le tecniche di cui sopra) per utenti e amministratori (ad esempio, non trattare gli amministratori in modo speciale) [Lo'oris]
• Considera l'autenticazione di secondo livello (ad es. Certificati client, smart card, spazio per schede e così via) [JoeGeeky]
• Consenti l'accesso solo da IP / domini affidabili, aggiungi il controllo alla pipeline HTTP di base (tramite ad esempio HttpModules) se possibile. [JoeGeeky]
• [ASP.NET] Blocca IPrincipal e Principal (rendili immutabili e non enumerabili) [JoeGeeky]
• Elevazione dei diritti federati: ad esempio, inviare un'e-mail ad altri amministratori quando i diritti di un amministratore vengono aggiornati. [JoeGeeky]
• Considera i diritti a grana fine per gli amministratori, ad esempio, anziché i diritti basati sui ruoli, definisci i diritti per le singole azioni per amministratore [JoeGeeky]
• Limita la creazione di amministratori: ad esempio, gli amministratori non possono modificare o creare altri account amministratore. Usa un client "superadmin" bloccato per questo. [JoeGeeky]
• Prendi in considerazione certificati SSL lato client o telecomandi di tipo RSA (token elettronici) [Daniel Papasian]
• Se si utilizzano i cookie per l'autenticazione, utilizzare cookie separati per le pagine admin e normali, ad esempio inserendo la sezione admin su un dominio diverso. [Daniel Papasian]
• Se pratico, considera di mantenere il sito di amministrazione su una sottorete privata, fuori dall'Internet pubblica. [John Hartsock]
• Riemettere i ticket di autenticazione / sessione quando ci si sposta tra i contesti di utilizzo normale / amministratore del sito web [Richard JP Le Guen]

Queste sono tutte buone risposte ... In genere mi piace aggiungere un paio di livelli aggiuntivi per le mie sezioni amministrative. Sebbene abbia utilizzato alcune variazioni su un tema, generalmente includono uno dei seguenti:

• Autenticazione di secondo livello : potrebbe includere certificati client (es. X509 certs), smart card, cardspace, ecc ...
• Restrizioni dominio / IP : in questo caso, solo client provenienti da domini affidabili / verificabili; come le sottoreti interne; sono ammessi nell'area di amministrazione. Gli amministratori remoti spesso passano attraverso punti di ingresso VPN affidabili in modo che la loro sessione sia verificabile ed è spesso protetta anche con chiavi RSA. Se stai usando ASP.NET puoi facilmente eseguire questi controlli nella pipeline HTTP tramite moduli HTTP che impediranno alla tua applicazione di ricevere richieste se i controlli di sicurezza non sono soddisfatti.
• Bloccato IPrincipal e Autorizzazione basata su Principal : la creazione di principi personalizzati è una pratica comune, sebbene un errore comune sia renderli modificabili e / o enumerabili con i diritti. Sebbene non sia solo un problema di amministrazione, è più importante poiché è qui che è probabile che gli utenti abbiano diritti elevati. Assicurati che siano immutabili e non enumerabili. Inoltre, assicurati che tutte le valutazioni per l'autorizzazione siano effettuate in base al preside.
• Elevazione dei diritti federati : quando un account riceve un numero selezionato di diritti, tutti gli amministratori e il responsabile della sicurezza vengono immediatamente informati tramite e-mail. In questo modo, se un utente malintenzionato eleva i diritti lo sappiamo subito. Questi diritti ruotano generalmente intorno a diritti privilegiati, diritti di vedere informazioni protette dalla privacy e / o informazioni finanziarie (ad esempio carte di credito).
• Rilascia i diritti con parsimonia, anche agli amministratori : infine, e questo può essere un po 'più avanzato per alcuni negozi. I diritti di autorizzazione dovrebbero essere il più discreti possibile e dovrebbero circondare comportamenti funzionali reali. Gli approcci tipici della sicurezza basata sui ruoli (RBS) tendono ad avere una mentalità di gruppo . Dal punto di vista della sicurezza questo non è il modello migliore. Invece di " Gruppi " come " Gestione utenti ", prova a suddividerlo ulteriormente (ad es. Crea utente, Autorizza utente, Eleva / Revoca i diritti di accesso, ecc ...). Questo può avere un po 'più di sovraccarico in termini di amministrazione, ma questo ti dà la flessibilità di assegnare solo i diritti che sono effettivamente necessari al gruppo di amministratori più grande. Se l'accesso è almeno compromesso, potrebbero non ottenere tutti i diritti. Mi piace racchiudere questo nelle autorizzazioni Code Access Security (CAS) supportate da .NET e Java, ma questo va oltre lo scopo di questa risposta. Un'altra cosa ... in un'app, gli amministratori non possono gestire la modifica di altri account amministratore o rendere un utente un amministratore. Ciò può essere fatto solo tramite un client bloccato a cui possono accedere solo un paio di persone.

Se il sito Web richiede un accesso sia per le attività regolari che per gli amministratori, ad esempio un forum, utilizzerei accessi separati che utilizzano lo stesso database utente. Ciò garantisce che XSRF e il furto di sessioni non consentano all'autore dell'attacco di accedere alle aree amministrative.

Inoltre, se la sezione admin si trova in una sottodirectory separata, proteggerla con l'autenticazione del server web (.htaccess in Apache per esempio) potrebbe essere una buona idea - allora qualcuno ha bisogno sia della password che della password dell'utente.

Oscurare il percorso di amministrazione non produce quasi alcun guadagno in termini di sicurezza: se qualcuno conosce dati di accesso validi è molto probabile che sia anche in grado di scoprire il percorso dello strumento di amministrazione poiché lo ha phishing o keyloggato o lo ha ottenuto tramite l'ingegneria sociale (il che probabilmente rivelerebbe il percorso anche).

Potrebbe anche essere utile una protezione a forza bruta come bloccare l'IP dell'utente dopo 3 accessi falliti o richiedere un CAPTCHA dopo un accesso non riuscito (non per il primo accesso in quanto è estremamente fastidioso per gli utenti legittimi).

• Respingo l'oscurità
• Utilizzare due sistemi di autenticazione invece di uno è eccessivo
• La pausa artificiale tra i tentativi dovrebbe essere fatta anche per gli utenti
• Il blocco degli IP dei tentativi falliti dovrebbe essere fatto anche per gli utenti
• Anche le password complesse dovrebbero essere utilizzate dagli utenti
• Se consideri i captcha ok, indovina un po ', potresti usarli anche per gli utenti

Sì, dopo averlo scritto, mi rendo conto che questa risposta potrebbe essere sintetizzata come un "niente di speciale per il login amministratore, sono tutte caratteristiche di sicurezza che dovrebbero essere utilizzate per qualsiasi login".

Se utilizzi un solo accesso per gli utenti che hanno sia privilegi di utente normale che privilegi di amministratore, rigenera il loro identificatore di sessione (sia esso in un cookie o in un parametro GET o qualsiasi altra cosa ...) quando si verifica un cambiamento nel livello di privilegio ... per lo meno.

Quindi, se accedo, eseguo un po 'di cose normali da parte degli utenti e poi visito una pagina di amministrazione, rigenera il mio ID di sessione. Se poi esco da una pagina di amministrazione a una normale pagina utente, rigenera nuovamente il mio ID.

Avere una buona password amministratore.

Non "123456"solo una sequenza di lettere, cifre e caratteri speciali abbastanza lunga, diciamo, 15-20 caratteri. Mi piace "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Aggiungi una pausa per ogni controllo della password per prevenire attacchi di forza bruta.

Ecco alcune altre cose da considerare:

1. Un'opzione da considerare, soprattutto se gestisci i computer dell'amministratore o se sono tecnicamente competenti, è utilizzare qualcosa basato su certificati SSL per l'autenticazione del client. I telecomandi RSA e quant'altro possono essere utilizzati anche per una maggiore sicurezza.
2. Se stai utilizzando i cookie, forse per un token di autenticazione / sessione, probabilmente vorrai assicurarti che i cookie vengano inviati solo alle pagine di amministrazione. Questo aiuta a mitigare i rischi posti al tuo sito rubando i cookie, dalla compromissione del livello 1/2 o dall'XSS. Questo può essere fatto facilmente facendo in modo che la parte admin si trovi su un nome host o dominio diverso e impostando il flag di sicurezza con il cookie.
3. Anche la limitazione tramite IP può essere intelligente e se hai utenti su Internet puoi comunque farlo, se esiste una VPN affidabile a cui possono aderire.

Usiamo Windows Authenticationper l'accesso amministratore. Questo è il modo più pratico per proteggere le aree di amministrazione mantenendo l'autenticazione separata da ciò che si applica agli utenti finali generali. L'amministratore di sistema gestisce le credenziali di accesso dell'utente amministratore e applica i criteri per le password sull'account utente del dominio.

Il modo rigoroso è quello di avere due "farm" completamente diverse, inclusi database, server e tutto il resto, e spostare i dati da una farm all'altra. I sistemi più moderni e su larga scala utilizzano questo approccio (Vignette, SharePoint, ecc.). Normalmente si parla di diverse fasi "fase di modifica" -> "fase di anteprima" -> "fase di consegna". Questo metodo ti consente di trattare il contenuto / configurazione nello stesso modo in cui tratti il ​​codice (dev-> qa-> prod).

Se sei meno paranoico puoi avere un unico database ma solo la tua sezione di amministrazione disponibile sui server di "modifica". Voglio dire, solo gli script / file di modifica vengono inseriti nel server di modifica.

Naturalmente la fase di editing dovrebbe essere disponibile solo su una intranet locale e / o utilizzando una VPN.

Questo può sembrare un po 'eccessivo e potrebbe non essere la soluzione più semplice per tutti i casi di utilizzo, ma è sicuramente il modo più robusto di fare le cose.

Nota che cose come "avere password di amministratore complesse" sono carine, ma lascia comunque il tuo amministratore aperto a tutti i tipi di elementi intelligenti.

Dipende molto dal tipo di dati che si desidera proteggere (requisiti legali e simili).

• Molti suggerimenti riguardano l'autenticazione .. Penso che dovresti prendere in considerazione l'utilizzo dell'autenticazione OpenId / Facebook come login. (Molto probabilmente spenderanno più risorse per la sicurezza dell'autenticazione di te)

• Salva le modifiche e aggiorna i valori nel database. In questo modo puoi ripristinare le modifiche dell'utente X o tra la data X e Y.

Non ho notato che nessuno ha menzionato l'archiviazione / convalida della password dell'amministratore. Per favore, per favore, per favore, non memorizzare la PW in testo normale, e preferibilmente nemmeno qualcosa che può essere invertito - usa qualcosa come un hash MD5 salato in modo che almeno se qualcuno capita di recuperare la "password" memorizzata non hanno qualcosa di terribilmente utile, a meno che non abbiano anche il tuo schema di sale.

Aggiungi un campo per la password e una domanda di sicurezza che l'amministratore saprà, ad esempio qual era il nome della tua prima ragazza, o randomizza le domande ogni volta che visualizzi il pannello di amministrazione.

Forse potresti sempre mettere la sezione di amministrazione in una grande directory, ad es

http://domain.com/sub/sub/sub/sub/sub/index.php

Ma non è proprio un bene hah.

Forse potresti includere una stringa di query nella home page, come:

http://domain.com/index.php?display=true

Quando lo fa, appariranno il campo nome utente e password.