Čak i ako ste samo labavo slijedili događaje hakerskih skupina Anonymous i LulzSec, vjerojatno ste čuli o web stranicama i uslugama koje su hakirani, poput zloglasnih Sony hackova. Jeste li se ikad zapitali kako to rade?
Postoje brojni alati i tehnike koje te skupine koriste, a dok ne pokušavamo dati vam priručnik da to učinite samima, korisno je razumjeti što se događa. Dva napada koji dosljedno čujete o njima pomoću su "(Distributed) Denial of Service" (DDoS) i "SQL Injections" (SQLI). Evo kako oni rade.
Slika od xkcd
Što je?
"Uskraćivanje usluga" (ponekad se naziva "distribuirano uskraćivanje usluge" ili DDoS) događa se kada sustav, u ovom slučaju web poslužitelj, prima toliko mnogo zahtjeva istovremeno da su resursi poslužitelja preopterećeni sustav jednostavno zaključava i zatvori. Cilj i rezultat uspješnog napada na DDoS su web stranice na ciljnom poslužitelju nedostupne za legitimne zahtjeve za prometom.
Kako radi?
Logistika DDoS napada najbolje se može objasniti primjerom.
Zamislite milijun ljudi (napadači) da se zajedno s ciljem ometanja poslovanja tvrtke X uzevši u obzir svoj pozivni centar. Napadači koordiniraju tako da u utorak, u 9 sati, svi će nazvati telefonski broj tvrtke X. Najvjerojatnije, telefonski sustav tvrtke X neće moći riješiti milijune poziva odjednom, tako da će sve dolazne linije biti vezane od strane napadača. Rezultat toga je da legitimni korisnički pozivi (tj. Oni koji nisu napadači) ne prolaze jer je telefonski sustav vezan za rukovanje pozivima napadača. Dakle, u biti tvrtka X potencijalno gubi posao zbog legitimnih zahtjeva koji se ne mogu probiti.
DDoS napad na web poslužitelj funkcionira na isti način. Budući da praktički nema načina da saznate koji promet potječe iz legitimnih zahtjeva protiv napadača sve dok web poslužitelj ne obrađuje zahtjev, takva vrsta napada obično je vrlo učinkovita.
Izvršavanje napada
Zbog "bujne sile" prirode DDoS napada, morate imati puno računala koja su koordinirana za napad u isto vrijeme. Preusmjeravajući naš primjer pozivnog centra, to bi zahtijevalo da svi napadači oboje znaju nazvati u 9 ujutro i zapravo zvati u to vrijeme. Iako će ovo načelo zasigurno funkcionirati kada je u pitanju napadanje web poslužitelja, ona postaje znatno jednostavnija kada se upotrebljavaju zombi računala, umjesto stvarnih računalnih računala.
Kao što vjerojatno znate, postoje mnoge inačice zlonamjernog softvera i trojanaca koji, jednom u vašem sustavu, leže uspavani i povremeno "telefoniraju kući" za upute. Jedna od ovih uputa mogla bi, primjerice, biti poslati ponovljene zahtjeve na web poslužitelj tvrtke X u 9 sati ujutro. Dakle, s jednim ažuriranjem na početnu lokaciju odgovarajućeg zlonamjernog softvera, jedan napadač može trenutačno koordinirati stotine tisuća ugroženih računala za obavljanje ogromnog DDoS napada.
Ljepota iskorištavanja zombi računala nije samo u svojoj učinkovitosti, već iu anonimnosti jer napadač zapravo ne mora uopće koristiti računalo za izvršenje napada.
Što je?
Napad "SQL injection" (SQLI) napada je iskorištavanje koje iskorištava prednosti loših tehnika razvoja web stranica i, u pravilu, u kombinaciji s neispravnom sigurnosti baze podataka. Rezultat uspješnog napada može varirati od oponašanja korisničkih računa do kompletnog kompromisa odgovarajuće baze podataka ili poslužitelja. Za razliku od DDoS napada, SQLI napad je potpuno i lako spriječiti ako je web aplikacija prikladno programirana.
Izvršavanje napada
Kad god se prijavite na web stranicu i unesite svoje korisničko ime i lozinku, kako bi testirali vaše vjerodajnice web aplikacija može pokrenuti upit poput sljedećeg:
ODABERITE ID korisnika od korisnika WHERE UserName = "myuser" I lozinka = "moj pass";
Napomena: vrijednosti niza u SQL upitu moraju biti zatvorene u pojedinačnim navodnicima, zbog čega se pojavljuju oko korisnika unesenih vrijednosti.
Stoga kombinacija unesenog korisničkog imena (myuser) i zaporke (mikroprocesora) mora odgovarati unosu u tablici korisnika kako bi se ID korisnika vratio. Ako se ne podudara, ne vraća se UserID, tako da vjerodajnice za prijavu nisu važeće. Dok se određena implementacija može razlikovati, mehanika je prilično standardna.
Zato pogledaj upit za autentifikaciju predloška koji možemo zamijeniti vrijednosti koje korisnik ulazi na web obrazac:
ODABERITE ID korisnika od korisnika WHERE UserName = "[korisnik]" AND Password = "[pass]"
Na prvi pogled to može izgledati kao jednostavan i logičan korak za lako validiranje korisnika, no ako se na ovom predlošku provede jednostavna zamjena korisničkih unesenih vrijednosti, on je osjetljiv na SQLI napad.
Na primjer, pretpostavimo da je u polju korisničkog imena unesena "myuser", a zaporka je unesena "wrongpass". Koristeći jednostavnu zamjenu u našem upitu predloška, dobit ćemo ovo:
ODABERITE ID korisnika od korisnika WHERE UserName = "myuser" - "I lozinka =" wrongpass "
Ključ ove izjave je uključivanje dviju crtica (--), Ovo je početni komentar token za SQL izjave, tako da će se sve što se pojavljuje nakon dvije crtice (uključivo) zanemariti. U osnovi, gore navedeni upit izvršava baza podataka kao:
ODABERITE ID korisnika od korisnika WHERE UserName = "myuser"
Izvanredan propust ovdje je nedostatak provjere zaporke.Uključivanjem dvije crtice kao dijela korisničkog polja potpuno smo zaobišli stanje provjere zaporke i uspjeli smo se prijaviti kao "myuser" bez poznavanja odgovarajuće lozinke. Ovaj čin manipulacije upitom za izradu neželjenih rezultata je napad SQL injekcije.
Kakva šteta može biti učinjena?
Napad na SQL ubrizgavanje uzrokovan je nepažljivim i neodgovornim kodiranjem aplikacija i potpuno je moguće spriječiti (što ćemo u trenu pokriti), no opseg štete koja se može učiniti ovisi o postavljanju baze podataka. Da bi web aplikacija mogla komunicirati s bazom podataka baze podataka, aplikacija mora dostaviti prijavu u bazu podataka (napominjemo, to se razlikuje od prijave korisnika na web stranicu). Ovisno o dozvolama koje web aplikacija zahtijeva, ovaj odgovarajući račun baze podataka može zahtijevati sve od dopuštenja za čitanje / pisanje u postojećim tablicama samo do potpunog pristupa bazi podataka. Ako ovo sada nije jasno, nekoliko primjera bi trebalo pomoći u pružanju neke jasnoće.
Na temelju gornjeg primjera možete vidjeti da unosom, na primjer, "youruser" - "," admin "-" ili bilo koje drugo korisničko ime, odmah se prijaviti na stranicu kao taj korisnik bez poznavanja lozinke. Jednom kada smo u sustavu ne znamo da nismo zapravo taj korisnik pa imamo puni pristup odgovarajućem računu. Dozvole za baze podataka neće osigurati sigurnosnu mrežu, jer obično web stranica mora imati barem čitanje / pisanje pristupa svojoj bazi podataka.
Pretpostavimo da web stranica ima potpunu kontrolu nad vlastitom bazom podataka koja omogućuje brisanje zapisa, dodavanje / uklanjanje tablica, dodavanje novih računa sigurnosti itd. Važno je napomenuti da neke web aplikacije trebaju ovu vrstu dozvole kako bi nije automatski loša stvar koja se daje potpuna kontrola.
Da bismo ilustrirali štetu koja se može učiniti u ovoj situaciji, upotrijebit ćemo primjer naveden u gornjoj komi tako da unesete sljedeće u polje korisničkog imena: "Robert"; DROP TABLE Korisnici; - ". Nakon jednostavne zamjene upit za provjeru autentičnosti postaje:
ODABERITE korisničko ime od korisnika WHERE UserName = "Robert"; DROP TABLE Korisnici; - "I lozinka =" pogrešni pas "
Napomena: točka-zarez u SQL upitu koristi se za označavanje kraja određene izjave i početak nove izjave.
Koja se baza podataka izvršava kao:
ODABERITE ID korisnika od korisnika WHERE UserName = "Robert"DROP TABLE Korisnici
Stoga smo koristili SQLI napad kako bismo izbrisali cijelu tablicu korisnika.
Naravno, mnogo je gore moguće jer, ovisno o dozvoljenim SQL dozvolama, napadač može promijeniti vrijednosti, tablice za odbacivanje (ili cijelu bazu podataka) u tekstnu datoteku, stvoriti nove račune za prijavu ili čak oteti cjelokupnu instalaciju baze podataka.
Sprječavanje napada SQL injekcije
Kao što smo spomenuli nekoliko puta prije, napad SQL injekcije lako se može spriječiti. Jedno od kardinalnih pravila razvoja web-mjesta nikada niste nikada slijepo povjerenje korisničkog unosa kao što smo to učinili kada smo izvršili jednostavnu zamjenu u gornjem upitu predloška.
SQLI napad lako je ometan onim što se zove sanitizing (ili bježi) svoje inpute. Postupak sanitizacije je zapravo prilično trivijalan, budući da sve ono što u osnovi ne uspijeva riješiti bilo koji pojedinačni pojedinačni navodni citat (') tako da se ne mogu koristiti za preuranjeno prekidanje niza unutar SQL izraza.
Na primjer, ako ste željeli potražiti "O'neil" u bazi podataka, ne biste mogli upotrebljavati jednostavnu zamjenu jer će pojedinačni citat nakon O uzrokovati preuranjeno prestanak niza. Umjesto toga, očistite ga pomoću znaka za bijegu odgovarajuće baze podataka. Pretpostavimo da je tip bijega za inline pojedinačni citat prefacing svaki citat s \ simbol. Dakle, "O'neal" će se sanificirati kao "O \ 'neil".
Taj jednostavan čin sanitarne zaštite uglavnom sprečava SQLI napad. Da bismo ilustrirali, pregledajmo prethodne primjere i vidimo koji su dobiveni upiti kada se korisnički unos dezinficira.
myuser '- / wrongpass:
ODABERITE ID korisnika od korisnika WHERE UserName = "myuser" - "AND Password =" wrongpass "
Budući da se pojedinačni citat nakon što se izbjegne (što znači da se smatra dijelom ciljne vrijednosti), baza podataka doslovno traži korisničko ime "Myuser '-". Osim toga, budući da su crtice uključene unutar vrijednosti niza, a ne sama SQL izjava, oni će se smatrati dijelom ciljne vrijednosti umjesto da se tumače kao SQL komentar.
Robert'; DROP TABLE Korisnici; / wrongpass:
SELECT UserID od korisnika WHERE UserName = "Robert \"; DROP TABLE Korisnici; - "I lozinka =" pogrešni pas "
Jednostavnim izbjegavanjem pojedinačnog citata nakon Roberta, i točke i crtice sadržane su unutar UserName trake za pretraživanje tako da baza podataka doslovno traži "Robert"; DROP TABLE Korisnici; - " umjesto da izvršite brisanje tablice.
Dok se napadi na webu razvijaju i postaju sofisticiraniji ili se fokusiraju na drugu točku ulaza, važno je zapamtiti da se zaštitite od pokušaja i istinitih napada koji su bili inspiracija nekolicine slobodno dostupnih "hakerskih alata" osmišljenih za njihovo iskorištavanje.
Neke vrste napada, kao što je DDoS, ne mogu se lako izbjeći, dok drugi, kao što je SQLI, mogu. Međutim, šteta koja se može učiniti ovim vrstama napada može se odvijati bilo gdje od neugodnosti do katastrofalne, ovisno o predviđenim mjerama.
