L'applicazione web è connessa a un database tramite un server delle applicazioni più sicuro?

"Più sicuro" è non costruttivo

Pensare che qualcosa sia "più sicuro" spesso porta a decisioni sbagliate. Ogni sorta di cose sono più sicure pur essendo una cattiva idea. È più utile chiedere "Questo aggiunge sicurezza significativa?" e "La sicurezza ha raggiunto un compromesso ragionevole tra costi e benefici?"

I livelli non aggiungono molta sicurezza

La maggior parte dei libri di infosec consiglia il modello a tre livelli. Ho trovato che il modello a due livelli è altrettanto comune (forse più comune) e questo include un gran numero di app altamente critiche che ho verificato: online banking, ecc.

La realtà è che avere due livelli è solo un beneficio marginale per la sicurezza su un singolo livello. Le persone diranno spesso "se il server web viene violato, non sono nel database". Mentre tecnicamente vero, questo è fuorviante. Il server Web disporrà di credenziali per connettersi al database, che consentirà a un utente malintenzionato di estrarre tutti i dati. Puoi immaginare alcuni scenari di attacco in cui avere due livelli blocca particolari vettori di exploit, ma questi sono rari.

Il vantaggio sulla sicurezza di tre livelli contro due è addirittura inferiore a due contro uno. E questo è particolarmente vero con SPA, dove il livello web è sul client.

Modifica Per essere chiari, intendo i livelli come nei livelli su server separati (virtuali o fisici) - piuttosto che una separazione puramente logica.

Se si distingue tra server Web, server applicazioni e database, si intende in realtà un front end, una logica aziendale e un back-end (storage). Questa è anche chiamata architettura multilivello con livello di presentazione, livello applicazione e livello dati. In questo caso, il server delle applicazioni non passerà semplicemente alcuna richiesta dal server Web ma consentirà solo azioni che si adattano alla logica aziendale. Ciò significa che tutta la sicurezza (cioè chi può accedere a cosa) viene essenzialmente eseguita nel server delle applicazioni e il server Web è lì solo per rendere queste informazioni accessibili tramite un browser web.

Se invece si dispone solo di server Web e database, la logica aziendale è essenzialmente parte del server web. Mentre questo rende spesso più facile iniziare con alcune applicazioni Web, la distinzione mancante tra presentazione e logica aziendale porterà facilmente in un disastro che nessuno può più comprendere e che spesso consente di aggirare la logica di business e ottenere così un accesso diretto al database per un attaccante.

Si noti che la separazione tra i livelli non deve necessariamente essere eseguita con un server o un'applicazione separati, ma può anche essere una separazione in-process (ad esempio API, classi ...). Ma è importante che questa separazione non possa essere semplicemente aggirata, che spesso può essere gestita in modo più sicuro con un processo o server separato. Una separazione mancante tra la presentazione e l'applicazione può talvolta essere vista in quanto non è possibile accedere a informazioni specifiche in HTML, ma sono comunque accessibili da un'API JSON o XML.

È necessario un livello applicazione come filtro, poiché la maggior parte dei * sistemi di database non consente la gestione delle autorizzazioni, che è abbastanza dettagliata per gestire più utenti.

Di solito * puoi creare utenti con permessi di lettura e scrittura diversi, ma solitamente * questi sono progettati per un massimo di poche decine di utenti e non si adattano bene a migliaia o addirittura a milioni di utenti. Inoltre, di solito * puoi impostare le autorizzazioni solo a livello di tabella non su un livello per riga ma solo a livello di campo.

Questo significa che è difficile per te controllare quali dati i tuoi utenti possono e non possono visualizzare e quali dati possono e non possono modificare. Per fare un esempio, prendiamo una tabella utenti con queste colonne

userId
password
profilePicture
createdDate
lastLoggedInDate

Le persone dovrebbero poter cambiare il proprio profilePicture , ma non quello di altre persone. Nessuno dovrebbe cambiare il campo createdAt e cambiare userId potrebbe causare tutti i tipi di hijink. Ogni utente deve modificare lastLoggedInDate al momento dell'accesso e impostarlo sulla data corrente, ma non impostarlo su qualcosa di diverso. Il tuo database può gestire questa complessità *? Oh, e non abbiamo ancora parlato dei riferimenti tra i tavoli.

Bene, ma se si limitasse a vietarlo sul livello del client semplicemente non scrivendo il codice della GUI per fare ciò che l'utente non dovrebbe fare? Il problema è che il tuo database non ha modo di verificare che l'applicazione client sia realmente il programma che hai scritto. Quando parla SQL e invia credenziali di accesso valide, il database si fiderà di esso. Un utente malintenzionato potrebbe scrivere il proprio client e inviare comandi SQL arbitrari al proprio database.

_{* Non voglio dire che è impossibile che esista un database che può fare tutto questo, ma finora non ne ho visto uno. Quando ne conosci uno, non esitare a commentare.}