Näissä ryhmissä on useita työkaluja ja tekniikoita, ja vaikka emme yritä antaa sinulle käsikirjaa itse tekemään, on hyödyllistä ymmärtää, mitä tapahtuu. Kaksi hyökkäystä, joita olet johdonmukaisesti kuullut käytöstä, ovat "(Distributed) Denial of Service" (DDoS) ja "SQL Injections" (SQLI). Näin he työskentelevät.
Kuvaaja: xkcd
Palvelunestohyökkäys
Mikä se on?
Palvelun epääminen (joskus kutsutaan "hajautetun palvelunestohyökkäyksen" tai DDoS-hyökkäyksen aikana, kun järjestelmä, tässä tapauksessa verkkopalvelin, vastaanottaa niin monta pyyntöä kerrallaan, että palvelinresurssit ovat ylikuormittuneet, järjestelmä yksinkertaisesti lukkiutuu ja sammuu. Menestyksekkään DDoS-hyökkäyksen tavoite ja tulos ovat kohdepalvelimessa olevat sivut eivät ole oikeutettuja liikennepyyntöjä varten.
Kuinka se toimii?
DDoS-hyökkäyksen logistiikka voidaan parhaiten selittää esimerkin avulla.
Kuvittele, että miljoona ihmistä (hyökkääjät) päätyvät tavoitteeseen estää X: n liiketoiminta ottamalla puhelukeskuksensa alas. Hyökkääjät koordinoivat siten, että tiistaina kello 9.00 he kaikki soittavat X: n puhelinnumeroon. Todennäköisesti Company X: n puhelinjärjestelmä ei pysty käsittelemään miljoonia puheluita kerralla, jotta hyökkääjät sitoisivat kaikki tulevat rivit. Tuloksena on, että lailliset asiakaspuhelut (eli ne, jotka eivät ole hyökkääjiä) eivät pääse läpi, koska puhelinjärjestelmä on sidottu käsittelemään puhelut hyökkääjiltä. Joten yhtiö X voi mahdollisesti menettää liiketoimintaansa, koska oikeutetut pyynnöt eivät pääse läpi.
DDoS-hyökkäys web-palvelimelle toimii täsmälleen samalla tavalla. Koska käytännöllisesti katsoen ei ole mitään keinoa tietää, mikä liikenne on peräisin oikeutetuista pyynnöistä ja hyökkääjistä, kunnes verkkopalvelin käsittelee pyyntöä, tällainen hyökkäys on tyypillisesti erittäin tehokas.
Hyökkäyksen suorittaminen
DDoS-hyökkäyksen "brute force" -luonteen vuoksi sinulla on oltava paljon tietokoneita, jotka kaikki koordinoivat hyökkäykseen samanaikaisesti. Esimerkiksi puhelinkeskuksen esimerkin tarkistaminen vaatii, että kaikki hyökkääjät tietävät, että he soittavat klo 9.00 ja soittavat sinä aikana. Vaikka tämä periaate varmasti toimii WWW-palvelimen hyökkäämisen suhteen, siitä tulee huomattavasti helpompaa, kun zombietokoneita käytetään varsinaisten miehitettyjen tietokoneiden sijasta.
Kuten luultavasti tiedät, haittaohjelmien ja troijalaisten versioita on paljon, jotka kerran järjestelmässäsi ovat lepotilassa ja joskus "puhelimessa" ohjeita varten. Yksi näistä ohjeista voisi esimerkiksi olla lähettää toistuvia pyyntöjä yrityksen X verkkopalvelimelle kello 9.00. Joten yhdellä päivityksellä kyseisen haittaohjelmiston kotisivulle yksittäinen hyökkääjä voi välittömästi koordinoida satoja tuhansia vaarantuneita tietokoneita massiivisen DDoS-hyökkäyksen suorittamiseen.
Zombien tietokoneiden hyödyntämisen kauneus ei ole pelkästään sen tehokkuus vaan myös sen nimettömyys, sillä hyökkääjä ei todellakaan tarvitse käyttää tietokonettaan suorittamaan hyökkäystä.
SQL Injection Attack
Mikä se on?
SQLin injektio (SQLI) -hyökkäys on hyödyntävä, joka hyödyntää huonoja web-kehitystekniikoita ja tyypillisesti yhdistettynä virheelliseen tietokantaturvaan. Menestyksekkään hyökkäyksen tulos voi vaihdella käyttäjän käyttäjätilien esittämisestä vastaavan tietokannan tai palvelimen täydelliseen kompromissiin. Toisin kuin DDoS-hyökkäys, SQLI-hyökkäys on täysin ja helposti estettävissä, jos verkkosovellus on ohjelmoitu asianmukaisesti.
Hyökkäyksen suorittaminen
Aina kun kirjaudut verkkosivustoon ja kirjoitat käyttäjätunnuksesi ja salasanasi, jotta voit testata salasanasi, web-sovellus voi suorittaa seuraavanlaisen kyselyn:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Huomaa: SQL-kyselyn merkkijonojen arvot on sisällytettävä yksittäisiin lainausmerkkeihin, minkä vuoksi ne näkyvät käyttäjän antamien arvojen ympärillä.
Joten syötetyn käyttäjänimen (myuser) ja salasanan (mypassin) yhdistelmän on vastattava merkintää Käyttäjät-taulukossa, jotta käyttäjätunnus palautettaisiin. Jos vastausta ei ole, käyttäjätunnusta ei palauteta, joten kirjautumistunnukset eivät ole kelvollisia. Vaikka tietty toteutus voi poiketa, mekaniikka on melko vakio.
Katsotaan nyt mallin todennustekyselyä, jonka voimme korvata arvot, jotka käyttäjä kirjoittaa verkkomuotoon:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
Ensi silmäyksellä tämä voi tuntua yksinkertaiselta ja loogiselta askeleelta käyttäjien validoimiseksi helposti, mutta jos tällä mallilla tehdään käyttäjän syöttämäsi arvot yksinkertaisella korvauksella, se on altis SQLI-hyökkäykselle.
Oletetaan esimerkiksi, että "myuser'-" syötetään käyttäjänimi -kenttään ja salasanaan syötetään "wrongpass". Käyttämällä yksinkertaista korvaamista mallikyselyssä saisimme tämän:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Tämän toteamuksen avain on kahden viivan sisällyttäminen
(--)
. Tämä on SQL-lausekkeiden aloituskomentosymboli, joten mitä tahansa kahta viivettä (sisältävä) jälkeen näkyvä sisältö jätetään huomiotta. Pohjimmiltaan yllä oleva kysely suoritetaan tietokannalla seuraavasti:
SELECT UserID FROM Users WHERE UserName='myuser'
Selvä laiminlyönti tässä on salasanan tarkistuksen puuttuminen.Sisällyttämällä kaksi viivaa osana käyttäjän kenttää ohitimme täydellisesti salasanan tarkistusolosuhteet ja pääsimme kirjautumaan "myuseriksi" tietämättä salasanaa. Tämä kyselyn manipulointi tahattomien tulosten tuottamiseksi on SQL-injektio-hyökkäys.
Mitä vahinkoja voi tehdä?
SQL-injektio-hyökkäys johtuu huolimattomasta ja vastuutonta sovelluskoodista ja se on kokonaan estettävissä (joka kattaa hetken), mutta vahinkojen laajuus riippuu tietokannan määrityksestä. Jotta web-sovellus voi kommunikoida backend-tietokannan kanssa, sovelluksen on toimitettava kirjautumistiedot tietokantaan (huomaa, tämä eroaa käyttäjän sisäänkirjautumisesta itse verkkosivustolle). Riippuen siitä, mitä käyttöoikeuksia web-sovellus vaatii, kyseinen tietokantatili voi vaatia olemassaolevissa taulukoissa vain lukea / kirjata lupaa täydelliseen tietokantaan. Jos tämä ei ole nyt selvää, muutamia esimerkkejä pitäisi auttaa selkeyttämään.
Edellä olevan esimerkin perusteella voit nähdä, että kirjoittamalla esim.
'youruser'--', 'admin'--'
tai mikä tahansa muu käyttäjätunnus, voimme heti kirjautua sivustoon, koska käyttäjä tuntee salasanan. Kun olemme järjestelmässä, emme tiedä, emme ole tosiasiassa kyseistä käyttäjää, joten meillä on täysi pääsy kyseiseen tiliin. Tietokannan käyttöoikeudet eivät tarjoa turvaverkkoa, koska yleensä verkkosivustolla on oltava ainakin luku- / kirjoitusoikeus sen tietokantaan.
Oletetaan nyt, että verkkosivustolla on täysi hallinta sen tietokannasta, joka antaa mahdollisuuden poistaa tietueita, lisätä / poistaa pöytiä, lisätä uusia tietoturvatilejä jne. On tärkeää huomata, että jotkin verkkosovellukset tarvitsevat tällaisen luvan, joten ei ole automaattisesti huono asia, että täysi valvonta myönnetään.
Jotta havainnollistettaisiin tässä tilanteessa mahdollisesti esiintyvää vahinkoa, käytämme yllä olevaa sarjakuva-esimerkkiä kirjoittamalla seuraavat käyttäjätunnuksen kenttään:
'Robert'; DROP TABLE Users;--'.
Yksinkertaisen korvaamisen jälkeen todennuskysely muuttuu:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Huomaa: puolipisteessä SQL-kyselyssä käytetään tietyn lausunnon loppua ja uuden lausunnon alkua.
Joka saa tietokannan suorittamalla:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABLE Käyttäjät
Joten näin olemme käyttäneet SQLI-hyökkäys poistaa koko Käyttäjät-taulukon.
Tietenkin paljon huonompi voidaan tehdä, sillä sallitut SQL-oikeudet riippuvat hyökkäyksestä, joka voi muuttaa arvot, tyhjennystulokset (tai koko tietokannan itse) tekstitiedostoon, luoda uusia kirjautumistilejä tai jopa kaapata koko tietokannan asennuksen.
SQL-injektio-iskun estäminen
Kuten mainitsimme useita kertoja aikaisemmin, SQL-injektio-hyökkäys on helposti estettävissä. Yksi web-kehityksen tärkeimmistä säännöistä ei ole, että et koskaan sokeasti luota käyttäjän sisääntuloon, kuten teimme, kun teimme yksinkertaisen korvauksen yllä olevassa mallikyselyssä.
SQLI-hyökkäys on helposti estyneenä siitä, mitä sanotaan puhdistamalla (tai poistumasta) panoksesi. Sanitisointiprosessi on itse asiassa melko vähäpätöinen, koska kaikki olennaisesti se hoitaa minkä tahansa inline-yhden lainauksen (') merkit sopivasti siten, että niitä ei voida käyttää ennenaikaisesti lopettamaan SQL-käskyn sisällä oleva merkkijono.
Jos esimerkiksi haluat etsiä tietokannan "O'neil" tietokannasta, et voi käyttää yksinkertaista korvausta, koska yksittäinen lainaus O: n jälkeen aiheuttaa merkkijonoa ennenaikaisesti loppuun. Sen sijaan puhdistat sen käyttämällä vastaavaa tietokantaa. Oletetaan, että inline-kertaushakemuksen poistolohko edustaa jokaista lainausta symbolilla. Joten "O'neal" saniteettiin "O n neil".
Tämä yksinkertainen puhdistustoimenpide melkein estää SQLI-hyökkäyksen. Jotta havainnollistettaisiin, tarkastelemme edellisiä esimerkkejä ja näemme tuloksena olevat kyselyt, kun käyttäjän syöttö on puhdistettu.
myuser'--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Koska yksittäinen lainaus myuserin jälkeen poistuu (eli sitä pidetään osana tavoitearvoa), tietokanta kirjaimellisesti etsii käyttäjänimen
'myuser'--'.
Lisäksi, koska viivat sisältyvät merkkijonon arvoon eikä itse SQL-käskyyn, niitä pidetään osana tavoitearvoa sen sijaan, että niitä tulkittaisiin SQL-kommenteiksi.
Robert'; DROP TABLE Users;--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Yksinkertaisesti pelastamalla yhden tarjouksen Robertin jälkeen molemmat puolipisteet ja viivat ovat UserName-hakusanan sisällä, joten tietokanta kirjaimellisesti etsii
'Robert'; DROP TABLE Users;--'
sen sijaan, että suoritettaisiin taulukon poistaminen.
Yhteenvetona
Vaikka verkkohyökkäykset kehittyvät ja kehittyvät entistä kehittyneemmiksi tai kohdistuvat toiseen tulopaikkaan, on tärkeää muistaa suojata hyökkäyksiä vastaan, jotka ovat olleet innoitusta useista vapaasti käytettävissä olevista "hakkureitistä", jotka on suunniteltu hyödyntämään niitä.
Tiettyjä hyökkäystyyppejä, kuten DDoS, ei voida helposti välttää, kun taas muut, kuten SQLI, voivat. Kuitenkin vahinko, jota tällaiset hyökkäykset voivat tehdä, voivat ulottua missä tahansa haitasta katastrofaaliseen riippuen toteutetuista varotoimista.
