Prevenire l'immissione di dati errati

Question

È buona norma delegare la convalida dei dati interamente ai vincoli del motore di database?

La convalida dei dati dall'applicazione non impedisce l'inserimento non valido da parte di un altro software (eventualmente scritto in un'altra lingua da un altro team).Utilizzando i vincoli del database riduci i punti in cui devi preoccuparti di dati di input non validi.

Se metti la validazione sia nel database che nell'applicazione, la manutenzione diventa noiosa, perché devi aggiornare il codice per chissà quante applicazioni, aumentando la probabilità di errori umani.

Semplicemente non vedo che questo venga fatto molto, guardando il codice di progetti di software libero.

Answer 1

È meglio, ove possibile, specificare le regole di convalida nel database e utilizzare o scrivere un framework che faccia emergere tali regole nel front-end.ASP.NET Dynamic Data aiuta in questo e ci sono alcune librerie commerciali che lo rendono ancora più semplice.

Questo può essere fatto sia per la semplice convalida dell'input (come numeri o date) sia per i dati correlati come quelli vincolati da chiavi esterne.

In sintesi, l'idea è quella di definire le regole in un unico posto (il database la maggior parte delle volte) e avere codice in altri livelli che applicherà tali regole.

Answer 2

Convalidare al momento dell'input.Convalidare nuovamente prima di inserirlo nel database.E avere vincoli di database per prevenire input errati.E puoi scommettere che nonostante tutto ciò, i dati errati entreranno comunque nel tuo database, quindi convalidalo di nuovo quando lo usi.

Sembra che ogni giorno alcune app Web vengano hackerate perché hanno eseguito tutta la convalida nel modulo o, peggio, utilizzando Javascript, e le persone hanno trovato un modo per aggirarlo.Devi guardarti da questo.

Paranoico?Me?No, solo sperimentato.

Answer 3

Lo svantaggio di lasciare la logica al database è che si aumenta il carico su quel particolare server.I server Web e applicativi sono relativamente facili da espandere verso l'esterno, ma un database richiede tecniche speciali.Come regola generale, è una buona idea inserire la maggior parte della logica computazionale nel livello dell'applicazione e mantenere l'interazione con il database il più semplice possibile.

Detto questo, è possibile che la tua applicazione non debba preoccuparsi di problemi di scalabilità così pesanti.Se sei certo che il carico del server database non sarà un problema per il prossimo futuro, quindi andare avanti e imporre i vincoli al database.Hai ragione nel dire che ciò migliora l'organizzazione e la semplicità del tuo sistema nel suo insieme mantenendo la logica di convalida in una posizione centrale.

Answer 4

Ci sono altre preoccupazioni oltre alla semplice iniezione SQL con input.Dovresti assumere la posizione più difensiva possibile ogni volta che accetti l'input dell'utente.Ad esempio, un utente potrebbe essere in grado di inserire un collegamento a un'immagine in una casella di testo, che in realtà è uno script PHP che esegue qualcosa di pericoloso.

Se progetti bene la tua applicazione, non dovresti dover controllare faticosamente tutti gli input.Ad esempio, potresti utilizzare un'API Forms che si occupa della maggior parte del lavoro per te e un livello di database che fa più o meno lo stesso.

Questa è una buona risorsa per il controllo di base delle vulnerabilità:

http://ha.ckers.org/xss.html

Answer 5

È troppo tardi quando i dati arrivano al tuo database per fornire una convalida significativa per i tuoi utenti e le tue applicazioni.Non vuoi che il tuo database funzioni Tutto la convalida poiché ciò rallenterà le cose abbastanza bene e il database non esprime la logica in modo così chiaro.Allo stesso modo, man mano che cresci, scriverai più transazioni a livello di applicazione per integrare le transazioni del tuo database.

Answer 6

Direi che è potenzialmente una cattiva pratica, a seconda di cosa succede quando la query fallisce.Ad esempio, se il tuo database potesse generare un errore che è stato gestito in modo intelligente da un'applicazione, allora potresti essere a posto.

D'altra parte, se non inserisci alcuna convalida nella tua app, potresti non avere dati errati, ma potresti far sì che gli utenti pensino di aver inserito elementi che non vengono salvati.

Answer 7

Implementa quanta più convalida possibile dei dati a livello di database senza compromettere altri obiettivi.Ad esempio, se la velocità è un problema, potresti prenderlo in considerazione non utilizzando chiavi esterne, ecc.Inoltre, alcune convalide dei dati possono essere eseguite solo dal lato dell'applicazione, ad esempio assicurando che gli indirizzi e-mail abbiano domini validi.

Answer 8

Un altro svantaggio nell'eseguire la convalida dei dati dal database è che spesso non si esegue la convalida allo stesso modo in ogni caso.In effetti, spesso dipende dalla logica dell'applicazione (ruoli utente) e talvolta potresti voler ignorare del tutto la convalida (processi cron e script di manutenzione).

Answer 9

Ho scoperto che eseguire la convalida nell'applicazione, anziché nel database, funziona bene.Ovviamente tutta l'interazione deve passare attraverso la tua applicazione.Se disponi di altre applicazioni che funzionano con i tuoi dati, la tua applicazione dovrà supportare una sorta di API (si spera REST).

Answer 10

Non penso che ci sia una risposta giusta, dipende dall'uso che ne fai.

Se disporrai di un sistema molto utilizzato, con la possibilità che le prestazioni del database possano diventare un collo di bottiglia, potresti voler spostare la responsabilità della convalida al front-end dove è più facile scalare con più server.

Se disponi di più applicazioni che interagiscono con il database, potresti non voler replicare e mantenere le regole di convalida su più applicazioni, quindi il database potrebbe essere il posto migliore.

Potresti volere una schermata di input più intuitiva che non si limiti a colpire l'utente con avvisi di convalida quando tenta di salvare un record, forse vuoi convalidare un campo dopo che i dati sono stati immessi e perde il focus;o anche mentre l'utente digita, modificando il colore del carattere quando la convalida fallisce/supera.

Correlati ai vincoli sono anche gli avvisi relativi a dati sospetti.Nella mia applicazione ho vincoli rigidi nel database (ad es.qualcuno non può iniziare un lavoro prima della data di nascita), ma poi nel front-end vengono visualizzati avvisi per dati che potrebbero essere corretti, ma sospetti (ad es.un bambino di otto anni che inizia a lavorare).