SQL injection je jednoduchý vektor útoku, ktorý je dodnes veľmi bežný. Dôvodom nie je nič iné ako žiadna záplata pre hlúposť. Prečo to hovoríte, vezmime si ako príklad JAVA, aby sme to ilustrovali:
Predpokladajme, že takáto tabuľka existuje v databáze:
Potom použite tabuľku akcií JDBC:
Vyššie uvedený kód často používajú niektorí vývojári. Predstavte si situáciu, kde prichádzajúci parameter userId je "3; používateľ tabuľky drop; SQL príkaz vykonaný je nasledovný:
Po skompilovaní a spustení databázy sa používateľská tabuľka vymaže. Voilà, jednoduchý SQL injection útok začína účinkovať! Je to preto, že vyššie uvedený kód nespĺňa programátorské špecifikácie.
Keď programujeme podľa špecifikácie, SQL injection prakticky neexistuje. To platí ajPrvý spôsob, ako sa vyhnúť SQL injection: predkompilované príkazy, kód je nasledovný:
Prečo SQL injection neexistuje v uvedenom kóde? Keďže sa používa predkompilovaný príkaz, predkompilovaný príkaz nastaví "select name from user where id= ?" Príkaz sa skompiluje vopred, takže ho stačí nahradiť len prichádzajúcimi parametrami pri vykonaní? Zástupné postavy sú v poriadku. V prvom prípade nezhody program napíše SQL príkaz a potom ho skompiluje s obsahom zadaným používateľom, čo je presne problém.
Okrem použitia predkompilovaných príkazov existuje aj druhá možnosťSpôsoby, ako sa vyhnúť útokom SQL injection: Uložené procedúry。 Uložená procedúra je množina SQL príkazov, ktoré vykonávajú konkrétnu funkciu, skompilované a uložené v databáze, a používateľ ju môže vykonať zavolaním uloženej procedúry a zadaním parametra (ak má uložená procedúra parametre), čo môže tiež zabrániť SQL injekčným útokom
Zodpovedajúca uložená procedúra v uvedenom kóde je nasledovná:
Samozrejme, používatelia môžu tiež vykonávať kontrolu znakov na frontende, čo je tiež spôsob, ako sa vyhnúť SQL injekcii: napríklad pri parametri userId vyššie používateľ skontroluje bodkočiarku a zobrazí sa chyba.
Avšak najzákladnejším dôvodom je, že existujú SQL injekčné útoky preto, že aplikácie nepoužívajú najmenšie oprávnenia pri prístupe k databázam. Zdá sa, že všetci používali root účet na prístup k databáze.
Ako teda MyBatis zabraňuje útokom SQL injekcií? Alebo vezmime ako príklad používateľa tabuľky vyššie:
Povedzme, že mapper súbor je:
Zodpovedajúce java súbory sú:
Vidíte, že vstupný parameter je userId typu String, keď zadávame userId="34; používateľ tabuľky drop; Potom tlačené vyhlásenie znie:
Bez ohľadu na zadané userID je jeho SQL príkaz takýto. Je to spôsobené tým, že mybatis používa predkompilované príkazy v základnej implementácii. Keď databáza vykoná toto vyhlásenie, priamo použije predkompilovaný príkaz a potom nahradí zástupcu za prechádzajúce userId? Len bež. Najskôr vymeniť zástupné miesta? Proces kompilácie sa vykonáva, takže neexistuje priestor na prežitie SQL injekcie.
Ako teda MyBatis robí predkompiláciu SQL? V skutočnosti sa trieda PreparedStatement používa na spodku rámca. Trieda PreparedStaement nielenže zabraňuje SQL injekcii, ale tiež šetrí (N-1) času kompilácie, keď sa ten istý SQL príkaz vykoná N-krát, čím sa zvyšuje efektivita.
Ak zmeníte vyššie uvedené tvrdenie na:
Keď zadáme userId="34; používateľ tabuľky drop; Potom tlačené vyhlásenie znie:
V súčasnosti mybatis nepoužíva predkompilované príkazy, najprv spojí reťazce a potom vykoná kompiláciu, čo je presne spôsob, akým sa SQL injection prejavuje.
Preto pri písaní príkazov na mapovanie mybatis sa snažte použiť formát "#{xxx}". Ak musíte použiť parametre ako "${xxx}", musíte ich manuálne filtrovať, aby ste zabránili SQL injekčným útokom.
|
Zverejnené 16. 8. 2018 10:57:34
|
|
|
