¿Cómo el procedimiento almacenado impide la inyección de SQL?

Los procedimientos almacenados son una forma de consulta parametrizada. El problema fundamental que causa la inyección de SQL es que los datos se tratan como lenguaje de consulta.

$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";

En este ejemplo, si configuro $password en foo' OR 'x'='x , obtendremos esto:

SELECT * FROM users WHERE username = 'blah' AND password = 'foo' OR 'x'='x'

Dado que el carácter 'x' siempre es igual al carácter 'x', esta consulta siempre devolverá filas independientemente de si el usuario / paso es correcto. La base de datos no puede saber que no fue su intención, porque solo se le asigna una cadena sin contexto.

Para evitar esto, debe poder saber la diferencia entre la consulta y los datos. Los procedimientos almacenados resuelven este problema escribiendo la consulta de antemano, con marcadores para los parámetros, de modo que los datos se puedan pasar a ellos más adelante. Por ejemplo:

SELECT * FROM users WHERE username = ? AND password = ?

El controlador de la base de datos envía el nombre de este procedimiento almacenado (o, en consultas parametrizadas estándar, solo el propio texto de consulta) y una lista de parámetros, como entidades separadas distintas en el protocolo. Esto significa que el servidor de la base de datos puede analizar la cadena de consulta como lenguaje de consulta de forma segura y tratar los parámetros únicamente como datos, sin ninguna ambigüedad.

También escribí un artículo más largo. responda hace un tiempo que explica todo esto de una manera más detallada, si eso te sirve.

Los procedimientos almacenados no son inmunes a la inyección de SQL . Como se explica aquí:

enlace

Siempre que se pueda crear SQL dinámico dentro de los procedimientos almacenados, usted es vulnerable a la inyección de SQL.

Y MySQL a partir de 5.0.13 en adelante, tienen capacidad de SQL dinámico:

enlace

Y, por lo tanto, es vulnerable a la inyección de SQL.

En servidor SQL , aquí hay un ejemplo:

enlace

VULNERABLE STORED PROCEDURE USING EXEC STATEMENT.
CREATE PROCEDURE getDescription
   @vname VARCHAR(50)
AS
   EXEC('SELECT description FROM products WHERE name = '''+@vname+ '''')
RETURN

Y otro ejemplo:

VULNERABLE STORED PROCEDURE USING DYNAMIC CURSOR.
CREATE PROCEDURE printDescriptions
   @vname             VARCHAR(100)
AS
   DECLARE @vdesc VARCHAR(1000)
   DECLARE @vsql VARCHAR(4000)
   SET @vsql = 'SELECT description FROM products WHERE name='''+@vname+''''
   DECLARE cur CURSOR FOR EXEC @vsql

   OPEN cur
   FETCH NEXT FROM cur INTO @vdesc

   WHILE @@FETCH_STATUS = 0
   BEGIN
      PRINT @vdesc
      FETCH NEXT FROM cur INTO @vdesc
   END

   CLOSE cur
   DEALLOCATE cur
RETURN

Y en Oracle , aquí están los ejemplos:

enlace

enlace

La presentación anterior de David Litchfield en Blackhat Europe tiene algo más serio, de la inyección de SQL que puede llevar a una escalada de privilegios, por lo que un usuario de Oracle normal puede ejecutarse como DBA si los procedimientos almacenados son creados por DBA (por ejemplo, todos los objetos del sistema Oracle).

Una base de datos SQL trabaja una declaración en varios pasos. Al principio se analiza la prueba de la declaración SQL, después de eso se optimizará y compilará. Cuando esto termine, la base de datos tiene ahora una pieza interna de software que puede ejecutar la declaración SQL dada.

Los procedimientos almacenados están precompilados. En otras palabras, la base de datos crea esa pieza interna de software antes de usarla. En este caso, solo el código de programación se interpreta sin ninguna influencia de los parámetros.

Si pasa un parámetro inclusivo de la sentencia SQL completa a la base de datos, procesará los pasos descritos anteriormente.

Por ejemplo ...

SELECT * FROM myTable WHERE id=1

o le das algo así ...

SELECT * FROM myTable WHERE id=1;DROP TABLE myTable

Normalmente, nadie escribiría una declaración como la segunda en su código de programación, pero si toma por ejemplo parámetros directos de una solicitud web, es posible que una declaración como esa resulte.

var sqlString="SELECT * FROM myTable WHERE id=";
sqlString = sqlString+request.getParameter("id");
// database parse, compile and optimize
var result=database.doQuery(sqlString);

Si utiliza procedimientos almacenados o declaración preparada. El proceso de análisis y compilación ya está hecho en la base de datos. Toda la interpretación depende de su código de programación. Cuando la llama a la base de datos, solo inserte los parámetros dados en el código precompilado y ahora se muestran los tipos de datos aceptados.

var sqlString = "call queryMyTable(?)";
// get the precompiled statement from database
var statement = database.createStatement(sqlString);
// inject the parameter
statement.setParameter(1,request.getParameter("id"));
// if 'id' is a number it works fine ...
// but if 'id' is '1;DROP TABLE myTable' you will got a type cast error and the risk of SQL injection is banned
var result = statement.execute();

Los procedimientos almacenados y las declaraciones preparadas están a la vista de la seguridad igual.

Otra forma de pensarlo, de ser explícito y de aumentar las respuestas ya dadas.

SELECT * FROM users WHERE username = 'blah' AND password = 'foo' OR 'x'='x'

Sin la declaración preparada, OR después de que 'foo' se trate como código

Ahora, con la declaración preparada, OR (y todo lo demás) después de que 'foo' se trate como datos