Voglio sapere perché chiamare un database dal front-end è considerato una cattiva pratica per la sicurezza.
È davvero così difficile giustificare la creazione di un livello applicativo con tutti i suoi svantaggi: costi, prestazioni, tempo di sviluppo?
Non sono sicuro di cosa intendi esattamente. La separazione in livelli come l'applicazione e la logica aziendale e l'accesso ai dati non riguarda tanto la sicurezza quanto la manutenibilità. È fatto per rendere il codice utilizzabile ed essere in grado di fare cose come cambiare il database che si usa senza dover riscrivere completamente l'applicazione.
Inoltre, facilita la sicurezza in quanto è possibile proteggere il DAL per garantire che le chiamate SQL non possano essere violate, ma la stessa cosa può ancora essere eseguita con un piccolo sforzo in più anche se il codice è completamente piatto.
Quindi la premessa iniziale che si tratta di una cattiva pratica di sicurezza non è esattamente corretta, è solo una cattiva pratica di programmazione in generale. Il fatto che rende la sicurezza più difficile da implementare correttamente è solo un effetto secondario del cattivo design generale.
Una connessione al database consentirà all'utente di fare praticamente tutto ciò che gli piace sul database, a condizione che abbia i diritti di accesso. Aprire una connessione direttamente a Internet e l'unica cosa che consente a qualsiasi utente di accedere all'account dell'amministratore è la segretezza della password dell'account amministratore. Per la maggior parte, non vedrai un sistema di database costruito con questo tipo di accesso in mente, quindi non vedrai protezioni sul database stesso create per questo utilizzo.
Dato l'accesso amministrativo e la connettività, un hacker può:
Quindi ... la domanda di risposta è: qual è lo scopo del database e quanto conta l'integrità? Se si tratta di un database di test per un progetto di uno studente, potrebbe interessarsi di più alla macchina stessa rispetto al database. Ma nella maggior parte delle applicazioni, le informazioni nel database e la sua validità, disponibilità e affidabilità sono il cuore del sistema. Perdere questo, o perdere la fiducia in esso e in molti casi, non hai più un business funzionante.
Parlare come uno sviluppatore web, tuttavia - il più grande driver per avere un'app Web non è ancora la sicurezza: è la funzionalità. Le persone non tendono a pensare in SQL, quindi è necessaria un'interfaccia che consenta a un utente meno tecnico di visualizzare e manipolare i dati in un modo che l'utente possa comprendere. Una volta ammesso, anche in un caso, che è necessario un server Web o un app server per il rendering dei dati in una pagina leggibile dall'utente, è stato eliminato il costo maggiore per la gestione del server delle applicazioni. E una volta investito tempo ed energie nello sviluppo di moduli o altri meccanismi di input dei dati che l'utente medio può utilizzare, hai investito abbastanza nel sito nel suo complesso, che farlo correttamente - con solide pratiche di sicurezza è un saggio investimento non solo per proteggere i dati, ma per proteggere il valore dell'investimento nella creazione dell'applicazione.
Sono un po 'poco chiaro su cosa intendi per "front end", ma se stai parlando di attivare in qualche modo i comandi del database direttamente dal lato client di un'applicazione web, sarebbe molto brutto.
Qualsiasi javascript del tuo client può essere facilmente modificato o aggirato interamente, il che significa che qualsiasi comando eseguito dal lato client può essere modificato per fare qualsiasi cosa desideri da un utente malintenzionato. Ad esempio potrebbero cambiare il tuo comando da: SELECT * FROM Products a DELETE Products
Inoltre, è una cattiva idea avere il tuo server database accessibile da Internet. In genere, si desidera disporre di un server Web accessibile da Internet, quindi il server del database sarà disponibile per il server Web.
Leggi altre domande sui tag sql-server secure-coding