Existuje celý rad 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ú "Distribuované odmietnutie služby" (DDoS) a "SQL Injections" (SQLI). Tu je návod, 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, keď 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 sa koordinujú, 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ú zviazané ú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ý manipuláciou 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é prekonať.
Útok DDoS na webový server funguje presne rovnakým spôsobom. Pretože prakticky neexistuje žiadny spôsob, ako zistiť, čo sa získava z legitímnych žiadostí a útočníkov, kým webový server spracováva žiadosť, tento typ útoku je zvyčajne veľmi účinný.
Vykonanie útoku
Kvôli prírode útoku DDoS "brutálnej sily" musíte mať k dispozícii množstvo počítačov, ktoré sú koordinované na útok naraz. Pri opätovnom prečítaní nášho príkladu telefónneho centra by to vyžadovalo, aby všetci útočníci obaja poznali, že majú zavolať o 9.00 hod. A skutočne volajú v tom čase. Zatiaľ čo táto zásada 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, využívajú.
Ako pravdepodobne viete, existuje veľa variantov malwaru a trójskych koní, ktoré kedysi na vašom 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 jednou 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žívanie, ktoré využíva slabé techniky vývoja webových aplikácií 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ť svoje poverenia, webová aplikácia môže spustiť dotaz, ako je nasledujúci:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='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 neexistuje žiadna zhoda, nebudú vrátené žiadne ID používateľa, takže prihlasovacie údaje nie sú platné. Kým konkrétna implementácia sa môže líšiť, mechanika je dosť štandardná.
Takže teraz sa pozrime na dotaz na autentifikáciu šablóny, ktorý môžeme nahradiť hodnotami, ktoré používateľ zadá na webovom formulári:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[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é do hesla. Použitím jednoduchej náhrady v dotaze šablóny by sme získali toto:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Kľúčom k tomuto vyhláseniu je zaradenie dvoch pomlčiek
(--)
Toto je začiatočný komentár pre príkazy SQL, takže niečo, čo sa objaví po dvoch pomlčkách (vrátane), bude ignorované. V podstate je vyššie uvedený dotaz vykonaný databázou ako:
SELECT UserID FROM Users WHERE UserName='myuser'
Zjavné vynechanie tu 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 útokom SQL injection.
Aké škody možno 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), rozsah škôd, ktoré je možné vykonať, 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, ktoré 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 môžete vidieť, že zadaním, napríklad,
'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 vlastne nie sme ten používateľ, takže máme plný prístup k príslušnému účtu. Databázové povolenia neposkytujú záchrannú sieť, pretože webová stránka musí mať aspoň prístup k čítaniu alebo zápisu do svojej databázy.
Predpokladajme, že webová stránka má plnú kontrolu nad príslušnou databázou, ktorá dáva možnosť vymazať 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ú vyššie v komiksu zadaním nasledujúceho poľa pre meno používateľa:
'Robert'; DROP TABLE Users;--'.
Po jednoduchom nahradení sa autentifikačný dotaz stáva:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' 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 databázou vykonáva ako:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABLE Používatelia
Takže tak sme použili útok SQLI na vymazanie celej tabuľky Používatelia.
Samozrejme, je možné urobiť oveľa horšie, pretože v závislosti od povolených oprávnení SQL môže útočník meniť hodnoty, tabuľky výpisov (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, je možné jednoducho zabrániť útoku SQL injection. 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 dotaze šablóny vyššie.
SQLI útok je ľahko prekonaný tým, čo sa nazýva sanitizing (alebo uniknúť) 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, že nemôžu byť použité na predčasné ukončenie reťazca 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 jednoduchá citácia po O by spôsobila predčasné ukončenie reťazca. 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 robí každý citát so symbolom. Takže "O'neal" by sa dezinfikoval ako "O" neil ".
Tento jednoduchý úkon sanitácie skoro zabráni útoku SQLI. Ak chcete ilustrovať, vráťme sa k našim predchádzajúcim príkladom a výsledné dopyty sa zobrazia, keď sa dezinfikuje užívateľský vstup.
myuser'--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Keďže jednoduchá citácia po myuseri unikne (čo znamená, že sa považuje za súčasť cieľovej hodnoty), databáza bude vyhľadávať doslova UserName
'myuser'--'.
Navyše, pretože pomlčky sú zahrnuté do hodnoty reťazca a nie do samotného príkazu SQL, považujú sa za súčasť cieľovej hodnoty namiesto toho, aby sa interpretovali ako komentár SQL.
Robert'; DROP TABLE Users;--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Jednoduchým uniknutím jednej cenovej ponuky po Roberte sa nachádza aj bodkočiarka a pomlčky v reťazci vyhľadávania UserName, takže databáza doslova vyhľadá
'Robert'; DROP TABLE Users;--'
namiesto vykonania vymazania tabuľky.
V súhrne
Zatiaľ čo útoky na web 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 pred pokusnými a pravdivými útokmi, ktoré boli inšpiráciou niekoľkých voľne dostupných "hackerových nástrojov" určených na ich zneužívanie.
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íjemnosti až po katastrofálne v závislosti od prijatých bezpečnostných opatrení.
