Jak hackeři přebírají webové stránky s SQL Injection a DDoS
Dokonce i když jste jen sledovali události hackerských skupin Anonymous a LulzSec, pravděpodobně jste slyšeli o tom, že jsou webové stránky a služby hackovány, jako jsou neslavné Sony hacks. Přemýšleli jste někdy o tom, jak to dělají?
Existuje řada nástrojů a technik, které tyto skupiny používají, a když se nepokoušíme dát vám manuál, abyste to sami udělali, je užitečné pochopit, co se děje. Dva z útoků, které jste o nich slyšeli, jsou "Distributed Denial of Service" (DDoS) a "SQL Injections" (SQLI). Zde je, jak fungují.
Obrázek o xkcd
Odmítnutí útoku na službu
Co je to?
"Odepření služby" (někdy nazývané "distribuované odmítnutí služby" nebo DDoS) nastane, když systém, v tomto případě webový server, obdrží tolik požadavků najednou, že jsou zdroje serveru přetíženy, systém se jednoduše uzamkne a vypne se. Cíl a výsledek úspěšného útoku DDoS je, že webové stránky na cílovém serveru nejsou k dispozici pro legitimní požadavky na provoz.
Jak to funguje?
Logistiku útoku DDoS lze nejlépe vysvětlit příkladem.
Představte si, že se milion lidí (útočníci) setká s cílem zabránit podnikání společnosti X tím, že sníží své call centrum. Útočníci koordinují tak, aby v úterý v 9:00 všichni volali na telefonní číslo společnosti X. S největší pravděpodobností telefonní systém společnosti X nebude schopen zvládnout milion hovorů najednou, takže všechny příchozí linky budou svázány útočníky. Výsledkem je, že legitimní zákaznické hovory (tj. Ty, které nejsou útočníky) neprocházejí, protože telefonní systém je svázán s manipulací s hovory od útočníků. Takže společnost X je v podstatě potenciálně ztracena kvůli oprávněným požadavkům, které nemohou projít.
Útok DDoS na webový server funguje přesně stejným způsobem. Protože neexistuje prakticky žádný způsob, jak zjistit, jaký je zdroj z legitimních požadavků a útočníků, dokud webový server zpracovává požadavek, tento typ útoku je obvykle velmi účinný.
Provedení útoku
Kvůli přírodě útoku DDoS "hrubou silou" musíte mít spoustu počítačů koordinovaných k útoku ve stejnou dobu. Při přehodnocení našeho příkladu telefonického centra by to vyžadovalo, aby všichni útočníci oba věděli, že mají volat v 9:00 a skutečně volají v té době. Zatímco tato zásada jistě bude fungovat, pokud jde o útok na webový server, je to podstatně jednodušší, když jsou zombie počítače namísto skutečných počítačů s posádkou využívány.
Jak pravděpodobně víte, existuje spousta variant malwaru a trojských koní, které jednou na vašem systému ležely spící a občas "telefonovaly domů" pro instrukce. Jedním z těchto pokynů může být například odeslání opakovaných požadavků na webový server společnosti X v 9:00. Takže s jediným upgradem na domovské umístění příslušného malwaru může jeden útočník okamžitě koordinovat stovky tisíc kompromitovaných počítačů a provádět masivní útok DDoS.
Krása využití počítačů zombie je nejen v jeho účinnosti, ale také v jeho anonymitě, protože útočník ve skutečnosti nemusí používat svůj počítač k útoku.
SQL Injection Attack
Co je to?
"SQL injection" (SQL injection) útok je exploit, který využívá špatných technik vývoje webu a obvykle v kombinaci s vadnou databázovou bezpečností. Výsledek úspěšného útoku může být v rozmezí od zosobnění uživatelského účtu k úplnému kompromisu příslušné databáze nebo serveru. Na rozdíl od útoku DDoS je útok SQLI zcela a snadno zabráněn, pokud je webová aplikace vhodně naprogramována.
Provedení útoku
Kdykoli se přihlásíte na webové stránky a zadáte uživatelské jméno a heslo, za účelem otestování pověření webová aplikace může spustit dotaz, jako je následující:
SELECT UserID z uživatelů WHERE UserName = "myuser" A heslo = "mypass";
Poznámka: Hodnoty řetězce v dotazu SQL musí být přiloženy k jednotlivým uvozovkám, a proto se objevují kolem hodnot zadaných uživatelem.
Takže kombinace zadaného uživatelského jména (myuser) a hesla (mypass) musí odpovídat položce v tabulce Uživatelé, aby bylo možné vrátit UserID. Pokud neexistuje shoda, není vráceno žádné uživatelské ID, takže přihlašovací údaje jsou neplatné. Zatímco konkrétní implementace se může lišit, mechanika je docela standardní.
Takže teď se podívejme na dotaz ověřování šablon, který můžeme nahradit hodnotami, které uživatel zadá do webového formuláře:
SELECT UserID z uživatelů WHERE UserName = "[user]" A heslo = "[pass]"
Na první pohled se to může zdát jako přímý a logický krok pro snadné ověření uživatelů, nicméně pokud se na této šabloně provede jednoduchá náhrada zadaných hodnot uživatele, je náchylná na útok SQLI.
Předpokládejme například, že v poli uživatelského jména je zadáno "myuser'-" a v hesle je zadáno "wrongpass". Použitím jednoduché náhrady v našem šablonovém dotazu bychom získali toto:
SELECT ID uživatele FROM uživatele WHERE UserName = "myuser" - "AND Password =" wrongpass "
Klíčem k tomuto tvrzení je zahrnutí dvou pomlček (-). Toto je počáteční token komentářů pro příkazy SQL, takže vše, co se objeví po dvou pomlčkách (včetně), bude ignorováno. V podstatě je výše uvedený dotaz proveden v databázi jako:
SELECT UserID z uživatelů WHERE UserName = "myuser"
Zřejmým vynecháním je nedostatek kontroly hesla. Začleněním dvou pomlček v rámci uživatelského pole zcela zrušili podmínku kontroly hesla a bylo možné se přihlásit jako "myuser" bez znalosti příslušného hesla. Tento čin manipulace s dotazem, který vedl k neúmyslným výsledkům, je útok SQL injection.
Jaká škoda může být provedena?
Injektový útok SQL je způsoben nedbalým a nezodpovědným kódováním aplikací a je zcela zabráněno (které budeme pokrývat v jednom okamžiku), avšak rozsah poškození, který lze provést, závisí na nastavení databáze. Aby webová aplikace mohla komunikovat s backendovou databází, musí aplikace přihlásit do databáze (poznámka, toto je jiné než uživatelské přihlášení k samotnému webu). V závislosti na tom, jaké oprávnění vyžaduje webová aplikace, může příslušný databázový účet vyžadovat cokoli od oprávnění čtení / zápis v existujících tabulkách pouze k úplnému přístupu k databázi. Pokud to nyní není jasné, několik příkladů by mělo pomoci poskytnout určitou jasnost.
Na základě výše uvedeného příkladu to můžete vidět například zadáním, "youruser" - "," admin "-" nebo jakéhokoli jiného uživatelského jména, můžeme okamžitě přihlásit k webu jako tento uživatel bez znalosti hesla. Jakmile jsme v systému, neví, že nejsme vlastně ten uživatel, takže máme plný přístup k příslušnému účtu. Databázová oprávnění neposkytují bezpečnostní síť, protože webová stránka musí mít alespoň přístup k čtení a zápisu do příslušné databáze.
Nyní předpokládejme, že webová stránka má plnou kontrolu nad příslušnou databází, která umožňuje odstranit záznamy, přidávat nebo odstraňovat tabulky, přidávat nové bezpečnostní účty apod. Je důležité si uvědomit, že některé webové aplikace mohou vyžadovat tento typ oprávnění, takže není automaticky špatná věc, která je plná kontrola udělena.
Abychom ukázali škody, které lze v této situaci udělat, použijeme příklad obsažený v tomto komiksu zadáním následujícího pole do pole uživatelského jména: "Robert"; Uživatelé DROP TABLE; - ". Po jednoduché substituci se ověřovací dotaz stává:
SELECT UserID z uživatelů WHERE UserName = "Robert"; Uživatelé DROP TABLE - "AND Password =" wrongpass "
Poznámka: středník v dotazu SQL se používá k označení konce určitého příkazu a začátku nového příkazu.
Který se provádí databází jako:
SELECT UserID z uživatelů WHERE UserName = "Robert"DROP TABLE Uživatelé
Takže právě tak jsme použili SQLI útok k odstranění celé tabulky uživatelů.
Samozřejmě může být mnohem horší, jelikož v závislosti na oprávnění SQL může útočník měnit hodnoty, tabulky výpisů (nebo celou databázi sám) do textového souboru, vytvořit nové přihlašovací účty nebo dokonce unášet celou instalaci databáze.
Zabránění útoku SQL injection
Jak jsme již dříve několikrát zmínili, lze zabránit útoku SQL injection. Jedním z hlavních pravidel tvorby webových stránek je, že jste nikdy slepě nevěřili vstupu uživatele, jako jsme udělali, když jsme provedli jednoduchou náhradu v našem šablonovém dotazu výše.
SQLI útok je snadno potlačen tím, co se nazývá sanitizing (nebo uniknout) vaše vstupy. Proces dezinfekce je ve skutečnosti poměrně triviální, protože vše, co v podstatě dělá, je zpracovávat libovolné inline jednoduché citáty (') odpovídajícím způsobem tak, aby nebyly použity k předčasnému ukončení řetězce uvnitř příkazu SQL.
Například, pokud jste chtěli v databázi hledat "O'neil", nemohli jste použít jednoduchou náhradu, protože jednoduchá citace po O by způsobila, že by řetězec předčasně skončil. Místo toho je dezinfikujete pomocí příslušného únikového znaku databáze. Předpokládejme, že úniková postava pro inline jednoduchou citaci předkládá každou citaci se symbolem \. Takže "O'neal" bude sanitizován jako "O" neil ".
Tento jednoduchý hygienický postup zabraňuje útoku SQLI. Pro ilustraci přehodnoťme naše předchozí příklady a zkontrolujte výsledné dotazy, když je uživatelský vstup dezinfikován.
myuser '-- / nesprávný průchod:
SELECT UserID z uživatelů WHERE UserName = "myuser" - "AND Password =" wrongpass "
Protože jediný citát po myuseru unikne (což znamená, že je považován za část cílové hodnoty), databáze bude vyhledávat doslova UserName "myuser" - ". Navíc, protože pomlčky jsou zahrnuty v hodnotě řetězce a nikoliv v samotném příkazu SQL, budou považovány za část cílové hodnoty místo toho, aby byly interpretovány jako komentář SQL.
Robert '; DROP TABLE Uživatelé;-- / nesprávný průchod:
SELECT UserID z uživatelů WHERE UserName = "Robert \"; Uživatelé DROP TABLE - "AND Password =" wrongpass "
Jednoduchým unikáním jediné citace po Robertu se v rámci vyhledávacího řetězce UserName nachází jak středník, tak pomlčky, takže databáze doslova vyhledá "Robert"; Uživatelé DROP TABLE; - " namísto spuštění tabulky smazat.
Celkem
Zatímco webové útoky se vyvíjejí a stávají se sofistikovanějšími nebo se zaměřují na jiný vstupní bod, je důležité pamatovat na ochranu před pokusnými a opravdovými útoky, které byly inspirací několika volně dostupných "hackerských nástrojů" určených k jejich zneužití.
Některé typy útoků, jako například DDoS, nelze snadno zabránit, zatímco jiné, jako například SQLI, mohou. Škody, které mohou být způsobeny těmito typy útoků, se však mohou pohybovat od nepohodlí po katastrofální v závislosti na přijatých bezpečnostních opatřeních.
