Confusión con blind SQL injection

[Schaiden]

Buenas! Hay lugares en los que te explican blind SQL injection de una forma y otros en los que te la explican de otra.

Explicación 1:
Blind SQL injection se da cuando el servidor no muestra mensajes de error al hacer una consulta SQL malformada, sin darle información al atacante sobre como podría formar una consulta válida.

Explicación 2:
Blind SQL injection se da cuando los datos consultados en la inyección no son mostrados en la misma web, por lo tanto para comprobar su existencia hacen faltas de pruebas basadas en tiempo, etc, para confirmar según el comportamiento del servidor si un dato existe o no.

Según el tiempo que llevo usando sqlmap, y artículos y cosas que vengo leyendo, para mi lo que más tiene sentido que sea una blind SQL injection es la de la explicación 2. O sea si el servidor simplemetne no muestra información de error no complicaría tanto las cosas. Solo hay que probar varias inyecciones hasta que se muestre los datos que esperamos ver. En el otro caso hay que hacer pruebas muy distintas basadas en tiempo...

Bueno, me gustaría que me ayudaran a despejar ésta duda.

Saludos!

[BloodSharp]

Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible.

Basadas en tiempo es solo una manera, si te leés la documentación del enlace, esta provee varios ejemplos.


B#

[Schaiden]

Bueno, excelente, muchas gracias BloodSharp! alguna vez creo haber leido exactamente esa definición y en éste caso se acemeja a lo que les marque como "explicacion 2". Pero ahora casualmente estaba leyendo la guía de pruebas de OWASP y miren:



Lo que resalté en amarillo hace referencia al mismo concepto que yo marqué como "explicación 2" y que vos BloodSharp me acabas de citar de la mismisima página de OWASP haciendo referencia al concepto de blind sqli... En éste caso, a ese concepto no lo toman como blind SQL injection, sino como una de las tres clases en las que se dividen los ataques de sqli.

Y en lo que remarqué en rojo se hace referencia a mi "explicación 1", lo cuál en ésta guía de pruebas OWASP lo considera blind SQL injection...

No entiendo como OWASP se contradice, o mezcla las cosas. Tal vez sea un error de traducción.

[BloodSharp]

Enlace de OSWAP original.

SQL Injection attacks can be divided into the following three classes:

   Inband: data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page.
   Out-of-band: data is retrieved using a different channel (e.g., an email with the results of the query is generated and sent to the tester).
   Inferential or Blind: there is no actual transfer of data, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behavior of the DB Server.


A successful SQL Injection attack requires the attacker to craft a syntactically correct SQL Query. If the application returns an error message generated by an incorrect query, then it may be easier for an attacker to reconstruct the logic of the original query and, therefore, understand how to perform the injection correctly. However, if the application hides the error details, then the tester must be able to reverse engineer the logic of the original query.

Sugeriría para la próxima vez buscar la información original, no la traducida por una máquina/persona que traduzca el texto omitiendo detalles o modificando el significado de la expliación

Con respecto a la manera ciega o inferida, no es que realmente no haya transferencia de datos siempre te puede responder con datos o sin datos dependiendo de la configuración.
Si el demonio está configurado para que no envíe respuestas erróneas se le infiere ciegamente (porque no vemos al principio una respuesta) una "comprobación extra" la cuál de entrada se sabe la respuesta (verdadero o falso) forzando a que aparezca alguna salida (errónea o no) con la respuesta esperada verdadera/falsa, finalmente el programa le aplica un filtro para remover verdadero/falso y te queda en la aplicación tuya de la interfaz la respuesta de la inyección solamente.


B#