Hay algunos casos en los que esta función de escape fallará. La más obvia es cuando no se usa una comilla simple:
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 "desglosarse" usando una comilla doble, una tilde invertida. En el último caso, no hay nada de lo que "romperse", por lo que puede escribir 1 union select password from users-- o cualquier carga útil de sql que desee el atacante.
La siguiente condición en la que fallará esta función de escape es si se toma una subcadena después de que se escape la cadena (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 volvió a convertirse en abcdefgji' tomando la subcadena. Esto se puede aprovechar configurando el valor de la contraseña en cualquier instrucció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 mencionaron. Advanced SQL Injection In SQL Server Applications es un excelente documento 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 reconoce la codificación de varios bytes, y un atacante puede utilizarla para "consumir" el carácter de escape. Anteponer una "N" a la cadena no ayudará, ya que esto no afecta el valor de los caracteres de varios bytes más adelante en la cadena. Sin embargo, este tipo de ataque es muy poco común porque la base de datos debe estar configurada para aceptar cadenas Unicode de 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 usa 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 y luego bam el atacante tendrá a su disposición una comilla simple literal de carácter.
Prueba todo, no confíes en nada.
