Buscamos en diferentes espacios y de esta forma darte la solución a tu problema, en caso de dificultades deja tu duda y responderemos porque estamos para servirte.
Solución:
Hay algunos casos en los que esta función de escape fallará. El más obvio es cuando no se usa una sola comilla:
string table= """ + table.Replace("'", "''") + """
string var= "`" + var.Replace("'", "''") + "`"
string index= " " + index.Replace("'", "''") + " "
string query = "select * from `"+table+"` where name=""+var+"" or id="+index
En este caso, puede “romper” con una comilla doble, un tic al revés. En el último caso, no hay nada de lo que “salir”, por lo que puede escribir 1 union select password from users-- o cualquier carga útil sql que desee el atacante.
La siguiente condición en la que esta función de escape fallará es si un sub-string se toma después de la string se ha escapado (y sí He encontrado vulnerabilidades como esta en la naturaleza):
string userPassword= userPassword.Replace("'", "''")
string userName= userInput.Replace("'", "''")
userName = substr(userName,0,10)
string query = "select * from users where name='"+userName+"' and password='"+userPassword+"'";
En este caso, un nombre de usuario de abcdefgji' se convertirá en abcdefgji'' por la función de escape y luego se convirtió de nuevo en abcdefgji' tomando el sub-string. Esto se puede aprovechar estableciendo el valor de la contraseña en cualquier declaración SQL, en este caso or 1=1-- se interpretaría como sql y el nombre de usuario se interpretaría como abcdefgji'' and password=. La consulta resultante es la siguiente:
select * from users where name='abcdefgji'' and password=' or 1=1--
T-SQL y otras técnicas avanzadas de inyección de sql donde ya se mencionó. La inyección avanzada de SQL en aplicaciones de SQL Server es un artículo excelente y debería leerlo si aún no lo ha hecho.
El problema final son los ataques Unicode. Esta clase de vulnerabilidades surge porque la función de escape no es consciente de la codificación de múltiples bytes, y esto puede ser utilizado por un atacante para “consumir” el carácter de escape. Anteponer una “N” al string no ayudará, ya que esto no afecta el valor de los caracteres multibyte más adelante en el string. Sin embargo, este tipo de ataque es muy poco común porque la base de datos debe configurarse para aceptar cadenas unicode GBK (y no estoy seguro de que MS-SQL pueda hacer esto).
La inyección de código de segundo orden aún es posible, este patrón de ataque se crea confiando en las fuentes de datos controladas por el atacante. El escape se utiliza para representar caracteres de control como su carácter literal. Si el desarrollador se olvida de escapar de un valor obtenido de un select y luego usa este valor en otra consulta luego bam el atacante tendrá una comilla simple literal de carácter a su disposición.
Prueba todo, no confíes en nada.
Con algunas estipulaciones adicionales, su enfoque anterior no es vulnerable a la inyección de SQL. El principal vector de ataque a considerar es el contrabando de SQL. El contrabando de SQL se produce cuando se traducen caracteres unicode similares de forma 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 correctamente las cadenas Unicode? Si el idioma no es compatible con Unicode, puede identificar erróneamente 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? System.Data.SqlClient en .Net framework lo hace, pero ¿qué hay de las bibliotecas antiguas de la era de Windows 95? Las bibliotecas ODBC de terceros realmente existen. ¿Qué sucede si el controlador ODBC no admite Unicode en la consulta? string?
-
¿El DB maneja la entrada correctamente? Las versiones modernas de SQL son inmunes asumiendo que está usando N ”, pero ¿qué pasa con SQL 6.5? SQL 7.0? No estoy al tanto de ninguna vulnerabilidad en particular, sin embargo, esto no estaba en el radar de los desarrolladores en la década de 1990.
-
¿Se desborda el búfer? Otra preocupación es que el citado string es más largo que el original string. ¿En qué versión de Sql Server se introdujo el límite de entrada de 2 GB? Antes de eso, ¿cuál era el límite? En versiones anteriores de SQL, ¿qué sucedía cuando una consulta excedía el límite? ¿Existe algún límite en la longitud de una consulta desde el punto de vista de la biblioteca de red? O en la longitud del string en el lenguaje de programación?
-
¿Existe alguna configuración de idioma que afecte la comparación utilizada en la función Reemplazar ()? .Net siempre hace una comparación binaria para la función Reemplazar (). ¿Será ese siempre el caso? ¿Qué sucede si una versión futura de .NET admite anular ese comportamiento en el nivel de app.config? ¿Qué pasa si usamos una expresión regular en lugar de Reemplazar () para insertar una comilla simple? ¿La configuración regional de la computadora afecta esta comparación? Si se produjo un cambio en el comportamiento, es posible que no sea vulnerable a la inyección de sql, sin embargo, puede haber editado inadvertidamente el string cambiando un carácter de código único que parecía una comilla simple en una comilla simple antes de que llegara a la base de datos.
Entonces, asumiendo que está usando la función System.String.Replace () en C # en la versión actual de .Net con la biblioteca SqlClient incorporada contra una versión actual (2005-2012) del servidor SQL, entonces su enfoque no es vulnerable. A medida que comienzas a cambiar las cosas, 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 avalan esta técnica. Hay varias otras muy buenas razones por las que este es el enfoque incorrecto para generar SQL. Sin embargo, detallarlos está fuera del alcance de esta pregunta.
NO USE ESTA TÉCNICA PARA NUEVOS DESARROLLOS.
NO USE ESTA TÉCNICA PARA NUEVOS DESARROLLOS.
NO USE ESTA TÉCNICA PARA NUEVOS DESARROLLOS.
Usar parámetros de consulta es mejor, más fácil y más rápido que escapar de las comillas.
Con respecto a su comentario, veo que reconoció la parametrización, pero merece énfasis. ¿Por qué querrías usar el escape cuando puedes parametrizar?
En Inyección SQL avanzada en aplicaciones SQL Server, busque la palabra “reemplazar” en el texto y, a partir de ese momento, lea algunos ejemplos en los que los desarrolladores permitieron inadvertidamente ataques de inyección SQL incluso después de escapar de la entrada del usuario.
Existe un caso límite en el que las comillas de escape con resulta en una vulnerabilidad, porque el se convierte en la mitad de un carácter multibyte válido en algunos juegos de caracteres. Pero esto no es aplicable a su caso ya que no es el personaje que escapa.
Como otros han señalado, también puede agregar contenido dinámico a su SQL para algo más que un string literal o literal de fecha. Los identificadores de tabla o columna están delimitados por " en SQL, o [] en Microsoft / Sybase. Las palabras clave SQL, por supuesto, no tienen delimitadores. Para estos casos, recomiendo lista blanca los valores a interpolar.
La conclusión es que escapar es una defensa eficaz, si puede asegurarse de hacerlo de forma coherente. Ese es el riesgo: que uno del equipo de desarrolladores de su aplicación pueda omitir un paso y hacer algunos string interpolación insegura.
Por supuesto, lo mismo es true de otros métodos, como la parametrización. Solo son efectivos si los haces de manera constante. Pero encuentro que es más fácil y rápido usar parámetros que averiguar el tipo correcto de escape. Es más probable que los desarrolladores utilicen un método que sea conveniente y no los ralentice.
Acuérdate de que te brindamos la opción de decir si diste con el hallazgo.