SQL-injektion er en simpel angrebsvektor, som stadig er meget almindelig i dag. Årsagen til dette er intet andet end ingen patch for dumhed. Hvorfor siger du det? Lad os tage JAVA som eksempel for at illustrere:
Antag, at en tabel som denne findes i databasen:
Brug derefter JDBC's handlingstabell:
Ovenstående kode bruges ofte af nogle udviklere. Forestil dig en situation, hvor parameteren for den indkommende userId er "3; bruger af drop-table; Den udførte SQL-sætning er som følger:
Efter databasen er kompileret og eksekveret, slettes brugertabellen. Voila, et simpelt SQL-injektionsangreb træder i kraft! Dette skyldes, at koden ovenfor ikke overholder programmeringsspecifikationerne.
Når vi programmerer efter specifikationen, eksisterer SQL-injektion ikke. Det er også tilfældetDen første måde at undgå SQL-injektion på: prækompilerede sætninger, koden er som følger:
Hvorfor findes SQL-injektion ikke i ovenstående kode? Fordi den forudkompilerede sætning bruges, vil den forudkompilerede sætning sætte "vælg navn fra bruger, hvor id= ?" Er sætningen kompileret på forhånd, så den kun behøver at blive erstattet med de indkommende parametre ved udførelsen? Pladsholdere er fine. I det første ikke-kompatible tilfælde vil programmet skrive en SQL-sætning og derefter kompilere den med det indhold, brugeren har sendt ind, hvilket netop er problemet.
Ud over at bruge forudkompilerede sætninger findes der en anden mulighedMåder at undgå SQL-injektionsangreb på: Lagrede procedurer。 En lagret procedure er et sæt SQL-sætninger, der udfører en specifik funktion, kompileret og gemt i en database, og brugeren kan udføre den ved at kalde en lagret procedure og angive en parameter (hvis den lagrede procedure har parametre), som også kan undgå SQL-injektionsangreb
Den tilsvarende lagrede procedure i ovenstående kode er som følger:
Selvfølgelig kan brugere også lave tegnkontrol på frontend, hvilket også er en måde at undgå SQL-injektion på: for eksempel vil brugeren for operatorId-parameteren ovenfor tjekke for et semikolon, og en fejl vil blive vist.
Den mest grundlæggende årsag er dog, at SQL-injektionsangreb eksisterer, fordi apps ikke bruger least privilege, når de tilgår databaser. Det ser ud til, at alle har brugt root-kontoen til at få adgang til databasen.
Så hvordan undgår MyBatis SQL-injektionsangreb? Eller tag tabelbrugeren ovenfor som eksempel:
Lad os sige, at mapperfilen er:
De tilsvarende java-filer er:
Du kan se, at inputparameteren er userId af typen String, når vi sender userId="34; bruger af drop-table; Derefter lyder den trykte erklæring:
Uanset hvilket brugerID der er indtastet, er hans SQL-sætning sådan her. Dette skyldes, at mybatis bruger forudkompilerede udsagn i den underliggende implementering. Når databasen udfører den sætning, bruger den direkte den prækompilerede sætning og erstatter derefter pladsholderen med den passerende userId? Bare løb. Udskifte pladsholdere først? Kompileringsprocessen udføres, så der er ikke plads til, at SQL-injektion kan overleve.
Så hvordan laver MyBatis SQL-prekompilering? Faktisk bruges PreparedStatement-klassen nederst i frameworket. PreparedStaement-klassen undgår ikke blot SQL-injektion, men sparer også (N-1) kompileringstid, når den samme SQL-sætning udføres N gange, hvilket forbedrer effektiviteten.
Hvis du ændrer ovenstående påstand til:
Når vi indtaster userId="34; bruger af drop-table; Derefter lyder den trykte erklæring:
På nuværende tidspunkt bruger mybatis ikke prækompilerede sætninger, men sammensætter først strenge og udfører derefter kompilering, hvilket præcis er sådan, SQL-injektion virker.
Derfor skal du prøve at bruge formatet "#{xxx}", når du skriver mybatis-mapping-sætninger. Hvis du skal bruge parametre som "${xxx}", skal du manuelt filtrere dem for at forhindre SQL-injektionsangreb.
|
Opslået på 16/08/2018 10.57.34
|
|
|
