c# - tipos - ¿Cuáles son buenas formas de prevenir la inyección de SQL?

pruebas de inyeccion sql

Question

Esta pregunta ya tiene una respuesta aquí:

• ¿Cómo puedo agregar una entrada proporcionada por el usuario a una declaración SQL? 2 respuestas

Tengo que programar un sistema de gestión de aplicaciones para mi empresa OJT. El front end se realizará en C # y el back-end en SQL.

Ahora nunca he hecho un proyecto de este alcance antes; en la escuela solo tuvimos lecciones básicas sobre SQL. De alguna manera, nuestro profesor no pudo hablar sobre las inyecciones de SQL, algo con lo que ahora me he topado leyendo en la red.

Entonces, de todos modos, mi pregunta es: ¿cómo se previenen las inyecciones de SQL en C #? I vagamente creo que se puede hacer enmascarando correctamente los campos de texto de la aplicación para que solo acepte la entrada en un formato específico. Por ejemplo: un cuadro de texto de correo electrónico debe tener el formato "[email protected]". ¿Sería este enfoque suficiente? ¿O .NET tiene métodos predefinidos que manejan cosas como esta? ¿Puedo aplicar un filtro a un cuadro de texto para que solo acepte el formato de dirección de correo electrónico o un cuadro de texto de nombre para que no acepte caracteres especiales?

Answer 1

La inyección SQL puede ser un problema difícil, pero hay formas de evitarlo. Su riesgo se reduce el riesgo simplemente mediante el uso de un ORM como Linq2Entities, Linq2SQL, NHibrenate. Sin embargo, puede tener problemas de inyección de SQL incluso con ellos.

Lo principal con la inyección de SQL es la entrada controlada por el usuario (como ocurre con XSS). En el ejemplo más simple, si tiene un formulario de inicio de sesión (espero que nunca tenga uno que solo lo haga), se requiere un nombre de usuario y una contraseña.

SELECT * FROM Users WHERE Username = ''" + username + "'' AND password = ''" + password + "''"

Si un usuario ingresara lo siguiente para el nombre de usuario Admin ''- la declaración SQL se vería así al ejecutar en contra de la base de datos.

SELECT * FROM Users WHERE Username = ''Admin'' --'' AND password = ''''

En este caso simple, usar una consulta paramaterizada (que es lo que hace un ORM) eliminaría su riesgo. También tiene el problema de un vector de ataque de inyección SQL menos conocido y eso es con los procedimientos almacenados. En este caso, incluso si utiliza una consulta paramaterizada o un ORM, aún tendría un problema de inyección de SQL. Los procedimientos almacenados pueden contener comandos de ejecución, y esos comandos en sí mismos pueden ser aceptables para los ataques de inyección de SQL.

CREATE PROCEDURE SP_GetLogin @username varchar(100), @password varchar(100) AS
DECLARE @sql nvarchar(4000)
SELECT @sql = '' SELECT * FROM users'' +
'' FROM Product Where username = '''''' + @username + '''''' AND password = ''''''+@password+''''''''
EXECUTE sp_executesql @sql

Por lo tanto, este ejemplo tendría el mismo problema de inyección de SQL que el anterior, incluso si utiliza consultas paramaterizadas o un ORM. Y aunque el ejemplo parece tonto, te sorprendería la frecuencia con la que se escribe algo como esto.

Mis recomendaciones serían usar un ORM para reducir inmediatamente las posibilidades de tener un problema de inyección SQL, y luego aprender a detectar el código y los procedimientos almacenados que pueden tener el problema y trabajar para solucionarlos. No recomiendo usar ADO.NET (SqlClient, SqlCommand, etc ...) directamente, a menos que sea necesario, no porque de alguna manera no sea seguro usarlo con parámetros, sino porque es mucho más fácil ser flojo y simplemente comenzar a escribir un SQL consulta usando cadenas y simplemente ignorando los parámetros. ORMS hace un gran trabajo obligándote a usar parámetros porque es justo lo que hacen.

Luego visite el sitio de OWASP sobre inyección SQL https://www.owasp.org/index.php/SQL_Injection y use la hoja de información sobre inyección SQL para asegurarse de que puede detectar y eliminar cualquier problema que surja en su código. https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet último, diría que hay una buena revisión del código entre usted y otros desarrolladores de su empresa, donde puede revisar el código de cada uno de ellos para cosas como inyección SQL y XSS. Muchas veces los programadores pierden estas cosas porque están tratando de apresurar una función y no pasan demasiado tiempo revisando su código.

Answer 2

La inyección de SQL no se debe evitar intentando validar su entrada; en su lugar, esa entrada debe escaparse correctamente antes de pasarla a la base de datos.

Cómo escapar de la entrada depende totalmente de la tecnología que esté utilizando para interactuar con la base de datos. En la mayoría de los casos ya menos que esté escribiendo SQL desnudo (lo cual debe evitar tan duro como sea posible), el marco lo solucionará automáticamente para que obtenga protección a prueba de balas de manera gratuita.

Debería explorar más esta cuestión después de haber decidido exactamente cuál será su tecnología de interfaz.

Answer 3

Mi respuesta es bastante fácil:

Use Entity Framework para la comunicación entre C # y su base de datos SQL. Eso hará cadenas SQL parametrizadas que no son vulnerables a la inyección de SQL.

Como beneficio adicional, es muy fácil trabajar con él también.

Answer 4

Use consultas SQL parametrizadas.

Eche un vistazo a estas preguntas y respuestas: https://.com/search?tab=votes&q=sql%20injection

Una comprensión del concepto de inyección SQL: http://en.wikipedia.org/wiki/SQL_injection

Answer 5

Al usar SqlCommand y su colección de parámetros secundarios, todo el esfuerzo de verificar la inyección de sql se le quita y será manejado por estas clases.

Aquí hay un ejemplo, tomado de uno de los artículos anteriores:

private static void UpdateDemographics(Int32 customerID,
string demoXml, string connectionString)
{
// Update the demographics for a store, which is stored
// in an xml column.
string commandText = "UPDATE Sales.Store SET Demographics = @demographics "
+ "WHERE CustomerID = @ID;";
using (SqlConnection connection = new SqlConnection(connectionString))
{
SqlCommand command = new SqlCommand(commandText, connection);
command.Parameters.Add("@ID", SqlDbType.Int);
command.Parameters["@ID"].Value = customerID;
// Use AddWithValue to assign Demographics.
// SQL Server will implicitly convert strings into XML.
command.Parameters.AddWithValue("@demographics", demoXml);
try
{
connection.Open();
Int32 rowsAffected = command.ExecuteNonQuery();
Console.WriteLine("RowsAffected: {0}", rowsAffected);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}