Kui on midagi, mida küberkurjategijad armastavad, on need andmed. Varastatud andmed on ebaseaduslikel turgudel väga väärtuslikud ja juurdepääs eraandmebaasidele võib olla pahatahtlikele osalejatele suurepärane võimalus oma ettevõtmistest kasumit teenida. Üks võimalus privaatandmetele juurde pääseda on SQL-i süstimine. Aga mis SQL-i süstimine täpsemalt on, kuidas see toimib ja kas sellist rünnakut saab ära hoida?
Mis on SQL-i süstimine?
Tarkvaraprogrammid toetuvad toimimiseks koodile. Kood on ka keel, mida masinad kasutavad toimingute tegemiseks ja mida võib esineda mitmel kujul (Python, JavaScript, C++ jne). Sageli saavad küberkurjategijad ohvreid rünnata koodi kaudu ja SQL-i süstid (või SQL-id) ei erine sellest. Need võimaldavad pahatahtlikel osalejatel SQL-lausesse kahjulikku koodi "süstida".
Vaatame kõigepealt üle, mida SQL tähendab.
SQL tähistab struktureeritud päringu keelt.
See on teist tüüpi programmeerimiskeel kasutatakse spetsiaalselt andmebaasidega tegelemisel. IBMi poolt 1970. aastatel välja töötatud SQL saab andmebaasi teavet manipuleerida, talletada ja hankida. Paljud andmebaaside sidesüsteemid üle maailma kasutavad SQL-i, seega pole üllatav, et ohus osalejad on välja töötanud viise, kuidas seda andmebaaside sihtimiseks kuritarvitada.SQL-laused moodustavad andmebaasikommunikatsiooni võtmeosa. SQL-lause on käsk mida on mitmel erineval kujul. Mõned muudavad andmeid, mõned toovad või kustutavad need ja mõned võivad muuta andmebaasi enda struktuuri. Kui SQL-i süstimine toimub, süstitakse pahatahtlik kood SQL-lausesse.
Muidugi peab veebisait või rakendus kasutama SQL-i programmeerimiskeelt, et SQL-i süstimine oleks võimalik. Aga kuidas see ründevektor töötab?
Oletame, et teil on tavaline koodirida, mida rakendus kasutab. Kui küberkurjategija sisestab pahatahtliku SQL-i süsti, lisatakse koodirida, mis võib segada päringuid, mida rakendus ise oma andmebaasi saadab. Seda tehes saab andmebaasi ära kasutada viisil, mis võimaldab ohus osalejal vaadata andmeid, millele tal muidu juurdepääsu ei oleks.
Siit saab küberkurjategija andmeid varastada, et neid otse ära kasutada või müüa seda pimedas veebis või mujal. Samuti võivad nad sihtandmebaasi andmeid muuta, lisada või kustutada. Sõltuvalt SQL-i süstimise rünnaku astmest võib palju kahju tekitada. Kui pääsete juurde makseandmetele, sotsiaalkindlustusnumbritele või muudele eraandmetele, võib paljusid inimesi ära kasutada.
Teisest küljest, kui ründajal õnnestub andmebaasi oluliselt muuta, võib suur hulk andmeid jäädavalt kaduma. Kokkuvõttes võivad SQL-i süstid hävitada terveid andmebaase vaid ühe rünnakuga. Kuigi need on olnud kasutusel alates 1998. aastast, on need meie praegusel ajal endiselt asjakohased ja ohtlikud.
Nagu leidis Avatud veebirakenduse turbeprojekt (OWASP)2021. aastal tuvastati rakenduste testimisel sellise rünnaku olemasolu suhtes 274 000 SQL-i süsti.
SQL-i süstimise tüübid
SQL-i süstimist on mitut erinevat tüüpi, kusjuures kolm peamist on pimesüstid, ribasisesed ja ribavälised süstid.
Pime (või järeldatav) SQL-i süstimine toimub siis, kui rakendust või saiti rünnatakse süstimine, kuid esitatud HTTP (Hypertext Transfer Protocol) vastused ei sisalda SQL päring. Teisisõnu ei anta küberkurjategijale andmeid rünnatud andmebaasist. Mis selle mõte siis on?
Pimeda SQL-i süstimise abil saadab ründaja andmed sihtserverisse ja saab seejärel HTTP-vastuse enda olemuse kaudu tuvastada andmebaasi teatud asju. Lisaks võivad HTTP-vastusega seotud tegurid aidata ründajal luua andmebaasile juurdepääsuks veel ühe tõhusama SQL-i süsti.
Pimedat SQL-i süstimist on kaks peamist tüüpi, mida tuntakse ajapõhise ja tõeväärtusena. Need kaks varianti on oma olemuselt üsna sarnased. Nii tõeväärtuslik kui ka ajapõhine SQL-i süstimine saadab massiivi jah- või ei-vastustega küsimusi, kuigi viimane nõuab, et andmebaas ootaks enne päringutele vastamist veidi aega.
Järgmisena on ribasisesed SQL-i süstid. Bändisisesed SQL-i süstid võimaldavad operaatoril rünnak läbi viia ja sama kanali kaudu soovitud tulemus saada. Kõige sagedamini kasutatakse ribasiseseid SQL-i süsti, kuna neid on kõige lihtsam teostada, kuna neil on vaja ainult ühte kanalit.
Lõpuks on teil ribaväline SQL-i süst. See on sisuliselt ribasisese SQL-i süstimise alternatiivne versioon, kus ründaja ei saa rünnakut läbi viia kokku ühe kanali kaudu. Teise võimalusena võib rünnak kasutada ribavälist SQL-i süsti, kui sihtserver lihtsalt ei ole tulemuste saavutamiseks piisavalt kiire.
Need tegurid muudavad protsessi pisut keerulisemaks, mis tähendab, et see peab sihitud andmebaasis edu saavutamiseks tuginema teatud funktsioonidele. Näiteks peab rünnataval platvormil olema puudulik sisendi desinfitseerimine. Seetõttu on ribasisesed SQL-i süstid palju tavalisemad kui ribavälised SQL-i süstid. Aga neid ikka juhtub.
Kas SQL-i süstimist saab vältida?
SQL-i süstid valmistavad rohkem muret ettevõtetele ja organisatsioonidele kui tavalistele üksikisikutele. Kuid on asju, mida need potentsiaalsed sihtmärgid saavad teha, et vähendada tõenäosust, et selline rünnak neid tabab.
Sisendite puhastamine on SQL-i süstide vältimise peamine tava. See on filtreerimisprotsess, mis skannib ja puhastab sisend ohtlikest tähemärkidest. Kui SQL-koodi töödeldakse enne desinfitseerimist, suureneb SQL-i süstimise võimalus loomulikult.
Lisaks võivad parameetritega päringud aidata teil SQL-i süstidest eemale hoida. Need on päringud, mille täitmiseks on vaja vähemalt ühte parameetrit. Parameetrite rakendamine muudab küberkurjategijate jaoks SQL-i süstimise rünnaku eduka läbiviimise raskemaks.
Kuid SQL-i süstimise vältimiseks pole kindlat viisi. Nagu paljude küberrünnakute puhul, on peaaegu võimatu hoida oma seadmeid ja süsteeme täiesti õhukindlana. SQL-i süstide puhul on parim, mida saate teha, desinfitseerida kõik sisendid ja luua parameetritega päringuid.
SQL-i süstid on vananenud, kuid siiski ohuks
Kuigi SQL-i süstid on olnud kasutusel üle 20 aasta, kujutavad need endiselt ohtu paljudele veebisaitidele ja rakendustele. Seetõttu on hea mõte seda ründevormi silmas pidada ja astuda vajalikke samme selle vältimiseks, kuna see võib tulevikus mingil hetkel teie andmebaase ohustada.
