Úvodná » ako » Ako Hackeri preberajú webové stránky pomocou SQL Injection a DDoS

    Ako Hackeri preberajú webové stránky pomocou SQL Injection a DDoS

    Dokonca aj keď ste len voľne sledovali udalosti hackerových skupín Anonymous a LulzSec, pravdepodobne ste počuli o webových stránkach a službách, ktoré sú napadnuté, ako o neslávnom Sony hacks. Premýšľali ste niekedy, ako to robia??

    Existuje niekoľko nástrojov a techník, ktoré tieto skupiny používajú, a kým sa nepokúšame vám dať manuál, aby ste to urobili sami, je užitočné pochopiť, čo sa deje. Dva z útokov, ktoré ste neustále počuli o nich, sú "(Distributed) Denial of Service" (DDoS) a "SQL Injections" (SQLI). Tu je, ako fungujú.

    Obrázok podľa XKCD

    Odmietnutie útoku služby

    Čo je to?

    "Zamietnutie služby" (niekedy nazývané "distribuované odmietnutie služby" alebo DDoS) sa vyskytuje, ak systém, v tomto prípade webový server, prijíma toľko požiadaviek naraz, že zdroje servera sú preťažené, systém sa jednoducho zamkne a vypne sa. Cieľ a výsledok úspešného útoku DDoS je, že webové stránky na cieľovom serveri nie sú k dispozícii na legitímne požiadavky na návštevnosť.

    Ako to funguje?

    Logistika útoku DDoS možno najlepšie vysvetliť príkladom.

    Predstavte si, že sa milión ľudí (útočníci) stretne s cieľom obmedziť podnikanie spoločnosti X tým, že zničí svoje call centrum. Útočníci súhlasia, aby v utorok o 9:00 všetci zavolali telefónne číslo spoločnosti X. S najväčšou pravdepodobnosťou telefónny systém spoločnosti X nebude schopný zvládnuť milión hovorov naraz, takže všetky prichádzajúce linky budú viazané útočníkmi. Výsledkom je, že legitímne zákaznícke hovory (t. J. Tie, ktoré nie sú útočníkmi) sa nedostanú, pretože telefónny systém je viazaný na manipuláciu s hovormi od útočníkov. Takže v podstate spoločnosť X potenciálne stráca svoju činnosť v dôsledku legitímnych požiadaviek, ktoré nie sú schopné dostať sa.

    DToS útok na webovom serveri funguje presne rovnakým spôsobom. Pretože prakticky neexistuje žiadny spôsob, ako vedieť, čo sa získava z legitímnych žiadostí a útočníkov, až kým webový server spracováva žiadosť, tento typ útoku je zvyčajne veľmi účinný.

    Vykonanie útoku

    Vzhľadom na povahu útoku DDoS "brutálnej sily" musíte mať k dispozícii množstvo počítačov, ktoré sú koordinované, aby mohli naraziť naraz. Pri opätovnom prečítaní nášho príkladu telefónneho centra by to vyžadovalo, aby všetci útočníci obaja vedeli, že majú zavolať o 9:00 hod. A skutočne volajú v tom čase. Zatiaľ čo tento princíp určite bude fungovať, pokiaľ ide o útok na webový server, stáva sa podstatne ľahšie, keď sa zombie počítačov, namiesto skutočných počítačov s posádkou,.

    Ako pravdepodobne viete, existuje veľa variantov škodlivého softvéru a trójskych koní, ktoré raz v systéme ležia spiace a príležitostne "telefón doma" pre pokyny. Jedným z týchto pokynov by mohlo byť napríklad odoslanie opakovaných žiadostí na webový server spoločnosti X v 9:00. Takže s jedinou aktualizáciou na domáce umiestnenie príslušného malware môže jeden útočník okamžite koordinovať stovky tisíc kompromitovaných počítačov, aby mohol vykonať masívny útok DDoS.

    Krása využitia počítača zombie nie je len v jeho účinnosti, ale aj v jeho anonymity, pretože útočník v skutočnosti nemusí používať svoj počítač na vykonanie útoku.

    SQL Injection Attack

    Čo je to?

    Iniciatíva "SQL injection" (SQL injection) je zneužitie, ktoré využíva slabé techniky vývoja webu a zvyčajne v kombinácii s chybnou databázovou bezpečnosťou. Výsledok úspešného útoku môže byť od zosobnenia používateľského konta až po úplný kompromis príslušnej databázy alebo servera. Na rozdiel od útoku DDoS je útok SQLI úplne a ľahko zabrániteľný, ak je webová aplikácia správne naprogramovaná.

    Vykonanie útoku

    Kedykoľvek sa prihlásite na webovú stránku a zadáte svoje používateľské meno a heslo, aby ste mohli vyskúšať vaše poverenia, webová aplikácia môže spustiť dotaz, ako je nasledujúci:

    SELECT UserID z používateľov WHERE UserName = "myuser" A heslo = "mypass";

    Poznámka: Hodnoty reťazca v dotaze SQL musia byť uzavreté v samostatných úvodzovkách, čo je dôvod, prečo sa zobrazujú okolo hodnôt zadaných používateľom.

    Kombinácia zadaného používateľského mena (myuser) a hesla (mypass) sa musí zhodovať s položkou v tabuľke Používatelia, aby sa vrátila užívateľská identifikácia. Ak nie je žiadna zhoda, žiadny UserID je vrátený, takže prihlasovacie údaje sú neplatné. Zatiaľ čo sa určitá implementácia môže líšiť, mechanika je dosť štandardná.

    Takže teraz sa pozrime na dotaz o autentifikácii šablóny, ktorý môžeme nahradiť hodnotami, ktoré používateľ zadá na webovom formulári:

    SELECT UserID z používateľov WHERE UserName = "[user]" A heslo = "[pass]"

    Na prvý pohľad sa to môže zdať ako jednoduchý a logický krok pre jednoduché overenie používateľov, avšak ak sa na túto šablónu vykoná jednoduchá náhrada užívateľom zadaných hodnôt, je náchylná na útok SQLI.

    Predpokladajme napríklad, že v poli užívateľského mena je zadané slovo "myuser" - a heslo "wrongpass" je zadané. Použitím jednoduchej náhrady v našom dotaze šablóny by sme získali toto:

    SELECT UserID z používateľov WHERE UserName = "myuser" - "AND Password =" wrongpass "

    Kľúčom k tomuto vyhláseniu je zaradenie dvoch pomlčiek (-). Toto je začiatočný token komentára pre príkazy SQL, takže všetko zobrazené po dvoch pomlčkách (vrátane) bude ignorované. V podstate je uvedený dotaz vykonaný databázou ako:

    SELECT UserID z používateľov WHERE UserName = "myuser"

    Zjavné vynechanie je nedostatok kontroly hesla. Zahrnutím dvoch pomlčiek ako súčasť užívateľského poľa sme úplne vynechali podmienku kontroly hesla a dokázali sa prihlásiť ako "myuser" bez toho, aby sme poznali príslušné heslo. Tento akt manipulácie s dotazom na dosiahnutie neúmyselných výsledkov je útok SQL injection.

    Aké škody môžete urobiť?

    Injektový útok SQL je spôsobený nedbanlivým a nezodpovedným kódovaním aplikácie a je úplne zabránené (čo budeme pokrývať za chvíľu), avšak rozsah poškodenia, ktorý sa dá urobiť, závisí od nastavenia databázy. Aby mohla webová aplikácia komunikovať s databázou backend, aplikácia musí poskytnúť prihlásenie do databázy (poznamenajte si, že je to iné ako prihlásenie používateľa na samotnú webovú stránku). V závislosti od toho, aké povolenia webová aplikácia vyžaduje, môže príslušný databázový účet vyžadovať čokoľvek od oprávnenia na čítanie / zápis v existujúcich tabuľkách až po úplný prístup k databáze. Ak to teraz nie je jasné, niekoľko príkladov by malo pomôcť poskytnúť určitú jasnosť.

    Na základe vyššie uvedeného príkladu to môžete vidieť napríklad zadaním, "youruser" - "," admin "-" alebo akékoľvek iné používateľské meno, môžeme okamžite prihlásiť sa na stránku ako tento používateľ bez toho, aby ste vedeli heslo. Akonáhle sme v systéme nevie, že nie sme vlastne ten užívateľ, takže máme plný prístup k príslušnému účtu. Povolenia databázy neposkytujú záchrannú sieť, pretože webová stránka musí mať aspoň prístup k čítaniu alebo zápisu do príslušnej databázy.

    Predpokladajme, že webová stránka má plnú kontrolu nad príslušnou databázou, ktorá umožňuje odstrániť záznamy, pridať / odstrániť tabuľky, pridať nové bezpečnostné účty atď. Je dôležité poznamenať, že niektoré webové aplikácie by mohli potrebovať tento typ povolenia, nie je automaticky zlá vec, ktorú poskytuje plná kontrola.

    Na ilustráciu škôd, ktoré je možné v tejto situácii urobiť, použijeme príklad uvedenú v komiksu uvedenom vyššie zadaním nasledujúceho poľa pre meno používateľa: "Robert", používatelia DROP TABLE, - ". Po jednoduchom nahradení sa autentifikačný dotaz stáva:

    SELECT UserID z používateľov WHERE UserName = "Robert"; DROP TABLE užívateľov - "AND Password =" wrongpass "

    Poznámka: bodkočiarka v dotaze SQL sa používa na označenie konca konkrétneho výpisu a začiatku nového výpisu.

    Ktorý sa spúšťa databázou ako:

    SELECT UserID z používateľov WHERE UserName = "Robert"

    DROP TABLE Users

    Takže tak sme použili útok SQLI na odstránenie celej tabuľky Používatelia.

    Samozrejme, oveľa horšie je možné urobiť, pretože v závislosti od povolených oprávnení SQL môže útočník zmeniť hodnoty, výpis tabuľky (alebo celú databázu samotnú) do textového súboru, vytvoriť nové prihlasovacie účty alebo dokonca uniesť celú inštaláciu databázy.

    Zabránenie útoku SQL injection

    Ako sme už niekoľkokrát spomenuli, útok SQL injection je ľahko zabrániteľný. Jednou z hlavných pravidiel vývoja webu nie je nikdy slepá dôvera užívateľa ako sme urobili, keď sme vykonali jednoduchú náhradu v našom dotazu šablóny vyššie.

    Útok SQLI je ľahko zablokovaný tým, čo sa nazýva sanitizing (alebo unikanie) vaše vstupy. Proces dezinfekcie je v skutočnosti dosť triviálny, pretože všetko, čo v podstate robí, je spracovávať akékoľvek inline jednoduché citácie (') znakov vhodne tak, aby nemohli byť použité na predčasné ukončenie reťazca vo vnútri príkazu SQL.

    Napríklad, ak ste chceli vyhľadávať "O'neil" v databáze, nemohli ste použiť jednoduchú náhradu, pretože jediný citát po O by spôsobil, že reťazec sa predčasne skončí. Namiesto toho sa dezinfikujete pomocou príslušného únikového znaku databázy. Predpokladajme, že znak úniku pre inline jednoduchú citáciu predbežne uvádza každú citáciu pomocou symbolu \. Takže "O'neal" by sa dezinfikoval ako "O" neil ".

    Tento jednoduchý úkon sanitácie celkom zabraňuje útoku SQLI. Ak chcete ilustrovať, vráťme sa k predchádzajúcim príkladom a výsledné dopyty sa zobrazia po sanitácii vstupu používateľa.

    myuser '-- / wrongpass:

    SELECT UserID z používateľov WHERE UserName = "myuser" - "AND Password =" wrongpass "

    Keďže unikátna citácia po myuseri unikne (čo znamená, že sa považuje za súčasť cieľovej hodnoty), databáza doslova vyhľadá UserName "Myuser '-". Navyše, pretože pomlčky sú zahrnuté do hodnoty reťazca a nie samotného príkazu SQL, budú považované za súčasť cieľovej hodnoty namiesto toho, aby sa interpretovala ako komentár SQL.

    Robert "; DROP TABLE Používatelia;-- / wrongpass:

    SELECT UserID FROM používateľov WHERE UserName = "Robert \"; DROP TABLE užívateľov - "AND Password =" wrongpass "

    Jednoduchým uniknutím jediného citátu po Roberte sa nachádza aj bodkočiarka a čiarky v reťazci vyhľadávania UserName, takže databáza doslova vyhľadá "Robert", používatelia DROP TABLE, - " namiesto vykonania vymazania tabuľky.

    V súhrne

    Zatiaľ čo webové útoky sa vyvíjajú a stávajú sa sofistikovanejšími alebo sa sústreďujú na iný vstupný bod, je dôležité mať na pamäti ochranu proti pokusom a pravdivým útokom, ktoré boli inšpiráciou niekoľkých voľne dostupných "hackerových nástrojov" určených na ich využitie.

    Niektoré typy útokov, ako napríklad DDoS, sa nedajú ľahko vyhnúť, zatiaľ čo iné, napríklad SQLI, môžu. Škody, ktoré môžu byť spôsobené týmito druhmi útokov, sa však môžu pohybovať od nepríjemností po katastrofálne v závislosti od preventívnych opatrení.