Crittografia dei campi nel database

Sì, è un buon piano, ma ci sono ancora una serie di potenziali vulnerabilità. In realtà, l'unico attacco che stai mitigando è l'attacco che hai menzionato, la possibilità di catturare i dati in chiaro con un'istruzione SQL arbitraria. Non stai mitigando altri attacchi, ad esempio, un utente malintenzionato che utilizza l'iniezione SQL per elevare i propri privilegi all'interno dell'applicazione in modo che possano visualizzare le pagine in cui l'applicazione si aspetta di visualizzare questa data in chiaro.

Quindi, la vera soluzione è la difesa in profondità. Questa è una buona parte di questa soluzione (e in effetti i dati dovrebbero essere crittografati a riposo), ma per proteggerli efficacemente occorrono anche salvaguardie aggiuntive, come ad esempio:

1. Strategie generali di protezione dell'iniezione SQL che consentono solo l'accesso all'utente dell'applicazione tramite stored procedure parametrizzate e impediscono completamente l'accesso alle tabelle sottostanti.

2. Protezione dagli attacchi che si basano su caricamento ed esecuzione di codice arbitrario

3. Protezione contro XSS e attacchi di furto di sessione che potrebbero consentire a un utente malintenzionato di acquisire cookie di autenticazione da un amministratore.

I dati sono sicuri solo come il collegamento più debole nella sicurezza complessiva delle applicazioni, quindi ricorda che l'attacco diretto ai dati stessi tramite SQL injection non è l'unica cosa a cui devi pensare per proteggerli.

I would like to encrypt the sensitive fields to protect against any possible SQL injection vulnerabilities.

Questo è probabilmente sbagliato all'inizio. Se si accede al database tramite l'applicazione, in quali circostanze l'applicazione non decrittografa i dati? SQL injection è una vulnerabilità delle applicazioni e quindi a un livello superiore rispetto a quando i dati vengono decodificati.

La crittografia dei dati nel database ha lo scopo di impedire l'esposizione dei dati da parte di accessi non autorizzati al database. Poiché la tua applicazione è autorizzata e può decifrare, non è realmente protetta dall'iniezione tramite questo metodo. Quello che dovresti fare per proteggerti dall'iniezione è usare query parametrizzate .

Ciò su cui verrebbe protetto è che qualcuno ha compromesso direttamente il server del database senza poter compromettere l'applicazione Web.

You would need to get the web application to retrieve the key first. And you can't inject code into the complied web application to do that.

Una rapida ricerca di " applicazione web di overflow del buffer " dovrebbe convincerti diversamente. Inoltre, la chiave sarebbe esposta se potessero in qualche modo leggere l'applicazione.

I secondo @Jeff Ferland nel senso che c'è una dichiarazione confusa nella tua domanda:

I would like to encrypt the sensitive fields to protect against any possible SQL injection vulnerabilities

L'iniezione SQL è un problema a livello di applicazione, mentre la crittografia DB è pensata per evitare minacce interne o qualcuno che potrebbe avere accesso diretto al database.

Non sono molto chiaro su quale DBMS stai usando, ma penso che quello che ti serve qui sia una crittografia a livello di database basata su colonne. Nel mondo commerciale, MyDiamo è la soluzione comune per il DB open source.

Se utilizzi DBMS proprietari (Oracle, MSSQL, ecc.) per una crittografia a livello di database con funzionalità di controllo dell'accesso, probabilmente vorrai andare con la suite di soluzioni sorella di MyDiamo D'Amo . La maggior parte delle altre soluzioni sul mercato sarà principalmente crittografia a livello di file che, come hai affermato sopra, potrebbe ostacolare il tuo scopo.

Nota: ho lavorato come consulente di crittografia DB e mi sono occupata delle soluzioni di cui sopra per un po '.