¿Qué peligros existen al permitir que el usuario ingrese partes de una cadena de conexión ODBC?

Question

¿Qué peligros existen al permitir que el usuario ingrese partes de una cadena de conexión ODBC?

#1 de TobyS (3 votos)
#2 de D.W. (2 votos)

4

Estoy desarrollando una aplicación que permite al usuario ingresar nombres de host, nombres de bases de datos, nombres de usuario y contraseñas para el acceso a la base de datos. La aplicación construirá una cadena de conexión ODBC rellenando los marcadores de posición. En C, eso se traduciría en algo como:

snprintf(connStr, sizeof(connStr),
         "DRIVER={%s};SERVER={%s};DATABASE={%s};UID={%s};PWD={%s}",
         myDriver, hostName, dbName, userName, passWord);

Lo primero que pensé: necesito suprimir el ";" Personaje de todo. (Y indique a los usuarios que sus contraseñas no pueden contener puntos y comas).

¿Soy vulnerable a algún tipo de información hostil en este caso? (Antes de que pregunte, sí, buscaré una entrada excesivamente grande. Puede suponer que el búfer connStr será suficiente. O eso, o usaré un lenguaje de nivel superior con tipos de cadenas administradas).

databases injection

pregunta JCCyC 30.03.2011 - 01:34

fuente

2 respuestas

2

Bueno, no sé si este código es vulnerable. No sé mucho sobre el formato de las cadenas de conexión ODBC.

Pero, para ser honesto, ese código emite malos olores para mí. Aunque no conozco un ataque específico, huele a un riesgo potencial de seguridad. Huele como si pudiera tratarse de una vulnerabilidad de inyección que está por ocurrir.

¿Qué tan seguro está de que conoce la lista completa de todos los metacaracteres que el controlador de la base de datos podría interpretar al procesar la cadena ODBC? (¿Trata las barras invertidas como escapes? ¿Qué pasa si uno de los parámetros definidos por el usuario incluye una llave cerrada, algunas cosas y otra llave abierta? ¿Qué pasa si uno de los parámetros incluye una llave abierta pero no cerrada, y un parámetro posterior incluye ¿Qué sucede?) ¿Qué tan seguro está de que sabe qué codificaciones de caracteres podría usar el controlador de la base de datos al analizar la cadena de conexión? ¿Qué tan seguro está de que esto nunca cambiará, no para cualquier versión futura de la base de datos que usa, o para cualquier otra base de datos a la que pueda cambiar en el futuro? Sé que no estaría seguro de saber las respuestas a cualquiera de estas preguntas. Tal vez sabes más que yo.

Si fuera yo, no me expondría a estos riesgos. Yo sería cauteloso Parece innecesario tomar estos riesgos. En su lugar, sugeriría crear una lista blanca de caracteres que parezcan correctos y restringir todas esas cadenas para que usen solo caracteres dentro de la lista blanca. Tal vez esto sea una precaución innecesaria, pero es lo que yo haría.

respondido por el D.W. 31.03.2011 - 09:24

fuente

Lea otras preguntas en las etiquetas databases injection

¿Puede tener 2 puertos promiscuos (de rastreo) en una sola máquina? Determinar la topología de la red desde el exterior

score 3 · Accepted Answer

Para expandirse un poco en uno de los puntos de @ Sigtran, el filtrado en caracteres deliminadores especiales es, por supuesto, un control clave cuando se protege contra ataques de inyección, sin embargo, también es recomendable proteger contra el potencial de codificaciones creativas utilizando el modo más restrictivo posible. un enfoque de lista blanca en lugar de simplemente reemplazar caracteres como; 'etc. Algunas expresiones regulares como esta podrían ser utilizadas (si no rompes la funcionalidad legítima con solo alfa / num / guiones, por supuesto):

/ [^ A-Za-z-_0-9] / g, ""