SQL süstimine on lihtne rünnakuvektor, mis on tänapäevalgi väga levinud. Põhjus on mitte keegi muu kui see, et rumaluse jaoks pole ühtegi plaastrit. Miks sa seda ütled, võtame näiteks JAVA-d, et seda illustreerida:
Oletame, et andmebaasis eksisteerib selline tabel:
Seejärel kasuta JDBC tegevustabelit:
Ülaltoodud koodi kasutavad sageli mõned arendajad. Kujutage ette olukorda, kus sisenev userId parameeter on "3; drop table kasutaja; SQL-lause täitmine on järgmine:
Pärast andmebaasi kompileerimist ja käivitamist kustutatakse kasutajatabel. Voila, lihtne SQL-i süstimise rünnak hakkab mõjuma! See tuleneb sellest, et ülaltoodud kood ei vasta programmeerimisspetsifikatsioonidele.
Kui programmeerida vastavalt spetsifikatsioonile, siis SQL-i süstimist ei ole. See kehtib kaEsimene viis SQL-i süstimist vältida: eelkompileeritud laused, kood on järgmine:
Miks SQL-i süstimist eeltoodud koodis ei ole? Kuna kasutatakse eelkompileeritud lauset, määrab eelkompileeritud lause "select name from user where id= ?" Lause kompileeritakse ette, nii et täitmisel tuleb see asendada ainult saabuvate parameetritega? Kohatäitjad sobivad. Esimese mittevastavuse korral kirjutab programm SQL-lause ja kompileerib selle kasutaja poolt edastatud sisuga, mis ongi probleem.
Lisaks eelkompileeritud lausetele on olemas ka teine võimalusViisid SQL süstirünnakute vältimiseks: salvestatud protseduurid。 Salvestatud protseduur on SQL-lausete kogum, mis täidab kindlat funktsiooni, kompileeritud ja salvestatud andmebaasi, ning kasutaja saab selle käivitada, kutsudes salvestatud protseduuri ja andes parameetri (kui salvestatud protseduuril on parameetrid), mis aitab vältida ka SQL-süstimise rünnakuid
Vastav salvestatud protseduur ülaltoodud koodis on järgmine:
Loomulikult saavad kasutajad teha ka märgikontrolli frontendis, mis aitab vältida SQL-i süstimist: näiteks ülaltoodud userId parameetri puhul kontrollib kasutaja semikoolonit ja kuvatakse viga.
Kõige põhilisem põhjus on aga see, et SQL süstimise rünnakud eksisteerivad, sest rakendused ei kasuta andmebaasidele juurdepääsul kõige väiksemaid privileege. Tundub, et kõik on kasutanud juurkontot, et andmebaasile ligi pääseda.
Kuidas siis MyBatis suudab vältida SQL-i süstimise rünnakuid? Või võtame näiteks tabelikasutaja:
Oletame, et mapperi fail on:
Vastavad Java failid on:
Näete, et sisendparameeter on userId tüüpi String, kui sisestame userId="34; drop table kasutaja; Pärast seda kõlab trükitud avaldus:
Sõltumata sisestatud kasutajatunnusest on tema SQL avaldus selline. See tuleneb sellest, et mybatis kasutab aluseks olevas rakenduses eelkompileeritud lauseid. Kui andmebaas selle lause täidab, kasutab ta otse eelkompileeritud lauset ja asendab seejärel kohatäitja kasutajaID-ga? Mine lihtsalt jookse. Kas asendada esmalt ajutised täideesemed? Kompileerimisprotsess viiakse läbi, seega pole SQL-i süstimisel ruumi ellu jääda.
Kuidas siis MyBatis SQL-i eelkompileerimist teeb? Tegelikult kasutatakse raamistiku allosas PreparedStatement klassi. PreparedStaement klass mitte ainult ei väldi SQL-i süstimist, vaid säästab ka (N-1) kompileerimisaega, kui sama SQL-lauset täitub N korda, parandades seeläbi efektiivsust.
Kui muudate ülaltoodud väite järgmiselt:
Kui sisestame userId="34; drop table kasutaja; Pärast seda kõlab trükitud avaldus:
Praegu ei kasuta mybatis eelkompileeritud lauseid, vaid ühendab esmalt stringid ja seejärel kompileerib, mis ongi SQL-i süstimise toimimise viis.
Seega, kui kirjutad mybatise kaardistuslauseid, proovi kasutada vormingut "#{xxx}". Kui pead kasutama parameetreid nagu "${xxx}", pead need käsitsi filtreerima, et vältida SQL süstimise rünnakuid.
|
Postitatud 16.08.2018 10:57:34
|
|
|
