Come proteggere un back-end del server

Se ho capito bene, il tuo CMS serve due tipi di utenti, che presumibilmente hanno privilegi diversi:

1. Utenti non in-app (ad esempio utenti che accedono al CMS direttamente dal proprio browser). Accesso in lettura e scrittura.
2. Utenti di app mobili. Solo accesso in lettura.

In base alla progettazione del tuo sistema, è possibile che un utente app trovi la combinazione utente / password utilizzata dalla sua app (perché è codificata nell'app) per accedere al CMS. Pertanto, la sola cosa che impedisce all'utente di manipolare i dati del CMS è il fatto che lui / lei stia utilizzando l'app.

La tua preoccupazione immediata dovrebbe essere la separazione dei ruoli nel tuo CMS. Se stai usando sessioni in JSP, questo dovrebbe essere facile (magari aggiungi un'altra colonna nella tabella utenti che rappresenterà il ruolo dell'utente e avrai un controllo di ruolo in ogni .jsp).

Riguardo al punto di accesso del tuo CMS, oscurarlo potrebbe ingannare alcuni robot, ma questo non è abbastanza. Potresti usare iptables per fermare gli attacchi bruteforce o potresti implementare un demone di qualche tipo che monitora i log di Tomcat e vieta il comportamento sospetto (un mio esempio usato per vietare i bruteforcers SSH: link ).

Inoltre, usa sempre HTTPS quando gestisci informazioni riservate come le credenziali di autenticazione.

Per prima cosa usa SSL (https). Ciò impedirà a un intercettatore di apprendere le credenziali degli utenti.

Vedere Quali sono i pro e i contro dell'SSL del sito (https)? , HSTS extra sicurezza su HTTPS , Guida per implementatori di siti solo HTTPS (lato server) .

Se si incorpora una password nel codice dell'app mobile che l'utente scarica, è un po 'strano e non sembra una buona pratica. Questo è effettivamente equivalente a mettere quella password sul tuo sito web affinché tutti possano vederla: chiunque può scaricare l'app e guardare i byte per trovare la password. Niente memorizzato in un programma binario dovrebbe essere trattato come segreto.

Se l'utente digita la sua password nell'app, va bene memorizzarla nell'archivio privato dell'app e riutilizzarla su ogni connessione. Oppure, è sufficiente generare una chiave privata al primo avvio dell'app, inviare in modo sicuro il cert corrispondente al server (tramite una connessione SSL autenticata dalla password dell'utente), quindi utilizzare SSL con i certificati client per autenticare il cellulare client al server su tutte le connessioni successive (quindi l'utente non deve digitare di nuovo la sua password).

Se il contenuto del CMS è destinato al pubblico, è necessario rimuovere la password per la visualizzazione del contenuto, poiché è un po 'inutile. Se l'app mobile è disponibile al pubblico, e chiunque abbia l'app mobile può leggere il contenuto sul CMS, hai effettivamente deciso che il contenuto del CMS è destinato al pubblico.

Puoi generare una "chiave API" per ogni utente che useranno per recuperare i dati, in modo che se sia rubata / compromessa, non può essere utilizzata per accedere al CMS e potrebbe anche essere ripristinata da lì.

Inoltre, dovresti rispondere con un errore (ad esempio 401 Non Autorizzato o 403 Proibito) agli accessi non validi invece di reindirizzarli all'endpoint di accesso.

Se vuoi aggiungere un livello di sicurezza opzionale al CMS, ti suggerisco di aggiungere qualche autenticazione multifactor (ad esempio Google Authenticator ).

Oltre a questi, dovresti proteggere i tuoi server dagli attacchi brute force (bloccare un indirizzo dopo una richiesta fallita ripetuta, o magari aggiungere un CAPTCHA al modulo di login), varie iniezioni (controlla attentamente il codice, specialmente le query SQL ) e sniffing (crittografa il traffico tra l'app mobile e il servizio web e utilizza SSL sul server CMS). E ovviamente, tieni aggiornati tutti i software e le librerie di terze parti.

L'ambiente è sempre importante, perché i livelli di sicurezza passano da un livello fisico all'altro.

Java ha la sua sicurezza, quindi è diverso quindi ad es. PHP, Python o Ruby. Java sta compilando il codice sorgente e il suo linguaggio statico. I modificatori di accesso OO hanno senso separare i diritti di parti del codice, ed è considerato sicuro poiché non si può fare l'iniezione di codice in Java come si fa con PHP, il più delle volte.

In pratica cosa devi fare per una app di questo tipo:

• In primo luogo, devi dividere le tue applicazioni in diversi contesti isolati usando Tomcat. Con PHP o IIS fai questo con un utente di sistema diverso. In Tomcat, devi solo impostare un'applicazione separata. Puoi anche isolarli tramite la virtualizzazione, ad es. due gatti e due ips.
• Ogni applicazione deve utilizzare login diversi per il Database e disporre solo delle autorizzazioni necessarie, ad esempio, frontend e backend possono avere livelli diversi, quindi SQL Injection su frontend non interromperà il sistema completo. Se tutti usano lo stesso DB. Puoi usare Views per farlo.
• Assicurati di utilizzare HTTPS per ogni accesso anche per la sessione utente back-end
• Puoi installare Apache con ModSecurity di fronte ad esso con mod_proxy
• Assicurati che la tua sessione sia sicura, ad es. è token crittograficamente sicuro

E soprattutto:

• Gli utenti di frontend e backend dovrebbero essere tenuti in tabelle separate e il loro accesso dovrebbe essere limitato a frontend o backend. Quindi, quando la frotend viene violata, non è possibile alcuna modifica al database tranne poche colonne innocenti.
• Le password devono essere sottoposte a hashing con sale al minimo.
• Ragionevole recupero della password.

Inoltre:

• Prova a proteggere la macchina con SELinux
• Crea un buon firewall IPTABLES - questo e sopra impedisce il rooting della macchina

Inoltre, se hai un sacco di pubblico:

• Isolare login, registrazione e recupero password (e reporting) in un altro tomcat con accesso in scrittura esclusivo alle tabelle degli utenti, ma potrebbe non essere un problema con Tomcat. Assicurati solo che ogni contesto di esecuzione in Tomcat non sia in grado di leggere i file di configurazione / le password db l'uno dall'altro.

Questo è ciò che ho deciso come risultato di questa discussione.

1. Tutto è finito su HTTPS, naturalmente.
2. Separerò i ruoli per gli utenti di CMS e di app per dispositivi mobili, in modo che l'accesso e la password dall'app non siano utili nel CMS.
3. Indurirò il servizio di login implementando misure contro gli attacchi brute force / dictionary.
4. Sembra che non ci sia alcuna "best practice" su come evitare che troppi aggressori vengano a bussare alla porta di accesso del CMS: dividere il CMS e WS in server / domini / ... o semplicemente "nascondere" "l'URL di accesso, o entrambi, o qualsiasi altra cosa - non ha molta importanza.