Rahvusvahelise standardandmebaasi päringu lausena on SQL-lauseid laialdaselt kasutatud erinevates programmeerimiskeskkondades. Kuna tegemist on küpse ja stabiilse süsteemiga, on kasutaja sisselogimine ja paroolikontroll hädavajalikud. Igapäevases programmeerimistöös avastasin, et paljud programmeerijad kasutavad SQL-lauseid kasutajaparoolide kontrollimiseks sellise lause kaudu:
sql="Vali * kasutajatabelist, kus nimi='"+nimi+"' ja password='"+password+"'"
Nimi ja parool on kasutaja sisestatud kasutajanimed ja paroolid ning ülaltoodud väited täidetakse, et kontrollida, kas kasutaja ja parool on legitiimsed ja kehtivad. Kuid analüüsi käigus võib leida, et ülaltoodud väidetes on saatuslikke lünki. Kui sisestame kasutajanimele järgmise stringi: 111'or'1=1 ja sisestame parooli juhuslikult, määrame selle aaaa-ks. Pärast muutuja asendamist muutub SQL-lause järgmiseks stringiks:
sql="Vali * kasutajatabelist, kus nimi='111'or'1=1' ja parool='aaaa'
Me kõik teame, et kui select-lause hindab päringu tingimusi, ignoreerib ta järgmisi ja (ja) operatsioone, kui kohtutakse või (või) operatsioonidega, ning väärtus 1=1 ülaltoodud lauses on alati tõene, mis tähendab, et ükskõik milline väärtus parooli sisestatakse, suudab see läbida ülaltoodud parooli kontrolli! Selle probleemi lahendus on väga lihtne ning meetodeid on palju, kõige sagedamini kasutatakse kasutaja ja sisestatud parooli legitiimsuse hindamine enne kontrolli teostamist ning erimärgid nagu üksikjutumärgid ja võrdsed märgid ei ole lubatud.
Ülaltoodud probleemid, kuigi need võivad tunduda lihtsad, eksisteerivad. Näiteks oli internetis tuntud veebimängu "Smiling Proud Jianghu" varajane versioon sellise probleemiga, ning autor analüüsis hoolikalt ka mõningaid programme, mida ta oli varem kirjutanud pärast selle mängu haavatavuse raporti lugemist, ja selliseid lünki oli palju. See peaks tõesti olema meie tähelepanu. See toob esile ka noorte programmeerijate, sealhulgas autori, programmikogemuse ja turvateadlikkuse puudumise. Samal ajal tuletab see meelde, et programmeerijad peaksid programmi disainimisel täielikult arvestama programmi turvalisusega ega tohi olla hooletu ning näiliselt väike puudujääk võib põhjustada tõsiseid tagajärgi.
|