Si la aplicación accede a los datos cifrados en una base de datos, ¿significa que la aplicación tiene la clave de descifrado?

7

Estoy usando una aplicación vinculada a una base de datos que contiene datos confidenciales (números). Según el desarrollador, estos datos están encriptados. Sin embargo, puedo generar fácilmente un informe que muestre los números en texto claro. ¿Cómo puede la aplicación acceder y obtener estos datos si están cifrados? Y si la aplicación accede a los datos, ¿cuáles son los beneficios del cifrado en primer lugar? El ataque puede iniciarse desde la aplicación web en ese caso, lo que superará el cifrado ...

    
pregunta Optimus Prime 25.07.2013 - 09:00
fuente

2 respuestas

6

Esta es una precaución contra (ciertas formas de) inyección de SQL o cualquier persona que pueda acceder a la base de datos de otra manera (violación interna en su servidor de base de datos). La aplicación hará algo como esto:

Fetch information from DB ==> use decrypt function on information ==> present to the user

Mientras que al usar la inyección SQL, usted usará directamente las consultas inyectadas para extraer los datos. Sin embargo, como no puede llamar a la función de descifrado (porque eso es parte del código de la aplicación) que utiliza la aplicación, solo puede obtener datos encriptados.

Esto podría no ser cierto para todas las situaciones en las que puede utilizar la inyección SQL. Si una función es vulnerable a la inyección de SQL donde hay un código que recorre una serie de resultados y descifra esa información y usted es capaz de modificar los resultados recopilados por la función (por ejemplo, inyectando una declaración 1=1 ). Obtendrás esos resultados devueltos, descifrados.

Tenga en cuenta que el cifrado de la base de datos es solo una parte de las medidas de seguridad para fortalecer las aplicaciones basadas en datos. También puede consultar este documento de RSA .

    
respondido por el Lucas Kauffman 25.07.2013 - 09:11
fuente
3

El cifrado consiste en garantizar la confidencialidad . El cifrado no garantiza la confidencialidad en absoluto, pero traduce el problema a la clave : cuando los datos están cifrados, solo podrán leerlos las entidades que tengan acceso a la clave de descifrado. La clave no necesita estar almacenada en el mismo lugar que los datos en sí, y ese es el tipo de separación del que estamos hablando aquí. A saber, los datos encriptados están en la base de datos pero la clave de descifrado es en la aplicación , que puede ser una máquina distinta, por lo que ofrece protección contra los atacantes que pueden obtener un vistazo en el servidor de la base de datos, pero no en la máquina de la aplicación.

Como señala @Lucas, esto funciona contra algunas formas de inyección de SQL siempre que el descifrado no sea factible en SQL . Algunas bases de datos tienen capacidades para realizar la criptografía por sí mismas, por lo que los ataques de inyección de SQL pueden aprovechar estas habilidades. Como caso extremo, considere lo que Microsoft llama Cifrado de datos transparente en SQL Server: todos los datos son cifrado, pero esto lo hace automáticamente el propio servidor de base de datos; La aplicación ni siquiera es consciente de ello. Esto ofrece protección cero (nil, void, nada) contra inyecciones de SQL y otros hacks de nivel de aplicación. TDE solo se aplica a las personas que leen el medio de almacenamiento sin pasar por el código del servidor SQL.

Un atacante que secuestra la máquina de la aplicación podrá leer toda la base de datos y descifrarla por completo, por lo que el cifrado no puede proteger contra eso. De hecho, hay relativamente pocos escenarios plausibles en los que el cifrado de la base de datos realmente ofrece protección adicional (a diferencia de la contraseña hashing , que es unidireccional, y que ofrece mucha protección adicional como segunda línea de defensa).

    
respondido por el Thomas Pornin 25.07.2013 - 17:31
fuente

Lea otras preguntas en las etiquetas