campos de cifrado en la base de datos

Sí, es un buen plan, pero todavía hay una serie de vulnerabilidades potenciales. En realidad, el único ataque que está mitigando es el ataque que mencionó, la capacidad de capturar los datos de texto sin cifrar con una declaración SQL arbitraria. No está mitigando ningún otro ataque, por ejemplo, un usuario malintencionado que usa la inyección de SQL para elevar sus privilegios dentro de la aplicación para que pueda ver las páginas en las que la aplicación espera mostrar esta fecha en texto claro.

Entonces, la solución real es la defensa en profundidad. Esta es una buena parte de esa solución (y, de hecho, los datos confidenciales deben estar encriptados en reposo), pero para protegerla de manera efectiva, también necesita garantías adicionales, como:

1. Las estrategias generales de protección de inyección SQL, como permitir solo el acceso al usuario de la aplicación a través de procedimientos almacenados parametrizados y negar el acceso a las tablas subyacentes por completo.

2. Protección contra ataques que se basan en la carga y ejecución de código arbitrario

3. Protección contra XSS y ataques de robo de sesión que podrían permitir a un usuario malintencionado capturar cookies de autenticación de un administrador.

Los datos solo son seguros como el enlace más débil en la seguridad general de la aplicación, así que recuerde que el ataque directo a los datos a través de la inyección de SQL no es lo único en lo que debe pensar para protegerlos.

  

Me gustaría cifrar los campos confidenciales para protegerme contra cualquier posible vulnerabilidad de inyección SQL.

Esto es probablemente incorrecto al principio. Si se accede a su base de datos a través de la aplicación, ¿en qué circunstancias la aplicación no descifra los datos? La inyección de SQL es una vulnerabilidad de la aplicación y, por lo tanto, a un nivel más alto que cuando se descifran sus datos.

El cifrado de datos en la base de datos tiene la intención de evitar la exposición de los datos mediante el acceso no autorizado a la base de datos. Debido a que su aplicación está autorizada y se puede descifrar, no está realmente protegida contra la inyección a través de este método. Lo que debe hacer para protegerse contra la inyección es utilizar consultas parametrizadas .

Contra lo que estarías protegido es que alguien haya comprometido el servidor de la base de datos directamente sin poder comprometer la aplicación web.

  

Necesitaría obtener la aplicación web para recuperar la clave primero. Y no puede insertar código en la aplicación web que cumple para hacer eso.

Una búsqueda rápida de " aplicación web de desbordamiento de búfer " debería convencerlo de lo contrario. Además, la clave quedaría expuesta si pudieran leer la aplicación de alguna manera.

Segundo @Jeff Ferland en que hay una declaración confusa en tu pregunta:

  

Me gustaría cifrar los campos confidenciales para proteger contra cualquier   posibles vulnerabilidades de inyección SQL

La inyección de SQL es un problema de nivel de aplicación, mientras que el cifrado de base de datos está diseñado para evitar amenazas internas o alguien que pueda tener acceso directo a su base de datos.

No tengo muy claro qué DBMS está utilizando, pero creo que lo que necesita aquí es un cifrado a nivel de base de datos basado en columnas. En el mundo comercial, MyDiamo es la solución común para la base de datos de código abierto.

Si está utilizando DBMS propietario (Oracle, MSSQL, etc.) para un cifrado a nivel de base de datos con capacidades de control de acceso, probablemente querrá ir con el conjunto de soluciones hermanas de MyDiamo D'Amo . La mayoría de las otras soluciones en el mercado serán principalmente la encriptación a nivel de archivo que, como se indicó anteriormente, frustraría su propósito.

Nota: He estado trabajando como consultor de cifrado de bases de datos y he tratado las soluciones anteriores por un tiempo.