26Aug
Isegi kui olete loogiliselt jälginud häkkerite rühmi Anonymous ja LulzSec, olete ilmselt kuulnud veebikaubadest ja teenustest, mis on häkkinud, nagu kurikuulus Sony hacks. Kas olete kunagi mõelnud, kuidas nad seda teevad?
On mitmeid tööriistu ja võtteid, mida need rühmad kasutavad, ja kui me ei püüa 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
Service Denial Service Attack
Mis see on?
Teenuse kasutamise keelamine( mõnikord nimetatakse "hajutatud teenusetõkendite" või DDoS-i) rünnakule tekib, kui süsteem, antud juhul veebiserver, saab korraga nii palju päringuid, et serveriressursid on ülekoormatud, lihtsalt lukustubüles ja välja lülitada. Eduka DDoS-ründe eesmärk ja tulemus on siht-serveri veebisaidid õigustatud liiklustaotluste jaoks kättesaamatud.
Kuidas see toimib?
DDoS-rünnaku logistikat saab kõige paremini selgitada näitena.
Kujutage ette, et miljon inimest( ründajad) ühineks eesmärgiga takistada ettevõtte X 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
DDoS-rünnaku "ründaja" olemuse tõttu peate korraga rünnakute tegemiseks olema 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 kutsutakse sel ajal. Kuigi see põhimõte kindlasti töötab veebiserveri rünnaku korral, muutub see oluliselt lihtsamaks, kui kasutataks tegelikult mehitatud arvutite asemel zombie arvuteid.
Nagu te arvatavasti teate, on palju pahavara ja troojalaste variante, mis teie süsteemis korduvad juhendamisel 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 tegelikult rünnaku teostamiseks tegelikult oma arvutit kasutama.
SQL Injection Attack
Mis see on?
SQL-i süstimise( SQLI) rünnak on ärakasutamine, mis kasutab halva veebiarenduse tehnikaid ja tavaliselt koos rikke andmebaaside 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ünde teostamine
Kui sisenete veebisaidile ja sisestate oma kasutajanimi ja parool, siis saab oma mandaadi testimiseks käivitada selline päring nagu
SELECT UserID kasutajatelt, kus kasutajaNimi = 'myuser' JA parool= 'mypass';
Märkus: SQL-päringus olevad stringiväärtused peavad olema lisatud ühe hinnapakkumisi, mistõttu need kuvatakse kasutaja sisestatud väärtuste ümber.
Nii et sisestatud kasutajanime( myuser) ja parooli( mypass) kombinatsioon peab kasutaja ID-s tagastamiseks vastama kasutajate tabeli kirjega. Kui vastavust ei leitud, ei anta kasutajaID tagasi, seega on sisselogimismandaadid kehtetud. Kuigi konkreetne rakendamine võib erineda, on mehaanika üsna standardne.
Nüüd vaatame malli autentimise päringut, mille abil saame asendada väärtused, mille kasutaja siseneb veebivormil:
SELECT UserID kasutajatelt, kus kasutajaNimi = '[kasutaja]' JA parool '' [pass] '
Esmapilgul seevõib tunduda lihtsa ja loogilise sammuna kasutajate hõlpsaks valideerimiseks, kuid kui selle malli abil kasutaja lihtsalt sisestatud väärtused asendatakse, on see SQLI-rünnaku suhtes vastuvõtlik.
Näiteks oletame, et kasutajanime väljale sisestatakse kasutajanimi "myuser" ja "password" on sisestatud vale pass. Lihtsa asenduse kasutamine meie mallide päringus me saame seda:
SELECT UserID kasutajatelt, kus kasutajaNimi = 'myuser' - 'AND Password =' errorpass '
Selle avalduse 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. Põhimõtteliselt täidab andmebaas andmebaasi järgmiselt:
SELECT UserID kasutajatelt, kus kasutajaNimi = 'myuser'
Siin on silmapaistvaks väljajätmiseks parooli kontrollimise puudumine. Kui lülitasite kaks kriipsu kasutajavälja osana, võttis me täielikult parooli kontrollimise tingimuse ja sai sisse logida "myuseriks", ilma et oleks vastavat parooli teada saanud. See juhtub, et soovimatu tulemuse saamiseks päringuga manipuleeritakse, on SQL-i süstimise rünnak.
Millist kahju saab teha?
SQL süstimise rünnaku põhjuseks on hooletu ja vastutustundetu rakenduste kodeerimine ja see on täiesti vältimatu( mida me mõne hetkega kaob), kuid kahju ulatus, mis on võimalik 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 võib näha, et näiteks sisestades näiteks "youruser" - "," admin "-" või mõni muu kasutaja nimi, võime koheselt saidile sisse logida kui seda kasutajat parooli teadmata. Kui oleme süsteemis, ei tea, kas me pole tegelikult see kasutaja, nii et meil oleks 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 oletame, et veebisaidil on täielik kontroll oma vastava andmebaasi üle, mis annab võimaluse kustutada dokumente, lisada tabeleid / eemaldada tabeleid, lisada uusi julgeolekukontosid jne. Oluline on märkida, et mõned veebirakendused vajavad seda tüüpi lubasee ei ole automaatselt halb, et täielik kontroll antakse.
Selleks, et illustreerida kahju, mida selles olukorras saab teha, kasutame eespool toodud koomiks toodud näidet, sisestades kasutajanimede väljale järgmised andmed: "Robert"; DROP TABLE Users - ".Pärast lihtsat asendamist avaneb autentimise päring:
SELECT UserID kasutajatelt, kus kasutajaNimi = 'Robert';DROP TABEL Kasutajad; - 'AND Password =' errorpass '
Märkus: semikoolon on SQL-päringus, mis tähistab konkreetse avalduse lõppu ja uue avalduse algust.
Mis andmebaasi täidab:
SELECT UserID kasutajatelt, kus kasutajatunnus = 'Robert'
DROP TABLE Kasutajad
Nii et me kasutasime SQLI rünnakut kogu kasutaja tabeli kustutamiseks.
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 varem mainitud, on SQL-i süstimise rünnak hõlpsasti ära hoitav.Üks veebiarenduse peamistest reeglitest on see, et te ei usalda kasutajate sisendit pimesi, nagu me tegime, kui me esitasime ülalkirjeldatud malli päringu käigus lihtsa asenduse.
SQLI rünnakut on lihtne ära hoida, mida nimetatakse teie sisendite hõõrdumiseks( 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 asendust, 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 '- / valeandur :
SELECT UserID kasutajatelt, kus kasutajaNimi =' myuser '-' AND Password = 'errorpass'
Kuna üksikasutaja pärast minu kasutaja on põgenenud( see tähendab, et seda peetakse sihtmärgi osaksväärtus), otsib andmebaas sõna otseses mõttes "myuser" - "kasutaja nime".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 TABEL Kasutajad - / valesti :
SELECT UserID kasutajatelt, kus kasutajaNimi = 'Robert';DROP TABEL Kasutajad; - 'AND Password =' errorpass '
Lihtsalt põgenedes pärast Robert'i üksikpakkumist, on nii semikoolonid ja kriipsud UserName'i otsingusardas, nii et andmebaas otsiks sõna "Robert"; DROP TABLE Users;- "tabeli täitmise asemel kustutatakse.
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 haaratud tööriistu, mille eesmärk on neid kasutada.
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.
