¿Escriba y la cláusula “WHERE” solamente?

3

He tenido una idea dando vueltas en mi cabeza por un tiempo, y me pregunto si hay problemas con ella o simplemente no tiene ningún valor. ¿Qué pasaría si un servidor de base de datos (como Postgres) tuviera una columna que solo pudiera usarse para INSERT o como parte de una cláusula WHERE? Estoy pensando en su uso para almacenar hashes de contraseñas, de manera que incluso con la inyección de SQL, un atacante no podría volcar los hashes. (Sí, los hashes aún estarían en los archivos en el disco). Me parece que esto sería relativamente fácil de implementar y otra capa en una estrategia de defensa en profundidad.

    
pregunta David 17.07.2013 - 05:44
fuente

2 respuestas

3

Un concepto similar, pero potencialmente más sólido es eliminar completamente el acceso a las tablas y administrar todo el acceso a los datos a través de procedimientos almacenados, como se menciona en @CodesInChaos en un comentario.

Si un usuario no tiene acceso para ejecutar consultas SQL directamente contra la tabla, entonces usted tiene control completo sobre los datos que pueden devolverse a la aplicación. Los procedimientos almacenados en este modelo se convierten en una API para la base de datos, esencialmente.

    
respondido por el Xander 17.07.2013 - 15:33
fuente
0

En DB2, column masks se utilizan para lograr el efecto que está describiendo, pero son vulnerables a los ataques de enumeración. Provocarán una máscara (por ejemplo, puede definirla como "CHAR ('XXX-XX-') || SUBSTR (SSN, 8,4)" en lugar del SSN completo) que se devolverá en lugar de los datos para SELECT, pero Todavía se puede utilizar normalmente para DONDE. Se pueden configurar por usuario / grupo / rol.

El ataque de enumeración es el siguiente: si puedo "DÓNDE" el campo "ssn" pero no lo "SELECCIONO", todavía puedo averiguar quién tiene qué SSN:

SELECT name FROM table WHERE ssn = '000-00-0000';
SELECT name FROM table WHERE ssn = '000-00-0001';
SELECT name FROM table WHERE ssn = '000-00-0002';
...
SELECT name FROM table WHERE ssn = '999-99-9999';

Y para algunas de esas adivinanzas afortunadas, el nombre será devuelto y me dirá qué SSN tienen.

Dependiendo de los datos involucrados, la "fuerza bruta" puede ser algo inteligente. Por ejemplo, con los números de tarjetas de crédito, el número completo puede estar protegido, pero el BIN (primeros 6) y los últimos 4 dígitos pueden almacenarse sin cifrar a su lado. Eso permitiría a un atacante enumerar 5 o 6 dígitos en lugar de 15 o 16, y el espacio puede reducirse aún más si el atacante calcula mod 10 antes de intentar números potenciales.

Ese no es un gran ejemplo porque los límites de campo que estamos discutiendo probablemente no satisfacen PCI DSS 3.4 requisitos para proteger los datos PAN. Pero es un ejemplo, y puede traducirse a otras áreas. Por ejemplo, algún subconjunto de la población tiene un SSN asignado según su lugar de nacimiento. Algún subconjunto de ese subconjunto aún vive en la misma área en la que nacieron. En consecuencia, el prefijo SSN de ese sub-subconjunto puede ser adivinado dada su dirección, que puede almacenarse sin cifrar junto con su SSN, reduciendo así el espacio de ataque.

    
respondido por el gowenfawr 17.07.2013 - 14:24
fuente

Lea otras preguntas en las etiquetas