Inyección de cadena sql vs inyección de sql

En realidad, hay casos en los que una inyección SQL es ciega, por lo que no devuelve ningún dato explícito, y las técnicas conocidas en inyecciones SQL ciegas fallan debido a que el resultado no tiene un impacto directo en el comportamiento del programa. Por lo tanto, no se puede extrapolar el comportamiento a los datos.

Sin embargo, para que su escenario realmente funcione, que el resultado de la inyección ciega de SQL se muestre en un mensaje de error, la consulta debe haberse ejecutado con éxito, de lo contrario no devolvería ningún resultado (especialmente no los de el código inyectado). Por lo tanto, debe haber algo más que use el resultado y falle.

Esta puede ser otra declaración SQL que utiliza los valores seleccionados de una declaración SQL anterior. Me gusta lo siguiente:

SELECT vendor_id FROM products WHERE id = $product_id

Y después:

SELECT name FROM vendors WHERE id = $vendor_id

Ahora, si realiza la primera instrucción SELECT, seleccione un valor que no sea válido en la segunda instrucción, i. e., el resultado de @@version :

product_id: 0 UNION SELECT @@version

Lo que resulta en:

SELECT vendor_id FROM products WHERE id = 0 UNION SELECT @@version

Entonces la segunda consulta fallaría como, e. g., 5.5.32-standard no se reconoce como válido en la segunda declaración SQL resultante:

SELECT name FROM vendors WHERE id = 5.5.32-standard

Aquí está el mensaje de error correspondiente informado por MySQL, incluida la declaración fallida con el valor de @@version :

  

Tienes un error en tu sintaxis SQL; consulte el manual que corresponde a la versión de su servidor MySQL para conocer la sintaxis correcta para usar cerca de '.32-standard' en la línea 1: SELECCIONE el nombre DE los proveedores DONDE id = 5.5.32-standard

Esto seguro se puede usar para convertir una inyección ciega de SQL en una no ciega. Y esto también puede suceder con otras rutinas que utilizan el valor seleccionado y reportan errores que contienen el valor seleccionado.

Por cierto, nunca he oído hablar de una distinción entre este tipo de inyecciones. Uno podría decir que está basado en errores, ya que un mensaje de error revela la información. Sin embargo, algunos pueden llamar a esto también una inyección SQL de segundo orden , ya que la inyección ocurre en un segundo paso. Este ejemplo también muestra que no es suficiente simplemente "desinfectar todas las entradas del usuario", ya que no está en la entrada donde ocurre la inyección sino en la salida en la declaración SQL.

Editar: a la luz de la referencia de OP a Blind SQL Injection

No veo ninguna forma en la que la "inyección de SQL basada en cadenas de caracteres" pueda interpretarse específicamente como una forma de inyección de SQL oculta. La inyección ciega de SQL puede ocurrir en cualquier tipo de datos, no en solo cadenas. Por supuesto, puede basarse en cadenas, pero no más que la inyección normal de SQL.

Es cierto que hay al menos un par de artículos en línea, pero creo que han confundido el término. Por ejemplo,

• enlace

• enlace

Los artículos de fuentes más confiables como OWASP no parecen establecer ningún vínculo entre los términos "basado en cadenas" y "ciegos", pero no dude en corregirme. Además, su pregunta parece describir lo que se conoce como Error SQL Inyección que no es ciega, ni está específicamente "basada en cadenas".

Sin embargo, aquí está mi respuesta original que cubre la inyección SQL de cadenas en comparación con otros tipos de datos ...

Esto se reduce a dónde se está inyectando el parámetro vulnerable; más específicamente, ya sea que se inyecte entre comillas (una cadena) o de otra forma (por ejemplo, enteros, marcas de tiempo, etc.).

Por ejemplo, considere la siguiente URL:

http://www.example.com/search?id=23&txt=my+search+string

Ahora supongamos que estos se incorporan dinámicamente a una consulta a través de PHP de la siguiente manera:

$id = $_GET('id');
$txt = $_GET('txt');
$querystring = "SELECT * FROM items WHERE id = $id OR txt = '$txt'"

Si $querystring se ejecutara en SQL, en este caso ambos parámetros serían vulnerables (se han concatenado sin validación ni desinfección).

Sin embargo, el parámetro txt está contenido dentro de las comillas ' , lo que significa que para ejecutar sentencias SQL arbitrarias, primero debe escapar de la cadena incluyendo un carácter ' (es decir, terminamos la cadena nosotros mismos para que nuestro SQL se incluye más adelante). Esto se debe a que cualquier cosa dentro de las comillas forma parte de la cadena de búsqueda y, por lo tanto, no se ejecutará.

Por ejemplo:

http://www.example.com/search?id=23&txt='+OR+1=1--

Esto daría como resultado un $querystring que parecía:

SELECT * FROM items WHERE id = 23 OR txt = '' OR 1=1--'

Así que hemos 'escapado' de la cadena inyectando nuestro propio ' . Por lo tanto, este caso depende en gran medida de poder incluir el carácter ' .

Mientras que el parámetro id solo necesita algunos espacios en blanco:

http://www.example.com/search?id=23+OR+1=1--&txt=my+search+string

...

SELECT * FROM items WHERE id = 23 OR 1=1 OR txt = 'my search string' 

Los principios son los mismos, ya que explotan cómo se manejan las cadenas para abusar de la base de datos y obtener datos u obtener acceso a un sitio.

La única diferencia es que cuando la gente habla de "inyección SQL basada en cadenas" (o inyección de SQL ciego ) por lo general se refieren a un servidor que es vulnerable a este ataque, pero no recibe ninguna pista sobre lo que está sucediendo, por lo tanto, es posible que reciba una página web válida, pero realmente es vulnerable, por lo que debe tomar un enfoque diferente.

Si usas algo como:

  

enlace orden por 10--

Recibe la página web normal, pero cuando usa:

  

enlace 'ordenar por 10 - +

Observe el ' y el + . Aquí recibe un error y con eso la respuesta a su consulta de base de datos.

Puede obtener más lecturas sobre Inyección de SQL en este tutorial de OWASP muy bueno .

Sé que ya hay una respuesta aceptada y que esta pregunta es un poco antigua, pero creo que hay un malentendido aquí.

La inyección SQL basada en cadenas no tiene nada que ver con la inyección ciega.

En los muchos tutoriales que hay por ahí, dicen que cuando

http://example.org/index.php?id=12+order+by+1000--

no funciona porque no te da un error, puedes intentarlo

http://example.org/index.php?id=12'+order+by+1000--+

Esto es no una nueva técnica. No hay nada mágico al respecto.

Muy simple, la primera url no es efectiva porque, incluso si el parámetro es un número, el código del servidor lo trata como una cadena. Su código se inyecta entre dos comillas simples:

SELECT id, author FROM news WHERE id = '12' order by 1000-- '

Tenga en cuenta que el último + es importante porque en MySQL los dos guiones deben ir seguidos de un espacio en blanco o un carácter de control (consulte aquí ).

Por lo tanto, agregar una comilla simple y un plus no es un método mágico que obligue a un sitio a mostrar un error.