SQL-injektion är en enkel attackvektor som fortfarande är mycket vanlig idag. Anledningen till detta är inget annat än ingen patch för dumhet. Varför säger du detta, låt oss ta JAVA som exempel för att illustrera:
Antag att en sådan tabell finns i databasen:
Använd sedan JDBC:s åtgärdstabell:
Ovanstående kod används ofta av vissa utvecklare. Föreställ dig en situation där parametern för inkommande userId är "3; användare av droppbordet; SQL-satsen som utförs är följande:
Efter att databasen kompilerats och körts tas användartabellen bort. Voilà, en enkel SQL-injektionsattack tar effekt! Detta beror på att koden ovan inte följer programmeringsspecifikationerna.
När vi programmerar enligt specifikationen existerar inte SQL-injektion. Så är det ocksåDet första sättet att undvika SQL-injektion: förkompilerade satser, koden är följande:
Varför finns inte SQL-injektion i koden ovan? Eftersom den förkompilerade satsen används kommer den förkompilerade satsen att sätta "välj namn från användaren där id= ?" Är satsen kompilerad i förväg så att den bara behöver ersättas med de inkommande parametrarna när den körs? Platshållare är okej. För det första icke-kompatibla fallet skriver programmet en SQL-sats och kompilerar den sedan med det innehåll som användaren skickar in, vilket är precis problemet.
Förutom att använda förkompilerade satser finns det ett andra alternativSätt att undvika SQL-injektionsattacker: Lagrade procedurer。 En lagrad produr är en uppsättning SQL-satser som utför en specifik funktion, kompilerad och lagrad i en databas, och användaren kan köra den genom att anropa en lagrad produr och ange en parameter (om den lagrade proceduren har parametrar), vilket också kan undvika SQL-injektionsattacker
Den motsvarande lagrade proceduren i ovanstående kod är följande:
Självklart kan användare också göra teckenkontroll i frontend, vilket också är ett sätt att undvika SQL-injektion: till exempel, för parametern userId ovan, kommer användaren att kontrollera om det finns semikolon och ett fel visas.
Den mest grundläggande anledningen är dock att SQL-injektionsattacker existerar eftersom appar inte använder minsta privilegium när de kommer åt databaser. Det verkar som att alla har använt root-kontot för att komma åt databasen.
Så hur undviker MyBatis SQL-injektionsattacker? Eller ta tabellanvändaren ovan som exempel:
Låt oss säga att mapperfilen är:
De motsvarande Java-filerna är:
Du kan se att indataparametern är userId av typen String, när vi skickar in userId="34; användare av droppbordet; Efter det lyder det tryckta uttalandet:
Oavsett vilket användarID som anges är hans SQL-sats så här. Detta beror på att mybatis använder förkompilerade satser i den underliggande implementationen. När databasen kör det uttalandet använder den direkt den förkompilerade satsen och ersätter sedan platshållaren med det passerande userId? Bara gå och spring. Byta ut platshållare först? Kompileringsprocessen genomförs, så det finns inget utrymme för SQL-injektion att överleva.
Så hur gör MyBatis SQL-prekompilering? Faktum är att klassen PreparedStatement används längst ner i ramverket. PreparedStaement-klassen undviker inte bara SQL-injektion, utan sparar också (N-1) kompileringstid när samma SQL-sats körs N gånger, vilket förbättrar effektiviteten.
Om du ändrar ovanstående uttalande till:
När vi anger userId="34; användare av droppbordet; Efter det lyder det tryckta uttalandet:
I nuläget använder mybatis inga förkompilerade satser, det syr först ihop strängar och utför sedan kompilering, vilket är exakt hur SQL-injektionen träder i kraft.
Därför, när du skriver mybatis-mappningssatser, försök använda formatet "#{xxx}". Om du måste använda parametrar som "${xxx}" måste du manuellt filtrera dem för att förhindra SQL-injektionsattacker.
|
Publicerad på 2018-08-16 10:57:34
|
|
|
