¿Los procedimientos almacenados evitan la inyección de SQL?

¿Es cierto que los procedimientos almacenados evitan ataques de inyección SQL contra bases de datos PostgreSQL? Investigué un poco y descubrí que SQL Server, Oracle y MySQL no están seguros contra la inyección de SQL, incluso si solo utilizamos procedimientos almacenados. Sin embargo, este problema no existe en PostgreSQL.

¿La implementación del procedimiento almacenado en el núcleo de PostgreSQL previene los ataques de inyección SQL o es algo más? ¿O PostgreSQL también es susceptible a la inyección de SQL incluso si solo usamos procedimientos almacenados? Si es así, muéstrame un ejemplo (por ejemplo, libro, sitio, papel, etc.).

No, los procedimientos almacenados no impiden la inyección de SQL. Aquí hay un ejemplo real (de una aplicación interna que alguien creó donde trabajo) de un procedimiento almacenado que desafortunadamente permite la inyección de SQL:

Este código de servidor sql:

CREATE PROCEDURE [dbo].[sp_colunmName2]   
    @columnName as nvarchar(30),
    @type as nvarchar(30), 
    @searchText as nvarchar(30)           
AS
BEGIN
    DECLARE @SQLStatement NVARCHAR(4000)
    BEGIN
        SELECT @SQLStatement = 'select * from Stations where ' 
            + @columnName + ' ' + @type + ' ' + '''' + @searchText + '''' 
        EXEC(@SQLStatement)
    END      
END
GO

aproximadamente equivalente a postgres:

CREATE or replace FUNCTION public.sp_colunmName2 (
    columnName  varchar(30),
    type varchar(30), 
    searchText  varchar(30) ) RETURNS SETOF stations LANGUAGE plpgsql            
AS
$$
DECLARE SQLStatement VARCHAR(4000);
BEGIN
    SQLStatement = 'select * from Stations where ' 
            || columnName || ' ' || type || ' ' || ''''|| searchText || '''';
    RETURN QUERY EXECUTE  SQLStatement;
END
$$;

La idea del desarrollador era crear un procedimiento de búsqueda versátil, pero el resultado es que la cláusula WHERE puede contener todo lo que el usuario desee, lo que permite una visita de las pequeñas Bobby Tables .

No importa si usa sentencias SQL o procedimiento almacenado. Lo que importa es si su SQL usa parámetros o cadenas concatenadas. Los parámetros evitan la inyección de SQL; cadenas concatenadas permiten la inyección de SQL.

Los ataques de inyección SQL son aquellos en los que la entrada no confiable se agrega directamente a las consultas, lo que permite al usuario ejecutar efectivamente código arbitrario, como se ilustra en este cómic canónico XKCD.

Por lo tanto, obtenemos la situación:

userInput = getFromHTML # "Robert ') Descartar estudiantes de la tabla; -"

Query = "Seleccionar * de estudiantes donde studentName =" + userInput

Los procedimientos almacenados son, en general, buenas defensas contra los ataques de inyección SQL porque los parámetros entrantes nunca se analizan.

En un procedimiento almacenado, en la mayoría de los DB (y programas, no olvide que las consultas precompiladas cuentan como procedimientos almacenados) tienen el siguiente aspecto:

 

crear procedimientos almacenados foo (
seleccione * de estudiantes donde studentName =: 1
);

Luego, cuando el programa desea acceder, llama foo(userInput)y felizmente recupera el resultado.

Un procedimiento almacenado no es una defensa mágica contra la inyección de SQL, ya que las personas pueden escribir procedimientos almacenados incorrectos . Sin embargo, las consultas precompiladas, ya sean almacenadas en la base de datos o en el programa, son mucho más difíciles de abrir agujeros de seguridad si comprende cómo funciona la inyección SQL.

Puede leer más sobre la inyección SQL:

• En esta discusión de Jeff Atwood
• Hoja de trucos de prevención
• Cómo atacar su propio código (Asegúrese de que su control de calidad incluya pruebas de seguridad. Si no lo hace, su sitio será probado por el exterior. Esto es algo malo).

Sí, hasta cierto punto.
Los procedimientos almacenados por sí solos no impedirán la inyección de SQL.

Permítanme citar primero sobre la inyección SQL de OWASP

Un ataque de inyección SQL consiste en la inserción o "inyección" de una consulta SQL a través de los datos de entrada del cliente a la aplicación. Una explotación de inyección SQL exitosa puede leer datos confidenciales de la base de datos, modificar datos de la base de datos (Insertar / Actualizar / Eliminar), ejecutar operaciones de administración en la base de datos (como apagar el DBMS), recuperar el contenido de un archivo dado presente en el archivo DBMS sistema y en algunos casos emiten comandos al sistema operativo. Los ataques de inyección SQL son un tipo de ataque de inyección, en el que los comandos SQL se inyectan en la entrada del plano de datos para efectuar la ejecución de comandos SQL predefinidos.

Debe desinfectar las entradas del usuario y no concatenar las declaraciones SQL, incluso si está utilizando un procedimiento almacenado.

Jeff Attwood explicó las consecuencias de concatenar sql en " Dame SQL parametrizado o dame la muerte "

Lo siguiente es la caricatura interesante que viene a mi mente cada vez que escucho SQL Injection , creo que entendiste :-)

Eche un vistazo a la hoja de trucos de prevención de inyección SQL , los métodos de prevención se explican de forma clara ...

La concatenación de cadenas es la causa de la inyección de SQL. Esto se evita utilizando la parametrización.

Los procedimientos almacenados agregan una capa adicional de seguridad al aplicar una sintaxis no válida cuando concatena, pero no son "más seguros" si usa, por ejemplo, SQL dinámico en ellos.

Entonces, su código anterior es causado por la concatenación de estas cadenas

• exec sp_GetUser '
• x' AND 1=(SELECT COUNT(*) FROM Client); --
• ' , '
• monkey
• '

Esto da una sintaxis no válida, por suerte

Parametrizarlo daría

exec sp_GetUser 'x'' AND 1=(SELECT COUNT(*) FROM Client); --' , 'monkey'

Esto significa

• @UserName = x' AND 1=(SELECT COUNT(*) FROM Client); --
• @Password = monkey

Ahora, en el código anterior no obtendrás filas porque supongo que no tienes usuario x' AND 1=(SELECT COUNT(*) FROM Client); --

Si el proceso almacenado se veía así (usando SQL dinámico concatenado ), entonces su llamada de proceso almacenado parametrizada todavía permitirá la inyección SQL

...
SET @sql = 'SELECT userName from users where userName = ''' + 
               @UserName + 
               ''' and userPass = ''' +
               @Password +
               ''''
EXEC (@sql)
....

Entonces, como se demostró, la concatenación de cadenas es el principal enemigo para la inyección de SQL

Los procedimientos almacenados agregan encapsulación, manejo de transacciones, permisos reducidos, etc., pero aún se puede abusar de ellos para la inyección de SQL.

Puede consultar Stack Overflow para obtener más información sobre la parametrización.

"Ataques de inyección SQL ocurren cuando la entrada del usuario se codifica de manera incorrecta. Típicamente, la entrada de usuario se algunos datos que el usuario envía con su consulta, es decir, valores en los $_GET, $_POST, $_COOKIE, $_REQUEST, o $_SERVERarrays. Sin embargo, la entrada del usuario pueden también provienen de una variedad de otros fuentes, como sockets, sitios web remotos, archivos, etc. Por lo tanto, realmente debe tratar todo menos las constantes (como 'foobar') como entrada del usuario ".

He estado investigando a fondo sobre este tema recientemente y me gustaría compartir con otros material bastante interesante, por lo que esta publicación es más completa e instructiva para todos.

• Prevención de inyección SQL con PHP por John Nebel
• Rincón de seguridad - Inyección SQL por Chris Shiflett
• La inyección SQL inesperada por Alexander Andonov
• Mysql_real_escape_string () versus declaraciones preparadas por Ilia Alshanetsky
• SQL Injection Attack and Defense por Sagar Joshi
• Ataques de inyección SQL por el profesor Jim Whitehead
• addlashes () vs mysql_real_escape_string () por Chris Shiflett
• ¿Qué es un error de inyección SQL por Joel Spolsky?
  
  
• MySQL - Prevención de inyección SQL
• Tutorial de inyección SQL
• Hoja de trucos de inyección SQL
• Declaraciones preparadas en PHP y MySQLi

De YouTube

• Inyección de SQL Mitos y falacias: mejores prácticas de defensa por Bill Karwin
• Tutoriales PHP: Seguridad - Inyección SQL
• Cómo inyectar SQL con SQLMAP en Backtrack5 RC1

De Wikipedia

• Wikipedia - Inyección SQL
• Wikipedia - SQL

De OWASP

• Inyección SQL
• Guía de inyección SQL
• OWASP: evitar la inyección de SQL
• Hoja de trucos de prevención de inyección SQL
• Prueba para inyección SQL

Del manual de PHP

• Inyección SQL
• Clase PDO: declaraciones preparadas y procedimientos almacenados
• Extensión mejorada de MySQL
• mysql_real_escape_string ()

De Microsoft y Oracle

• ¿Cuál es la forma correcta de prevenir la inyección de SQL en PHP Scripts por Microsoft?
• Detenga los ataques de inyección SQL antes de que lo detengan por Microsoft
• Defensa contra ataques de inyección SQL de Oracle

Desbordamiento de pila

• Inyecciones SQL y biblioteca ADOdb! Seguridad general del sitio web PHP con ejemplos
• La mejor manera de prevenir la inyección SQL en PHP
• Inyección SQL XKCD - explique
• ¿Cuál es la mejor manera de evitar ataques de inyección SQL?
• ¿Qué es la inyección SQL?
• Inyección SQL en INSERT
• ¿Cómo protejo esta función de la inyección SQL?
• ¿Son los parámetros realmente suficientes para prevenir las inyecciones de SQL?
• ¿Es la inyección de SQL un riesgo hoy?
• Inyección SQL
• Inyección SQL piratería ética
• ¿Este código impide la inyección de SQL?

Escáner de inyección SQL

• Top 15 escáner de inyección SQL
• Netsparker Community Edition, escáner de inyección SQL gratuito y escáner XSS

Los procedimientos almacenados no evitan mágicamente la inyección de SQL, pero sí hacen que evitarlo sea mucho más fácil. Todo lo que tienes que hacer es algo como lo siguiente (ejemplo de Postgres):

CREATE OR REPLACE FUNCTION my_func (
  IN in_user_id INT 
)
[snip]
  SELECT user_id, name, address FROM my_table WHERE user_id = in_user_id; --BAM! SQL INJECTION IMMUNE!!
[snip]

¡Eso es! El problema solo surge cuando se forma una consulta a través de la concatenación de cadenas (es decir, SQL dinámico), ¡e incluso en esos casos puede vincular! (Depende de la base de datos).

Cómo evitar la inyección de SQL en su consulta dinámica:

Paso 1) Pregúntese si realmente necesita una consulta dinámica. Si está uniendo cadenas solo para configurar la entrada, entonces probablemente lo esté haciendo mal. (Hay excepciones a esta regla: una excepción es para informar consultas en algunas bases de datos, puede tener problemas de rendimiento si no lo obliga a compilar una nueva consulta con cada ejecución. Pero investigue este problema antes de saltar a eso. )

Paso 2) Investigue la forma correcta de establecer la variable para su RDBMS particular. Por ejemplo, Oracle le permite hacer lo siguiente (citando sus documentos):

sql_stmt := 'UPDATE employees SET salary = salary + :1 WHERE ' 
           || v_column || ' = :2';
EXECUTE IMMEDIATE sql_stmt USING amount, column_value; --INJECTION IMMUNE!!

Aquí todavía no está concatenando la entrada. ¡Estás atado de forma segura! ¡Hurra!

Si su base de datos no admite algo como lo anterior (es de esperar que ninguno de ellos siga siendo tan malo, pero no me sorprendería), o si todavía debe concatenar su entrada (como en el caso "a veces" de informar consultas como Insinué arriba), entonces debe usar una función de escape adecuada. No lo escribas tú mismo. Por ejemplo, postgres proporciona la función quote_literal (). Entonces correría:

sql_stmt := 'SELECT salary FROM employees WHERE name = ' || quote_literal(in_name);

De esta manera, si in_name es algo tortuoso como '[snip] o 1 = 1' (la parte "o 1 = 1" significa seleccionar todas las filas, ¡permitiendo al usuario ver los salarios que no debería!), Entonces quote_literal guarda su trasero por haciendo la cadena resultante:

SELECT salary FROM employees WHERE name = '[snip] or 1=1'

No se encontrarán resultados (a menos que tenga algunos empleados con nombres realmente extraños).

Esa es la esencia de esto! Ahora déjame dejarte con un enlace a una publicación clásica del gurú de Oracle Tom Kyte sobre el tema de la inyección SQL, para llevar el punto a casa: Linky