Kako hekerji prevzamejo spletna mesta s SQL injekcijo in DDoS
Tudi če ste le ohlapno sledili dogodkom hekerskih skupin Anonymous in LulzSec, ste verjetno slišali, da so spletna mesta in storitve vdrli, kot na primer zloglasni Sony hack. Ste se kdaj spraševali, kako to delajo?
Obstajajo številna orodja in tehnike, ki jih uporabljajo te skupine, in čeprav vam ne želimo dati priročnika, da bi to naredili sami, je koristno razumeti, kaj se dogaja. Dva od napadov, ki jih nenehno slišite z uporabo, sta »(Distributed) Denial of Service« (DDoS) in »SQL Injections« (SQLI). Tako delujejo.
Slika po xkcd
Napaka na zavrnitev storitve
Kaj je to?
"Zavrnitev storitve" (včasih imenovana tudi "porazdeljeno zavračanje storitev" ali DDoS) napad se zgodi, ko sistem, v tem primeru spletni strežnik, prejme toliko zahtev hkrati, da so strežniški viri preobremenjeni, sistem preprosto zaklene in se izklopi. Cilj in rezultat uspešnega DDoS napada je, da spletna mesta na ciljnem strežniku niso na voljo za zakonite prometne zahteve.
Kako deluje?
Logistika DDoS napada je najbolje razložiti z zgledom.
Predstavljajte si, da se milijon ljudi (napadalci) združi s ciljem oviranja poslovanja podjetja X, tako da odvzame klicni center. Napadalci se usklajujejo tako, da bodo v torek ob 9. uri vsi poklicali telefonsko številko podjetja X. Najverjetneje telefonski sistem podjetja X ne bo mogel obvladati milijona klicev naenkrat, zato bodo vse dohodne linije povezane z napadalci. Posledica tega je, da zakoniti odjemalci (tj. Tisti, ki niso napadalci) ne preidejo, ker je telefonski sistem povezan z obravnavanjem klicev napadalcev. Torej je v bistvu podjetje X potencialno izgubilo posel zaradi legitimnih zahtev, ki jih ne morejo doseči.
Napad DDoS na spletni strežnik deluje popolnoma enako. Ker praktično ni mogoče vedeti, kateri promet izvira iz zakonitih zahtev proti napadalcem, dokler spletni strežnik ne obravnava zahteve, je ta vrsta napada navadno zelo učinkovita.
Izvršitev napada
Zaradi "surove" narave DDoS napada morate imeti veliko računalnikov, ki so vsi usklajeni za napad ob istem času. Če bi ponovno pregledali naš primer klicnega centra, bi morali vsi napadalci vedeti, da morajo ob 9 uri poklicati in dejansko klicati v tistem času. Čeprav bo to načelo zagotovo delovalo, ko gre za napad na spletni strežnik, postane bistveno lažje, ko se uporabljajo zombi računalniki, namesto dejanskih računalnikov s posadko..
Kot verjetno veste, obstaja veliko različic zlonamerne programske opreme in trojanskih konjev, ki, ko ste na vašem sistemu, ležijo mirujoče in občasno "telefonirajo domov" za navodila. Eno od teh navodil bi lahko na primer bilo pošiljanje večkratnih zahtevkov spletnemu strežniku podjetja X ob 9.00. Tako z enim samim posodabljanjem domače lokacije zadevne zlonamerne programske opreme lahko en napadalec takoj uskladi več sto tisoč ogroženih računalnikov in izvede ogromen DDoS napad..
Lepota uporabe zombi računalnikov ni le v njeni učinkovitosti, ampak tudi v njeni anonimnosti, saj napadalcu sploh ni treba uporabiti svojega računalnika za izvršitev napada..
SQL Injection Attack
Kaj je to?
Napoved »SQL injection« (SQLI) je izkoriščanje, ki izkorišča slabe tehnike spletnega razvoja in, navadno v kombinaciji z, napačno varnostjo baze podatkov. Rezultat uspešnega napada je lahko od lažnega predstavljanja uporabniškega računa do popolnega kompromisa ustrezne baze podatkov ali strežnika. Za razliko od DDoS napada, je napad SQLI popolnoma in lahko preprečiti, če je spletna aplikacija ustrezno programirana.
Izvršitev napada
Vsakič, ko se prijavite na spletno mesto in vnesete svoje uporabniško ime in geslo, lahko spletna aplikacija za preverjanje poverilnic izvede poizvedbo, kot je naslednja:
IZBIRA UPORABNIKA IZ UPORABNIKA OD KORISNIKOV KJE JE NAVODILA = "myuser" IN Geslo = "mypass";
Opomba: vrednosti niza v poizvedbi SQL morajo biti zaprte v enojne narekovaje, zato se pojavijo okoli uporabniško vnesenih vrednosti.
Zato se mora kombinacija vnesenega uporabniškega imena (myuser) in gesla (mypass) ujemati z vnosom v tabeli Users, da se vrne ID uporabnika. Če ni ujemanja, se ne vrne noben ID uporabnika, zato so poverilnice za prijavo neveljavne. Čeprav se lahko določena izvedba razlikuje, je mehanika precej standardna.
Zdaj pa si poglejmo poizvedbo za preverjanje pristnosti predloge, ki jo lahko nadomestimo z vrednostmi, ki jih uporabnik vnese v spletni obrazec:
SELECT Uporabniški ID FROM Uporabniki WHERE Uporabniško ime = "[uporabnik]" IN Geslo = "[posredovanje]"
Na prvi pogled se lahko zdi, da je to preprost in logičen korak za preprosto preverjanje uporabnikov, če pa se na tej predlogi izvede preprosta zamenjava uporabniško vnesenih vrednosti, je dovzetna za napad SQLI..
Recimo, da je v polje za uporabniško ime vneseno »myuser'-« in v geslo je vneseno »wrongpass«. Z uporabo preproste zamenjave v poizvedbi o predlogi bomo dobili to:
SELECT UserID FROM Uporabniki WHERE Uporabniško ime = "myuser" - "IN Password =" napačen "
Ključ do te izjave je vključitev obeh črt (-). To je začetni žeton komentarjev za stavke SQL, zato bo vse, kar se pojavi ob dveh črtah (vključno), prezrto. V bistvu se zgornja poizvedba izvaja v bazi podatkov kot:
SELECT UserID FROM Uporabniki WHERE Uporabniško ime = "myuser"
Izjemna opustitev je pomanjkanje preverjanja gesla. Z vključitvijo dveh pomišljajev kot dela uporabniškega polja smo popolnoma prezrli pogoj za preverjanje gesla in smo se lahko prijavili kot »myuser«, ne da bi poznali ustrezno geslo. To dejanje manipuliranja poizvedbe za ustvarjanje nenamernih rezultatov je napad z injiciranjem SQL.
Kakšno škodo je mogoče storiti?
Napad SQL injiciranja je posledica malomarnega in neodgovornega kodiranja aplikacij in je popolnoma preprečljiv (kar bomo zajeli v trenutku), vendar je obseg škode, ki se lahko stori, odvisen od nastavitve baze podatkov. Če želi spletna aplikacija komunicirati s podporno bazo podatkov, mora aplikacija predložiti prijavo v bazo podatkov (opomba: to se razlikuje od prijave uporabnika na spletno mesto). Odvisno od dovoljenj, ki jih zahteva spletna aplikacija, lahko ta ustrezni račun baze podatkov zahteva dovoljenje od dovoljenja za branje / pisanje v obstoječih tabelah samo do popolnega dostopa do baze podatkov. Če to zdaj ni jasno, bo nekaj primerov pripomoglo k jasnosti.
Na podlagi zgornjega primera lahko to vidite na primer z vnosom, "youruser" - "," admin "-" ali katero koli drugo uporabniško ime, se lahko takoj prijavimo na spletno mesto kot ta uporabnik, ne da bi vedel geslo. Ko smo v sistemu, ne vemo, da dejansko nismo ta uporabnik, zato imamo popoln dostop do zadevnega računa. Dovoljenja za zbirke podatkov ne bodo zagotovila varnostne mreže za to, ker mora imeti spletno mesto običajno vsaj dostop za branje / pisanje v svoji bazi podatkov..
Predvidevajmo, da ima spletna stran popoln nadzor nad svojo bazo podatkov, ki omogoča brisanje zapisov, dodajanje / odstranjevanje tabel, dodajanje novih varnostnih računov itd. Pomembno je omeniti, da bi lahko nekatere spletne aplikacije to vrsto dovoljenja potrebovale. ni samodejno slabo dejstvo, da je odobren popoln nadzor.
Za ponazoritev škode, ki jo je mogoče storiti v tem primeru, bomo uporabili primer, ki je naveden v komiki zgoraj, tako da v polje uporabniškega imena vnesemo naslednje: "Robert"; Uporabniki DROP TABLE; - ". Po preprosti zamenjavi poizvedba za preverjanje pristnosti postane:
SELECT UserID FROM Uporabniki WHERE Uporabniško ime = "Robert"; Uporabniki DROP TABLE; - 'IN Geslo = "napačen"
Opomba: podpičje je v poizvedbi SQL, ki se uporablja za označevanje konca določenega stavka in začetek novega stavka.
Katera baza podatkov se izvede kot:
SELECT UserID FROM Uporabniki WHERE Uporabniško ime = "Robert"Uporabniki DROP TABLE
Tako smo prav tako uporabili napad SQLI za brisanje celotne tabele Uporabniki.
Seveda, veliko slabše je mogoče storiti, ker lahko, odvisno od dovoljenj SQL, napadalec spremeni vrednosti, tabele izpisa (ali celotno bazo podatkov) v besedilno datoteko, ustvari nove prijavne račune ali celo ugrabi celotno namestitev baze podatkov.
Preprečevanje napada z injiciranjem SQL
Kot smo že večkrat omenili, je lahko injekcijski napad SQL preprosto preprečljiv. Eden od glavnih pravil za razvoj spletnih strani je, da nikoli ne slepo zaupate vnosu uporabnikov, kot smo to storili, ko smo izvedli preprosto zamenjavo v naši predlogi poizvedbe.
Napade SQLI lahko preprosto onemogoči tako imenovano dezinfekcijo (ali pobeg) vaših vnosov. Proces sanacije je pravzaprav dokaj trivialen, saj vse, kar v bistvu počne, je ustrezno rokovanje z vsakokratnimi in-line znaki ('), tako da jih ni mogoče uporabiti za predčasno prekinitev niza znotraj stavka SQL..
Na primer, če ste želeli iskati »O'neil« v bazi podatkov, ne bi mogli uporabiti preproste zamenjave, ker bi enojni citat po O povzročil, da se niz predčasno konča. Namesto tega jo dezinficirajte z uporabo ubežnega znaka ustrezne baze podatkov. Predpostavimo, da je znak za ubeževanje za enojni citat v vrstici pred vsakim citatom s simbolom. Torej bi bil "O'neal" dezinficiran kot "O \ t.
To preprosto dejanje sanacije precej preprečuje napad SQLI. Za ponazoritev ponovno preglejmo prejšnje primere in vidimo izhajajoče poizvedbe, ko je uporabniški vnos dezinficiran.
myuser '-- / narobe:
SELECT UserID FROM Uporabniki WHERE Uporabniško ime = "myuser" - "IN Password =" napačen "
Ker je enojni citat po izklopu myuserja (kar pomeni, da se šteje za del ciljne vrednosti), bo baza podatkov dobesedno poiskala uporabniško ime "myuser" - ". Poleg tega, ker so pomišljaji vključeni v vrednost niza in ne v sam stavek SQL, se bodo obravnavali kot del ciljne vrednosti, namesto da bi jih interpretirali kot komentar SQL.
Robert '; Uporabniki DROP TABLE;-- / narobe:
SELECT UserID FROM Uporabniki WHERE Uporabniško ime = "Robert"; Uporabniki DROP TABLE; - 'IN Geslo = "napačen"
Če preprosto pobegnete od enojne ponudbe po Robertu, sta podpičje in pomišljaji vsebovani v iskalnem nizu UserName, tako da bazi podatkov dobesedno išče "Robert"; Uporabniki DROP TABLE; - " namesto izvršitve brisanja tabele.
V povzetku
Medtem ko se spletni napadi razvijajo in postajajo bolj prefinjeni ali pa se osredotočajo na drugo točko vstopa, je pomembno, da se spomnite, da zaščitite pred poskusi in resničnimi napadi, ki so bili navdih več prosto dostopnih »hekerjev«, ki jih je mogoče uporabiti..
Nekaterih vrst napadov, kot je DDoS, ni mogoče enostavno preprečiti, medtem ko lahko drugi, kot je SQLI, to storijo. Vendar pa lahko škoda, ki jo lahko povzroči ta vrsta napadov, kjerkoli od neugodja do katastrofalnega, odvisno od sprejetih previdnostnih ukrepov..
