Sellised rühmad kasutavad mitmesuguseid tööriistu ja võtteid ning kui me ei ürita ise seda teha, on kasulik mõista, mis toimub. Kaks neist rünnakutest, mida teid pidevalt kuulete, on "Distributed Service Denial" (DDoS) ja "SQL Injections" (SQLI). Siin on, kuidas nad töötavad.
Pilt poolt xkcd
Denial of Service Attack
Mis see on?
Teenuse andmisest keeldumine (mõnikord "jagatud teenusetõkend" või DDoS) rünnak tekib siis, kui süsteem, antud juhul veebiserver, saab korraga nii palju päringuid, et serveriressursid on ülekoormatud, lihtsalt lukustub ja lülitab välja. Eduka DDoS-ründe eesmärk ja tulemus on siht-serveri veebisaidid õigustatud liiklustaotluste jaoks kättesaamatud.
Kuidas see töötab?
DDoS-rünnaku logistikat saab kõige paremini seletada näitega.
Kujutage ette, et miljon inimest (ründajad) ühineks eesmärgiga takistada X ettevõtte tegevust, võttes oma kõnekeskuse alla. Ründajad koordineerivad nii, et teisipäeval kell 9 on kõik kutsuvad ettevõtte X telefoninumbrit. Tõenäoliselt ei saa ettevõtte X telefonisüsteem korraga toimetada miljoneid kõnesid, nii et kõik sissetulevad liinid seotaksid ründajad. Tulemuseks on see, et seaduslikud kliendikõned (st need, mis ei ole ründajad) ei jõua, kuna telefonisüsteem on seotud ründajatele tehtud kõnede haldamisega. Põhimõtteliselt võib X ettevõtte potentsiaalselt kaotada äri, kuna seaduslikud taotlused ei saa läbi viia.
Veebiserveri DDoS rünnak toimib täpselt samamoodi. Kuna praktiliselt ei ole võimalik teada, mis liiklust pärineb õigustatud päringutest või ründajatest, kuni veebiserver taotluse töötleb, on selline rünnak tüüpiliselt väga tõhus.
Rünnaku läbiviimine
Kuna DDoS-i rünnaku "jõuline" olemus on tingitud, on teil vaja rünnata korraga ühtlasi palju arvuteid. Meie kõnekeskuse näite ümber vaatamine nõuab, et kõik ründajad mõlemad teaksid, et helistatakse kell 9.00 ja tegelikult helistatakse sel ajal. Kuigi see põhimõte kindlasti töötab veebiserveri rünnaku korral, muutub see oluliselt lihtsamaks, kui kasutataks zombie arvutid, mitte tegelikult mehitatud arvutid.
Nagu te arvatavasti teate, on pahavara ja troojalaste hulk erinevaid variante, mis teie süsteemis korduvad juhistele ja jäävad vaikseks ja aeg-ajalt telefoni koduks. Üks nendest juhenditest võib olla näiteks ettevõtte X veebiserverisse korduvate päringute saatmine kell 9.00. Nii, et vastava pahavara koduväljale antakse uus versioon, saab üks ründaja koheselt koordineerida sadu tuhandeid ohustatud arvuteid massiivse DDoS-rünnaku tegemiseks.
Zombie arvutite ilu ei seisne mitte ainult selle tõhususes, vaid ka selle anonüümsuses, kuna ründaja ei pea ründaja reaalselt oma arvutit kasutama.
SQL Injection Attack
Mis see on?
SQL-i süstimise (SQLI) rünnak on ekspluateerimine, mis kasutab ära halva veebiarenduse tehnikat ja tavaliselt koos rikutud andmebaasi turvalisusega. Eduka ründe tulemus võib ulatuda kasutajakonto kujutamisest kuni vastava andmebaasi või serveri täieliku kompromissini. Erinevalt DDoS-rünnakust on SQLI-rünnak täiesti ja hõlpsasti ennetatav, kui veebirakendus on programmeeritud õigesti.
Rünnaku läbiviimine
Kui sisenete veebisaidile ja sisestate oma kasutajanimi ja parool, võib mandaatide testimiseks veebirakendus käivitada päringu, mis on järgmine:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Märkus: SQL-päringus olevad stringiväärtused peavad olema lisatud ühele hinnapakkumisele, mistõttu need kuvatakse kasutaja sisestatud väärtuste ümber.
Nii et sisestatud kasutajanime (myuser) ja parooli (mypass) kombinatsioon peab kasutaja ID-s tagastamiseks vastama kasutaja tabelis olevale kirjele. Kui vastavust ei leitud, ei tagastata ühtki UserID-i, seega on sisselogimismandaadid kehtetud. Kuigi konkreetne rakendamine võib erineda, on mehaanika üsna standardne.
Nüüd vaatame mallide autentimise päringut, mille abil saame asendada väärtused, mille kasutaja siseneb veebivormil:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
Esmapilgul võib see tunduda lihtsa ja loogilise sammuna kasutajate hõlpsaks valideerimiseks, kuid kui antud malli kasutaja lihtsalt sisestatud väärtused asendatakse, on see tundlik SQLI-rünnaku suhtes.
Näiteks oletame, et kasutajatunnus on sisestatud "myuser" - "ja parool on sisestatud" valesti ". Lihtsa asenduse kasutamine meie malli päringus me saame seda:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Selle avaldise võtmeks on kahe kriipsu lisamine
(--)
. See on SQL-avalduste alustamiseks kommentaarimärguur, nii et kõik, mis kuvatakse pärast kahe kriipsu (kaasa arvatud), ignoreeritakse. Sisuliselt täidab ülaltoodud päring andmebaasi järgmiselt:
SELECT UserID FROM Users WHERE UserName='myuser'
Siin on silmatorkav väljajätmine parooli kontrollimise puudumine.Kui lülitasite kaks kriipsu kasutajavälja osana, võttis me täielikult parooli kontrollimise tingimuse ja sai sisse logida kui "myuser", ilma et oleks vastavat parooli teada saanud. See juhtub, et soovimatu tulemuse saamiseks päringuga manipuleeritakse, on SQL-i süstimise rünnak.
Mis kahju saab teha?
SQL-i süstimise rünnaku põhjuseks on hooletu ja vastutustundetu rakenduste kodeerimine ja see on täiesti vältimatu (mida me mõne aja jooksul ka kaetakse), kuid kahju ulatus, mis saab teha, sõltub andmebaasi seadistamisest. Veebirakenduse taustaandmebaasiga suhtlemiseks peab rakendus andma andmebaasis sisselogimise (märkus, see erineb veebisaidi kasutajapoolsest sisselogimisest). Sõltuvalt sellest, millised luba veebirakendus vajab, võib see vastav andmebaasi konto nõuda lugemis- / kirjutamisõigusest midagi olemasolevatest tabelitest ainult täieliku andmebaasi juurde. Kui see pole nüüd selge, peaksid mõned näited aitama anda mõningast selgust.
Eespool toodud näite põhjal näete, et sisestades näiteks
'youruser'--', 'admin'--'
või mõni muu kasutaja nimi, võime koheselt sisselogimisel saidile seda kasutajat parooli teadmata. Kui oleme süsteemis, ei tea, kas me pole tegelikult see kasutaja, nii et meil on täielik juurdepääs vastavale kontole. Andmebaasiõigused ei anna sellele turvavõrgu, sest tavaliselt peab veebisaidil olema vähemalt vastava andmebaasi jaoks lugemis- / kirjutamisõigus.
Nüüd eeldame, et veebisaidil on täielik kontroll selle vastava andmebaasi üle, mis annab võimaluse kustutada dokumente, lisada tabeleid / eemaldada tabeleid, lisada uusi julgeolekukontosid jne. On oluline märkida, et mõned veebirakendused vajavad seda tüüpi õigusi, nii et ei ole automaatselt halb, et täielik kontroll antakse.
Selleks, et illustreerida kahju, mida selles olukorras saab teha, kasutab me eespool toodud koomiks toodud näidet, sisestades kasutajanimede väljale järgmised andmed:
'Robert'; DROP TABLE Users;--'.
Pärast lihtsat asendamist autentimisprotokoll muutub:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Märkus: semikoolon on SQL-päringus, mis tähistab konkreetse avalduse lõppu ja uue avalduse algust.
Mis andmebaasi täidab andmebaas järgmiselt:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABEL Kasutajad
Nii et just nii oleme kasutanud SQLI rünnakut, et kustutada kogu kasutajate tabel.
Loomulikult saab palju hullem teha, kuna sõltuvalt lubatud SQL lubadest võib ründaja muuta väärtusi, dump tabeleid (või kogu andmebaasi ise) tekstifaili, luua uusi sisselogimiskontosid või isegi kopeerida kogu andmebaasi installi.
SQL süstimise rünnaku ennetamine
Nagu mitu korda varem mainitud, on SQL-i süstimise rünnak hõlpsasti ära hoitav. Üks veebiarenduse peamistest reeglitest on see, et te ei ole kunagi pimedalt usaldanud kasutaja sisendit, nagu me tegime, kui me tegime lihtsa asenduse ülaltoodud malli päringus.
SQLI-rünnakut takistab kergesti seda, mida nimetatakse teie sisendite puhastamiseks (või põgenemiseks). Desinfitseerimisprotsess on tegelikult üsna triviaalne, sest kõik see sisuliselt teeb käepäraseid üksikuid üksikülekandega (') tähemärke, mis on sellised, et neid ei saa kasutada SQL-i lausungi enneaegseks lõpetamiseks.
Näiteks kui soovite andmebaasi "O'neil" otsida, ei saa te kasutada lihtsat asendamist, sest pärast O-ga tehtud üksikotsing põhjustab stringi ennetähtaegselt. Selle asemel puhastate seda, kasutades vastava andmebaasi escape-tähemärki. Oletame, et põgusad tähemärgid sisestatud ühe tsitaadi jaoks on iga tsitaadi eesliinil koos sümboliga. Nii et "O'neal" oleks puhastatud kui "O " neil ".
See lihtne sanitaarkaitse toiming takistab SQLI rünnakut päris palju. Selle illustreerimiseks vaadake meie varasemaid näiteid ja vaadake saadud päringuid, kui kasutaja sisend on puhastatud.
myuser'--
/ valepass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Kuna minu kasutajapoolne üksikpakkumine on põgenenud (see tähendab, et seda peetakse sihtväärtuse osaks), otsib andmebaas sõna otseses mõttes kasutaja nime
'myuser'--'.
Lisaks, kuna kriipsud kuuluvad stringi väärtuseni, mitte aga SQL-i avalduseni, peetakse neid sihtväärtuse osaks, selle asemel et seda tõlgendada SQL-i kommentaarina.
Robert'; DROP TABLE Users;--
/ valepass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Lihtsalt põgenedes pärast Robert'i ühekordset tsitaati, asuvad mõlemad semikoolonid ja kriipsud kasutaja nime otsingu stringis, nii et andmebaas otsiks sõna otseses mõttes
'Robert'; DROP TABLE Users;--'
tabeli täitmise asemel kustutada.
Kokkuvõttes
Kuigi veebirakendused arenevad ja muutuvad keerukamaks või keskenduvad erinevale sisenemiskohale, on oluline meeles pidada, et kaitsta püüdlustega ja tõeliste rünnakute eest, mis on inspireerinud mitmeid vabalt kättesaadavaid "häkkerite tööriistu", mis on mõeldud nende kasutamiseks.
Teatud tüüpi rünnakuid, näiteks DDoS-i, ei saa kergesti vältida, samas kui teised, näiteks SQLI, suudavad. Siiski võib selline rünnakutega põhjustatav kahju ulatuda ebamugavast kuni katastroofini, sõltuvalt võetud ettevaatusabinõudest.
