26Aug
Dokonce i když jste jen volně sledovali události hackerových skupin Anonymous a LulzSec, pravděpodobně jste slyšeli o webech a službách, které jsou hackovány, jako o neslavných hackech Sony. 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 nesnažíme dát vám manuál, abyste to sami udělali, je užitečné pochopit, co se děje. Dvě z útoků, které jste o nich slyšeli, jsou "Distribuované odmítnutí služby"( DDoS) a "SQL Injections"( SQLI).Zde je návod, jak fungují.
Obrázek xkcd
Denial of Service Attack
Co je to?
"Denial of Service"( 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ížené, systém jednoduše zamknenahoru a vypne. Cíl a výsledek úspěšného útoku DDoS je, že webové stránky na cílovém serveru nejsou k dispozici k legitimním požadavkům na provoz.
Jak to funguje?
Logistika útoku DDoS lze nejlépe vysvětlit příkladem.
Představte si, že milion lidí( útočníci) se setkají s cílem omezit 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í volání zákazníků( tzn. Ty, které nejsou útočníky) se nedostanou, protože telefonní systém je svázán s manipulací s hovory od útočníků.Takže v podstatě společnost X potenciálně ztrácí svou činnost 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 provoz z legitimních požadavků a útočníků, dokud webový server zpracovává žádost, tento typ útoku je typicky velmi účinný.
Provádění útoku
Kvůli přírodě útoku DDoS "brutální síly" musíte mít spoustu počítačů koordinovaných k útoku ve stejnou dobu. Přehodnocením 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 tento princip jistě bude fungovat, pokud jde o útok na webový server, je to mnohem jednodušší, když jsou využívány počítače zombie namísto skutečně obsluhovaných počítačů.
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 příležitostně "telefon 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 updatem 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í zombie počítačů 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?
Útok "SQL injection"( SQLI) je exploit, který využívá špatné techniky vývoje webových stránek a obvykle v kombinaci s vadnou databázovou bezpečností.Výsledek úspěšného útoku se může pohybovat od předstírá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.
Provádění útoku
Kdykoli se přihlásíte na webovou stránku 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 FROM uživatele WHERE UserName = 'myuser' A heslo= 'mypass';
Poznámka: Hodnoty řetězce v dotazu SQL musí být uzavřeny v jednoduchých uvozovkách, což je důvod, proč se zobrazují 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 Users, aby bylo možné vrátit UserID.Pokud není shoda, není vráceno žádné UserID, 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íváme na dotaz ověřování šablony, který můžeme nahradit hodnoty, které uživatel zadá do webového formuláře:
SELECT UserID FROM Users WHERE UserName = '[uživatel]' A heslo = '[pass]'
se může zdát jako přímý a logický krok pro snadné ověření uživatelů, avšak pokud je na této šabloně provedena jednoduchá náhrada zadaných hodnot uživatele, je náchylná k útoku 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žijeme-li jednoduchou substituci v dotazu šablony, dostaneme to takto:
SELECT UserID FROM uživatele WHERE UserName = 'myuser' - 'AND Password =' wrongpass '
Klíčem k tomuto tvrzení je zahrnutí dvou pomlček( -.Toto je začátek 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 FROM uživatele WHERE UserName = 'myuser'
Zřejmým vynecháním zde chybí kontrola hesla. Začlenit dvě čárky jako součást uživatelského pole zcela zrušili podmínku kontroly hesla a mohli jsme se přihlásit jako "myuser" bez znalosti příslušného hesla. Tento čin manipulace s dotazem, který vede k neúmyslným výsledkům, je SQL injection injection.
Jaké škody lze provést?
Injektový útok SQL je způsoben nedbalým a nezodpovědným kódováním aplikací a je zcela zabráněno( což budeme pokrývat ihned), avšak rozsah poškození, který lze provést, závisí na nastavení databáze. Aby webová aplikace mohla komunikovat s backendovou databází, aplikace musí poskytnout přihlášení 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í a zápisu v existujících tabulkách pouze k úplnému přístupu k databázi. Není-li to nyní jasné, několik příkladů by mělo poskytnout určitou jasnost.
Na základě výše uvedeného příkladu můžete vidět, že zadáním například "youruser" - "," admin "- nebo jakéhokoli jiného jména uživatele se 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í záchrannou síť, protože webová stránka musí mít alespoň přístup k čtení a zápisům do příslušné databáze.
Nyní předpokládejme, že web 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 tento typ oprávnění vyžadovatnení automaticky špatná věc, že je zajištěna plná kontrola.
Pro ilustraci poškození, které lze v této situaci udělat, použijeme příklad uvedený v komiksu uvedení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 FROM Users WHERE UserName = 'Robert';DROP TABLE Uživatelé - 'AND Password =' wrongpass '
Poznámka: Bodkoćka v dotazu SQL se poużívá k oznaćení konce daného výkazu a zaćátku nového výkazu.
Který se provádí databází jako:
SELECT UserID FROM Uživatelé WHERE UserName = 'Robert'
Uživatelé
Takže právě tak jsme použili útok SQLI k odstranění celé tabulky uživatelů.
Samozřejmě může být mnohem horší, protože v závislosti na oprávnění SQL může útočník měnit hodnoty, vyměnit tabulky( 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.
Prevence útoku SQL
Jak jsme již několikrát zmínili, je možné snadno 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.
Útok SQLI je snadno potlačen tím, co se nazývá dezinfekce( nebo unikání) vašich vstupů.Proces dezinfekce je ve skutečnosti poměrně triviální, neboť vše, co v podstatě dělá, je zpracovávat libovolný inline jednoznačný znak( ') odpovídajícím způsobem tak, aby nemohl být použit 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 znak útěku pro inline jednoduchou citaci předkládá každý citát se symbolem \.Takže "O'neal" bude sanitován jako "O" neil ".
Tento jednoduchý hygienický postup zabraňuje útoku SQLI.Pro ilustraci přehodnoťme naše předchozí příklady a zobrazujeme výsledné dotazy, když je uživatelský vstup dezinfikován.
myuser '- / wrongpass :
SELECT uživatelské ID uživatele FROM WHERE UserName =' myuser '-' AND Password = 'wrongpass'
Protože jednoduchá citace po myuseru uniká( znamená, že je považována za součást cílehodnota), bude databáze doslova vyhledávat uživatelské jméno "myuser" - ".Navíc, protože pomlčky jsou zahrnuty v hodnotě řetězce a nikoli v samotném příkazu SQL, budou považovány za součást cílové hodnoty namísto toho, aby byly interpretovány jako komentář SQL.
Robert ';Uživatelé DROP TABLE - / wrongpass :
SELECT uživatelské ID uživatele FROM WHERE UserName = 'Robert \';DROP TABLE Uživatelé, - 'AND Password =' wrongpass '
Jednoduchým unikáním jediné citace po Robertu jsou jak středník, tak pomlčky obsaženy v vyhledávacím řetězci UserName, takže databáze doslova vyhledá uživatele "Robert";- "namísto spuštění tabulky smazat.
Souhrn
Zatímco webové útoky se vyvíjejí a stávají se propracovanějšími nebo se zaměřují na jiný vstupní bod, je důležité si uvědomit, že je třeba chránit před pokusnými a pravdivými útoky, které byly inspirací několika volně dostupných "hackerských nástrojů" určených k jejich zneužití.
Určité typy útoků, jako je 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 v rozmezí od nepohodlí po katastrofální v závislosti na přijatých bezpečnostních opatřeních.
