Има няколко случая, в които тази функция за бягство ще се провали. Най-очевидното е, когато не се използва единична кавичка:
string table= "\"" + table.Replace("'", "''") + "\""
string var= "`" + var.Replace("'", "''") + "`"
string index= " " + index.Replace("'", "''") + " "
string query = "select * from `"+table+"` where name=\""+var+"\" or id="+index
В този случай можете да „избиете“ с двойни кавички, обратна отметка. В последния случай няма от какво да се „избиете“, така че можете просто да напишете 1 union select password from users-- или каквото полезен товар sql желае нападателят.
Следващото условие, при което тази escape функция няма да успее, е ако се вземе подниз, след като низът е екраниран (и да Открих уязвимости като тази в дивата природа):
string userPassword= userPassword.Replace("'", "''")
string userName= userInput.Replace("'", "''")
userName = substr(userName,0,10)
string query = "select * from users where name='"+userName+"' and password='"+userPassword+"'";
В този случай потребителско име на abcdefgji' ще бъде превърнат в abcdefgji'' чрез escape функцията и след това се превръща обратно в abcdefgji' като вземете подниз. Това може да се използва чрез задаване на стойността на паролата на произволен SQL оператор, в този случай or 1=1-- ще се интерпретира като sql и потребителското име ще се интерпретира като abcdefgji'' and password= . Получената заявка е както следва:
select * from users where name='abcdefgji'' and password=' or 1=1--
T-SQL и други усъвършенствани техники за инжектиране на sql, където вече беше споменато. Advanced SQL Injection In SQL Server Applications е страхотен документ и трябва да го прочетете, ако още не сте го направили.
Последният проблем са атаките на Unicode. Този клас уязвимости възниква, защото escape функцията не знае за многобайтово кодиране и това може да бъде използвано от нападател, за да "консумира" escape символа. Добавянето на "N" към низа няма да помогне, тъй като това не се отразява на стойността на многобайтови знаци по-късно в низа. Този тип атака обаче е много необичайна, тъй като базата данни трябва да бъде конфигурирана да приема GBK unicode низове (и не съм сигурен, че MS-SQL може да направи това).
Инжектирането на код от втори ред все още е възможно, този модел на атака се създава чрез доверие на източници на данни, контролирани от атакуващия. Ескейпирането се използва за представяне на контролните знаци като техен литерал. Ако разработчикът забрави да екранира стойност, получена от select и след това използва тази стойност в друга заявка, след което bam нападателят ще има единични кавички с буквален символ.
Тествайте всичко, не вярвайте на нищо.
