¿Cómo puede el saneamiento que escapa a las comillas simples ser derrotado por la inyección SQL en SQL Server?

Con algunas estipulaciones adicionales, su enfoque anterior no es vulnerable a la inyección SQL. El principal vector de ataque a considerar es el contrabando SQL. El contrabando SQL ocurre cuando los caracteres unicode similares se traducen de una manera inesperada (por ejemplo, ` cambiando a ' ). Hay varias ubicaciones donde una pila de aplicaciones podría ser vulnerable al contrabando de SQL.

• ¿El lenguaje de programación maneja adecuadamente las cadenas unicode? Si el idioma no es unicode consciente, puede identificar mal un byte en un carácter unicode como una comilla simple y escapar de él.

• ¿La biblioteca de la base de datos del cliente (por ejemplo, ODBC, etc.) maneja adecuadamente las cadenas unicode? Sistema.Datos.SqlClient en. Net framework lo hace, pero ¿qué hay de las bibliotecas antiguas de la era de Windows 95? En realidad existen bibliotecas ODBC de terceros. ¿Qué sucede si el controlador ODBC no admite unicode en la cadena de consulta?

• La base de datos maneja la entrada correctamente? Las versiones modernas de SQL son inmunes asumiendo que estás usando N", pero ¿qué pasa con SQL 6.5? SQL 7.0? No soy consciente de ninguna vulnerabilidad en particular, sin embargo, esto no estaba en el radar para los desarrolladores en la década de 1990.

• ¿Desbordamientos de búfer? Otra preocupación es que la cadena entre comillas es más larga que la cadena original. ¿En qué versión de Sql Server se introdujo el límite de 2 GB para la entrada? Antes de eso, ¿cuál era el límite? En versiones anteriores de SQL, lo que sucedió cuando una consulta excedió el límite? ¿Existen límites en la longitud de una consulta desde el punto de vista de la biblioteca de red? O en la longitud de la cadena en el lenguaje de programación?

• ¿Hay alguna configuración de idioma que afecte a la comparación utilizada en la función Replace ()?. Net siempre hace una comparación binaria para la función Replace (). ¿Siempre será así? Qué sucede si una versión futura de.NET admite la anulación de ese comportamiento en la aplicación.config nivel? ¿Qué pasa si usamos una regexp en lugar de Replace() para insertar una comilla simple? ¿Afecta la configuración regional del equipo a esta comparación? Si se produjo un cambio en el comportamiento, podría no ser vulnerable a la inyección sql, sin embargo, puede haber editado inadvertidamente la cadena cambiando un carácter de código uni que parecía una comilla simple en una comilla simple antes de que llegara a la base de datos.

Entonces, asumiendo que estás usando el Sistema.Cadena.Función Replace () en C # en la actual versión de. Net con la biblioteca SqlClient incorporada en comparación con una versión actual (2005-2012) de SQL server, entonces su enfoque no es vulnerable. A medida que empiezas a cambiar las cosas, entonces no se pueden hacer promesas. El enfoque de consulta parametrizada es el enfoque correcto para la eficiencia, el rendimiento y (en algunos casos) la seguridad.

ADVERTENCIA Los comentarios anteriores no son una aprobación de esta técnica. Hay varias otras muy buenas razones por las que este es el enfoque equivocado para generando SQL. Sin embargo, detallarlos está fuera del alcance de esta pregunta.

NO UTILICE ESTA TÉCNICA PARA NUEVOS DESARROLLOS.

NO UTILICE ESTA TÉCNICA PARA NUEVOS DESARROLLOS.

NO UTILICE ESTA TÉCNICA PARA NUEVOS DESARROLLOS.

Usar parámetros de consulta es mejor, más fácil y más rápido que escapar comillas.

Con respecto a su comentario, veo que reconoció la parametrización, pero merece énfasis. ¿Por qué querría usar escape cuando podría parametrizar?

En Advanced SQL Injection In SQL Server Applications, busque la palabra "replace" en el texto y, a partir de ese momento, lea algunos ejemplos donde los desarrolladores permitieron inadvertidamente ataques de inyección SQL incluso después de escapando la entrada del usuario.

Hay un caso de borde donde escapar comillas con \ resulta en una vulnerabilidad, porque el \ se convierte en la mitad de un carácter multibyte válido en algunos conjuntos de caracteres. Pero esto no es aplicable a su caso ya que \ no es el carácter de escape.

Como otros han señalado, también puede agregar contenido dinámico a su SQL para algo que no sea un literal de cadena o un literal de fecha. Los identificadores de tabla o columna están delimitados por " en SQL, o [ ] en Microsoft / Sybase. Por supuesto, las palabras clave SQL no tienen delimitadores. Para estos casos, recomiendo incluir en la lista blanca los valores a interpolar.

La conclusión es que escapar es una defensa efectiva, si puedes asegurarte de hacerlo consistentemente. Ese es el riesgo: que uno del equipo de desarrolladores en su aplicación podría omitir un paso y hacer alguna interpolación de cadenas de forma insegura.

Por supuesto, lo mismo es cierto de otros métodos, como parametrización. Solo son efectivos si los haces constantemente. Pero encuentro que es más fácil usar parámetros más rápido que averiguar el tipo correcto de escape. Y es más probable que los desarrolladores usen un método que sea conveniente y no los ralentice.

La inyección SQL se produce si las entradas suministradas por el usuario se interpretan como comandos. Aquí comando significa cualquier cosa que no se interpreta como un reconocido tipo de datos literal.

Ahora bien, si está utilizando la entrada del usuario solo en literales de datos, específicamente solo en literales de cadena, la entrada del usuario solo se interpretaría como algo diferente a los datos de cadena si pudiera dejar el contexto literal de la cadena. Para literales de cadena de caracteres o cadena Unicode, es la comilla simple la marca que encierra los datos literales mientras que las comillas simples incrustadas deben representarse con dos comillas simples.

Por lo tanto, para dejar un contexto literal de cadena, uno necesitaría proporcionar una sola comilla simple (sic) ya que dos comillas simples se interpretan como datos literales de cadena y no como el delimitador final literal de cadena.

Entonces, si está reemplazando cualquier comilla simple en los datos suministrados por el usuario por dos comillas simples, será imposible para el usuario debe dejar el contexto literal de la cadena.

La inyección SQL puede ocurrir a través de unicode. Si la aplicación web tiene una URL como esta:

Http://mywebapp/widgets/?Code = ABC

Que genera SQL like seleccione * de los widgets donde Code = ' ABC '

Pero un hacker entra en esto:

Http://mywebapp/widgets/?Code = ABC % CA % BC; drop widgets de tabla {

El SQL se verá como seleccione * de los widgets donde Code = 'ABC'; drop table widgets {'

Y SQL Server ejecutará dos sentencias SQL. Uno para hacer el select y uno para hacer el drop. Su código probablemente convierte la url codificada % CA % BC en unicode U02BC que es un "apóstrofo de letra modificador". La función Reemplazar en. Net NO tratará eso como una comilla simple. Sin embargo, Microsoft SQL Server lo trata como una comilla simple. Aquí hay un ejemplo que probablemente permitirá la inyección SQL:

string badValue = ((char)0x02BC).ToString();
badValue = badValue + ";delete from widgets--";
string sql = "SELECT * FROM WIDGETS WHERE ID=" + badValue.Replace("'","''");
TestTheSQL(sql);

Probablemente no haya una forma 100% segura si está haciendo concatenación de cadenas. Lo que puede hacer es intentar verificar el tipo de datos para cada parámetro y si todos los parámetros pasan dicha validación, continúe con la ejecución. Por ejemplo, si su parámetro debe ser type int y está obteniendo algo que no se puede convertir a int, simplemente rechácelo.

Esto no funciona si estás aceptando parámetros nvarchar.

Como ya han señalado otros. La forma más segura es usar consulta parametrizada.