¿Son estos los únicos casos posibles para la inyección de DB?

1

Después de leer un poco sobre las inyecciones de DB (ya sea SQL, NoSQL o cualquier otro lenguaje de consulta de DB), entiendo que solo hay 3 casos posibles para que este tipo de ataque sea efectivo:

  1. Cuando no se instala el mecanismo Transform-To-Pure-Text en el servidor web: Por ejemplo, imprime un formulario HTML con PHP; Este formulario tiene un campo de entrada y los datos se cargan en la base de datos cuando se guarda el formulario. El propietario del servidor web instaló un software de servidor experimental que no tiene un mecanismo para transformar la consulta de base de datos en texto puro y cada vez que se ingrese, se inyectará y modificará la ecología de base de datos normal.

  2. Cuando no se haya instalado el mecanismo Tratar como texto puro : este mecanismo hará que el servidor web trate cualquier entrada de formulario (o al menos cualquier consulta entrada), como texto puro.

  3. Cuando existe alguno de los mecanismos, pero no funciona debido a un error.

¿Son estos los únicos casos en los que se podría realizar una inyección de DB?

    
pregunta JohnDoea 22.12.2016 - 21:55
fuente

1 respuesta

1

Basta con decir, en cuanto a ambos casos, no. 1 & caso. 2 para ser el problema de sanitización de entrada. Pre-liminar al de la desinfección de entrada, hay una validación de entrada, esto podría ser una lista blanca o una lista negra. El enfoque de la lista negra no es el preferido.

Ahora vamos a limitarnos a la respuesta, simplemente no es la conversión de datos, el análisis de datos, la transformación de datos o simplemente la representación de datos de otra fuente que es el punto aquí; las otras fuentes podrían ser la manipulación de datos donde se confunde la lógica del controlador de datos .

Algunos ejemplos podrían ser derivaciones de autenticación básicas, otros podrían ser variantes de inyecciones LDAP. Las posibles causas de las Inyecciones de DB en su caso deberían ser la falta de validación de entrada, la falta de desinfección de entrada, la falta de secuencias de escape, la falta de consultas SQL concatenadas con cadenas, y también la falta de control de acceso a través de políticas que acceden a varias tablas.

Esto podría suceder desde diferentes perspectivas para obtener una escalada; Vamos a discutir sobre algunos:

  1. Bases de datos SQL controladas por dominio interno: invocadas internamente debido a la falta de configuración de políticas.
  2. Aplicaciones web dirigidas externamente debido a la falta de validación de entrada además de la desinfección de entrada.
  3. En el nivel del controlador del controlador de base de datos en sí, un atacante confunde al controlador de la base de datos para pensar que es el usuario autenticado & Se otorgan privilegios.

Algunos mitos son:

La lista blanca será a prueba de pirateos : no permitirá que las entradas proporcionadas por el usuario final se eleven al mismo nivel que la estructura de comandos. En consecuencia, si bien la inclusión en listas blancas forma parte de cualquier enfoque viable de defensa en profundidad de la seguridad, todavía no es suficiente para protegerse contra la inyección de SQL por sí sola.

Los procedimientos almacenados lo harán realmente a prueba de pirateos . Si bien el uso adecuado de los procedimientos almacenados brinda una protección fantástica contra la inyección de SQL, no hay nada mágico en los procedimientos almacenados que los impida. de ser utilizado incorrectamente o inseguro; Los desarrolladores cometen errores de implementación.

Validación de entrada estricta, secuencias de escape & La desinfección de entrada sería suficiente : combinaciones de trucos de codificación, rutinas de escape, homoglifos y caracteres Unicode y ASCII utilizados de manera poco común como un medio para intentar comprometer rutinas de reemplazo de cadenas demasiado simples definidas por desarrolladores que no Piensa como los hackers van a fallar, repetidamente.

Básicamente, la entrada del usuario es el conjunto de problemas raíz & por lo tanto, el lenguaje de comando se separa adecuadamente de los datos o la entrada del usuario & allí estará claramente haciendo un estándar estricto para que las bases de datos de SQL sean seguras.

    
respondido por el Shritam Bhowmick 22.12.2016 - 22:13
fuente

Lea otras preguntas en las etiquetas