Inyección SQL si no se conoce la estructura de la tabla / estructura de la base de datos

Además de lo que dijo Philipp, tenga en cuenta que los ataques de inyección de SQL se realizan con bastante frecuencia sin conocer la estructura de la base de datos, pero una vez que se expone una vulnerabilidad, se puede usar para determinar la estructura.

Por ejemplo, una de las primeras cadenas de inyección SQL que una vez se enseñó solía ser ';shutdown--

Esto supone que los datos proporcionados por el usuario se colocaron entre comillas en una consulta SQL, por lo que la primera comilla en la cadena la cierra y el siguiente punto y coma finaliza la declaración, lo que puede dar como resultado un error. Sin embargo, la siguiente instrucción aún se ejecutaría, que sería shutdown . -- indica que el resto son comentarios. Por lo tanto, esta cadena podría apagar un servidor inmediatamente si la entrada no fue saneada.

Tomando el mismo paso en muchos sistemas de base de datos, como el servidor SQL, la lista de tablas del sistema es bien conocida y si la cuenta que estaba ejecutando la consulta tenía privilegios, podría usarse para enumerar usuarios, tablas, Procs almacenados, vistas y otras configuraciones de SQL. Una vez que se encuentra en la lista, se pueden quitar, exportar y la estructura de las tablas o vistas también se puede enumerar.

Del mismo modo, las consultas se pueden construir para omitir la autenticación, por ejemplo, mediante una cadena como ' or '1'='1' --

Una cadena como la anterior se insertaría en una cláusula WHERE y no importa qué nombre de usuario o contraseña se proporcionó, esto daría lugar a una verdadera evaluación, lo que permitiría al usuario autenticarse sin proporcionar ninguna credencial. por ejemplo:

SELECT * FROM USERS WHERE UserName = '' or '1'='1' --

En resumen, una vez que un ataque de inyección de SQL tiene éxito, el atacante tiene la capacidad de ejecutar código en su servidor, que debería considerarse lo mismo que si estuvieran sentados en el mismo servidor en términos de modelado de amenazas.

Para evitar los ataques, la mayoría de los marcos y sistemas de base de datos proporcionan un mecanismo para consultas parametrizadas. Aunque debería verificar su plataforma, las consultas parametrizadas suelen ser la forma más segura. Si debe crear consultas SQL usted mismo (por ejemplo, para pasar a alguna API externa que lo requiera), considere codificarlo correctamente aunque trataría de evitarlo.

Eso depende.

1. En algunas aplicaciones web, las instrucciones SQL sintácticamente incorrectas dan como resultado un mensaje de error que podría reenviarse a la salida HTML que ve el visitante. Esto podría dar al atacante cierta información sobre el aspecto de la consulta. ("Tiene un error en su consulta SQL cerca de 'myapp_tbl_users'."). Para evitar esto, configure su servidor web para que no muestre mensajes de error detallados.
2. Hay casos en los que los ataques de inyección de SQL dan como resultado que el contenido de la base de datos se imprima en la interfaz. Cuando descubrieron un ataque de este tipo, también pueden usarlo para generar metainformación sobre la base de datos, como las tablas que contiene.
3. Nunca asumas que todos los atacantes son externos. Un sistema seguro también debe ser seguro contra atacantes internos que saben cómo funciona la aplicación.
4. Podría haber una vulnerabilidad no relacionada en su aplicación web que revela el código fuente. Por lo general, estos no son tan críticos, pero cuando también hay una inyección de SQL en su aplicación, podría ayudar al atacante a obtener información sobre la estructura de su base de datos.
5. El atacante puede simplemente adivinar. Las adivinanzas se pueden automatizar (ejecute un script que fuerza de forma bruta posibles nombres de tablas).

Pero la mejor manera de evitar cualquiera de estos problemas es simplemente evitar las inyecciones de SQL en primer lugar. Hay muchas formas mejores de comunicarse con su base de datos SQL que de concatenar cadenas. Utilice procedimientos almacenados, declaraciones preparadas o un contenedor ORM.

Sí : pueden averiguar la estructura de su base de datos utilizando el INFORMATION_SCHEMA .

Muchos tutoriales en línea, como este lo hablan. El proceso, desde un simple exploit hasta la extracción de todos los datos.

Desde el punto de vista de los defensores, podría denegar el acceso a las tablas INFORMATION_SCHEMA. Dudo que su aplicación legítima los use alguna vez. Sin embargo, en ese caso, un atacante podría dañar los nombres de tablas y columnas de fuerza bruta, como sugiere Philipp. En realidad, nunca he visto una aplicación web que niegue el acceso. Es mejor gastar su esfuerzo en prevenir la inyección de SQL en primer lugar.