c# - tipos - sql injection test

¿El uso de SqlCommand parametrizado hace que mi programa sea inmune a la inyección de SQL?

Question

Soy consciente de que la inyección SQL es bastante peligrosa . Ahora en mi código C # compongo consultas parametrizadas con la clase SqlCommand :

SqlCommand command = ...;
command.CommandText = "SELECT * FROM Jobs WHERE JobId = @JobId;";
command.Parameters.Add("@JobId", SqlDbType.UniqueIdentifier ).Value = actualGuid;
command.ExecuteNonQuery();

¿Esto automáticamente hará que mi código sea inmune a la inyección de SQL? ¿Tengo que hacer algo extra?

Answer 1

Al utilizar SqlCommand una muy buena práctica y siempre que no concatene cadenas de SQL en cualquier lugar (incluso dentro de cualquier procedimiento almacenado que llame, es decir, evite el SQL dinámico), será inmune a los ataques de inyección de SQL.

Answer 2

Diría que para su ejemplo particular, y probablemente canónico, para consultas parametrizadas, sí, es suficiente.

Sin embargo, las personas a veces escriben código como este

cmd.CommandText = string.Format("SELECT * FROM {0} WHERE col = @col;", tableName);
cmd.Parameters.Add("@col", ...);

porque simplemente no hay forma de pasar el nombre de la tabla como un parámetro y el deseo de hacerlo existe a veces: equivocado o no. Parece que a menudo se pasa por alto, que tableName (a menos que tal vez solo se lea de un conjunto de valores estáticos / constantes que no se derivan de ninguna entrada) de hecho permite la inyección de SQL.

Answer 3

La inyección de SQL depende principalmente de la ejecución de SQL dinámico. En otras palabras, declaraciones SQL construidas por la concatenación de SQL con valores ingresados ​​por el usuario.

Para evitar la inyección de SQL por completo,

Protegerse contra ataques de inyección SQL no es muy difícil. Las aplicaciones que son inmunes a ataques de inyección SQL validan y desinfectan todas las entradas de los usuarios, nunca usan SQL dinámico, ejecutan usando una cuenta con pocos privilegios, hash o encriptan sus secretos, y presentan mensajes de error que revelan poca o ninguna información útil para el hacker. Al seguir un enfoque de varias capas para la prevención, puede estar seguro de que si se elude una defensa, seguirá estando protegido.

Desde MSDN

Answer 4

No es inmune a la inyección de SQL si usa sql dinámico, incluso si lo pasa a través de parámetros. Lástima que SQL Server no tenga una función incorporada para desinfectar los parámetros

Answer 5

Según la Nota en este artículo de MSDN , "los caracteres de entrada especiales representan una amenaza solo con SQL dinámico y no cuando se usa SQL parametrizado".

Por lo tanto, creo que está a salvo de la inyección de SQL. Puede haber algunos riesgos lógicos al usar identificadores como Idendity Values ​​en sus URL, pero esta es otra historia.