Der er nogle få tilfælde, hvor denne escape-funktion vil mislykkes. Det mest oplagte er, når et enkelt citat ikke bruges:
string table= "\"" + table.Replace("'", "''") + "\""
string var= "`" + var.Replace("'", "''") + "`"
string index= " " + index.Replace("'", "''") + " "
string query = "select * from `"+table+"` where name=\""+var+"\" or id="+index
I dette tilfælde kan du "bryde ud" ved at bruge et dobbelt anførselstegn, et flueben. I det sidste tilfælde er der ikke noget at "bryde ud" af, så du kan bare skrive 1 union select password from users-- eller hvilken sql-nyttelast angriberen ønsker.
Den næste betingelse, hvor denne escape-funktion mislykkes, er, hvis en understreng tages, efter at strengen er escaped (og ja Jeg har fundet sårbarheder som denne i naturen):
string userPassword= userPassword.Replace("'", "''")
string userName= userInput.Replace("'", "''")
userName = substr(userName,0,10)
string query = "select * from users where name='"+userName+"' and password='"+userPassword+"'";
I dette tilfælde brugernavnet abcdefgji' vil blive omdannet til abcdefgji'' af escape-funktionen og derefter vendt tilbage til abcdefgji' ved at tage understrengen. Dette kan udnyttes ved at indstille adgangskodeværdien til en hvilken som helst sql-sætning, i dette tilfælde or 1=1-- ville blive fortolket som sql, og brugernavnet ville blive fortolket som abcdefgji'' and password= . Den resulterende forespørgsel er som følger:
select * from users where name='abcdefgji'' and password=' or 1=1--
T-SQL og andre avancerede sql-injektionsteknikker er allerede nævnt. Avanceret SQL-injektion i SQL Server-applikationer er et fantastisk papir, og du bør læse det, hvis du ikke allerede har gjort det.
Det sidste problem er unicode-angreb. Denne klasse af sårbarheder opstår, fordi escape-funktionen ikke er opmærksom på multi-byte-kodning, og denne kan bruges af en angriber til at "forbruge" escape-karakteren. Det hjælper ikke at sætte et "N" foran strengen, da dette ikke påvirker værdien af multi-byte-tegn senere i strengen. Denne type angreb er dog meget ualmindelig, fordi databasen skal konfigureres til at acceptere GBK unicode-strenge (og jeg er ikke sikker på, at MS-SQL kan gøre dette).
Andenordens kodeindsprøjtning er stadig mulig, dette angrebsmønster er skabt ved at stole på angriberkontrollerede datakilder. Escape bruges til at repræsentere kontrolkarakterer som deres bogstavelige karakter. Hvis udvikleren glemmer at undslippe en værdi opnået fra en select og bruger derefter denne værdi i en anden forespørgsel end bam angriberen vil have et bogstaveligt enkelt citat til deres rådighed.
Test alt, stol ikke på noget.