Tenemos otra discusión aquí en el trabajo sobre el uso de consultas sql parametrizadas en nuestro código. Tenemos dos lados en la discusión: yo y algunos otros que dicen que siempre deberíamos usar parámetros para protegernos de las inyecciones de sql y los otros chicos que no creen que sea necesario. En su lugar, quieren reemplazar apóstrofos simples con dos apóstrofes en todas las cadenas para evitar inyecciones de sql. Todas nuestras bases de datos ejecutan Sql Server 2005 o 2008 y nuestra base de código se ejecuta en .NET framework 2.0.
Déjame darte un ejemplo simple en C #:
Quiero que usemos esto:
string sql = "SELECT * FROM Users WHERE Name=@name";
SqlCommand getUser = new SqlCommand(sql, connection);
getUser.Parameters.AddWithValue("@name", userName);
//... blabla - do something here, this is safe
Mientras que los otros chicos quieren hacer esto:
string sql = "SELECT * FROM Users WHERE Name=" + SafeDBString(name);
SqlCommand getUser = new SqlCommand(sql, connection);
//... blabla - are we safe now?
Donde la función SafeDBString se define de la siguiente manera:
string SafeDBString(string inputValue)
{
return "'" + inputValue.Replace("'", "''") + "'";
}
Ahora, siempre que usemos SafeDBString en todos los valores de cadena en nuestras consultas, deberíamos estar seguros. ¿Correcto?
Hay dos razones para utilizar la función SafeDBString. Primero, es la forma en que se ha hecho desde la edad de piedra, y segundo, es más fácil depurar las declaraciones sql ya que ve la consulta exacta que se ejecuta en la base de datos.
Por lo que entonces. Mi pregunta es si realmente es suficiente usar la función SafeDBString para evitar ataques de inyección SQL. He estado tratando de encontrar ejemplos de código que rompa esta medida de seguridad, pero no puedo encontrar ningún ejemplo de ello.
¿Hay alguien ahí fuera que pueda romper esto? ¿Como lo harias?
EDITAR: Para resumir las respuestas hasta ahora:
- Nadie ha encontrado una manera de sortear SafeDBString en Sql Server 2005 o 2008 todavía. Eso es bueno, creo.
- Varias respuestas señalaron que se obtiene una ganancia de rendimiento cuando se utilizan consultas parametrizadas. La razón es que los planes de consulta se pueden reutilizar.
- También estamos de acuerdo en que el uso de consultas parametrizadas proporciona un código más legible que es más fácil de mantener.
- Además, es más fácil usar siempre parámetros que usar varias versiones de SafeDBString, conversiones de cadena a número y conversiones de cadena a fecha.
- Usando parámetros obtienes conversión automática de tipos, algo que es especialmente útil cuando estamos trabajando con fechas o números decimales.
- Y finalmente: no intente hacer la seguridad usted mismo como escribió JulianR. Los proveedores de bases de datos gastan mucho tiempo y dinero en seguridad. No hay forma de que podamos hacerlo mejor y no hay razón por la que debamos intentar hacer su trabajo.
Entonces, aunque nadie pudo romper la seguridad simple de la función SafeDBString, obtuve muchos otros buenos argumentos. ¡Gracias!