I když jste události sledovali pouze volněhackerských skupin Anonymous a LulzSec jste pravděpodobně slyšeli o hackerských webech a službách, jako jsou nechvalně proslulí hackeři Sony. Přemýšleli jste někdy, jak to dělají?
Existuje celá řada nástrojů a technik, kterétyto skupiny používají, a přestože se vám nepokoušíme poskytnout návod, jak to udělat sami, je užitečné pochopit, co se děje. Dva z útoků, které o nich neustále slyšíte, jsou „(Distributed) Denial of Service“ (DDoS) a „SQL Injections“ (SQLI). Takto fungují.
Obrázek od xkcd
Denial of Service Attack
Co je to?
„Popření služby“ (někdy se nazývá aK útoku „distribuovaného odmítnutí služby“ nebo DDoS) dochází, když systém, v tomto případě webový server, obdrží tolik požadavků najednou, že zdroje serveru jsou přetíženy, systém se jednoduše zamkne a vypne. Cílem a výsledkem úspěšného útoku DDoS je, že weby na cílovém serveru nejsou k dispozici legitimním požadavkům na provoz.
Jak to funguje?
Logiku útoku DDoS lze nejlépe vysvětlit na příkladu.
Představte si milion lidí (útočníků)spolu s cílem omezit podnikání společnosti X zrušením jejich call centra. Útočníci se koordinují tak, aby v úterý v 9 hodin všichni zavolali na telefonní číslo společnosti X. Telefonický systém společnosti X s největší pravděpodobností nebude schopen zvládnout milion hovorů najednou, takže útočníci budou svázáni všechny příchozí linky. Výsledkem je, že legitimní volání zákazníků (tj. Volání, která nejsou útočníky), neprobíhají, protože telefonní systém je svázán při manipulaci s hovory od útočníků. Společnost X tedy v podstatě potenciálně ztrácí podnikání kvůli legitimním požadavkům, které nemohou projít.
Útok DDoS na webovém serveru funguje přesně jakoStejným způsobem. Protože neexistuje prakticky žádný způsob, jak zjistit, jaký provoz pochází z legitimních požadavků vs. útočníků, dokud webový server požadavek nezpracuje, je tento typ útoku obvykle velmi účinný.
Provedení útoku
Vzhledem k charakteru brutální síly útoku DDoS,musíte mít spoustu počítačů koordinovaných k útoku současně. Při revizi příkladu našeho call centra by to vyžadovalo, aby všichni útočníci věděli, že budou volat v 9:00 a skutečně zavolat v tu dobu. I když tento princip jistě bude fungovat, pokud jde o útok na webový server, je podstatně snazší, když se používají zombie počítače namísto skutečných počítačů s posádkou.
Jak asi víte, existuje spousta variantmalware a trojských koní, které, jakmile na vašem systému, leží spící a občas „telefon domů“, kde najdete pokyny. Jedním z těchto pokynů může být například zaslání opakovaných požadavků na webový server společnosti X v 9 hodin. Díky jediné aktualizaci domovského umístění příslušného malwaru může jediný útočník okamžitě koordinovat stovky tisíc ohrožených počítačů, aby provedl masivní útok DDoS.
Krása využití zombie počítačů je nejen v jeho účinnosti, ale také v anonymitě, protože útočník ve skutečnosti nemusí k provedení útoku vůbec použít svůj počítač.
SQL Injection Attack
Co je to?
Útok „SQL injection“ (SQLI) je zneužitímkterý využívá výhod špatných technik vývoje webových aplikací a obvykle v kombinaci s chybnou bezpečností databáze. Výsledek úspěšného útoku se může pohybovat od odcizení uživatelského účtu až po úplný kompromis příslušné databáze nebo serveru. Na rozdíl od útoku DDoS lze útoku SQLI zcela a snadno zabránit, pokud je webová aplikace správně naprogramována.
Provedení útoku
Kdykoli se přihlásíte na web a zadáte své uživatelské jméno a heslo, může webová aplikace vyzkoušet vaše přihlašovací údaje, aby spustila dotaz, jako je následující:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Poznámka: Hodnoty řetězce v dotazu SQL musí být uzavřeny v jednoduchých uvozovkách, a proto se objevují kolem hodnot zadaných uživatelem.
Kombinace zadaného uživatelského jména(myuser) a heslo (mypass) musí odpovídat záznamu v tabulce Users, aby bylo možné UserID vrátit. Pokud neexistuje shoda, nevrací se žádné ID uživatele, takže přihlašovací údaje jsou neplatné. I když se konkrétní implementace může lišit, mechanika je docela standardní.
Nyní se podívejme na ověřovací dotaz šablony, který můžeme nahradit hodnoty, které uživatel zadá do webového formuláře:
VYBRAJTE ID uživatele od uživatelů, KDE Jméno_uživatele = '[uživatel]' a heslo = '[průchod]'
Na první pohled se to může zdát jakopřímý a logický krok pro snadnou validaci uživatelů, avšak pokud je na této šabloně provedeno jednoduché nahrazení hodnot zadaných uživatelem, je to náchylné k útoku SQLI.
Předpokládejme například, že do pole uživatelského jména je zadáno „myuser“ - a do hesla je zadáno „špatný přístup“. Pomocí jednoduchého nahrazení v našem dotazu na šablonu bychom dostali toto:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Klíčem k tomuto tvrzení je zahrnutí dvou pomlček (--). Toto je token začátku komentáře pro příkazy SQL, takže cokoli, co se objeví po dvou pomlčkách (včetně), bude ignorováno. Výše uvedený dotaz se v podstatě provádí databází jako:
SELECT UserID FROM Users WHERE UserName='myuser'
Do očí bijící opomenutí je nedostatekkontrola hesla. Zahrnutím dvou pomlček do pole uživatele jsme zcela obešli podmínku kontroly hesla a mohli jsme se přihlásit jako „myuser“, aniž bychom znali příslušné heslo. Tento akt manipulace dotazu za účelem dosažení nezamýšlených výsledků je SQL injekční útok.
Jaké poškození může být způsobeno?
SQL injekční útok je způsoben nedbalostí anezodpovědné kódování aplikace a lze mu zcela zabránit (čemu se budeme zabývat za chvíli), rozsah poškození, který lze provést, však závisí na nastavení databáze. Aby webová aplikace mohla komunikovat s backendovou databází, musí aplikace poskytnout přihlašovací údaje do databáze (všimněte si, že se to liší od přihlašování uživatele k samotné webové stránce). V závislosti na tom, jaká oprávnění webová aplikace vyžaduje, může tento příslušný databázový účet vyžadovat cokoli od oprávnění ke čtení / zápisu ve stávajících tabulkách až po úplný přístup k databázi. Pokud to nyní není jasné, mělo by to poskytnout několik jasných příkladů.
Na základě výše uvedeného příkladu to můžete vidět například zadáním, "youruser'--", "admin'--" nebo jakékoli jiné uživatelské jméno, můžeme se okamžitě přihlásitjako uživatel bez znalosti hesla. Jakmile jsme v systému, nevíme, že nejsme vlastně tímto uživatelem, takže máme plný přístup k příslušnému účtu. Oprávnění databáze k tomu neposkytuje bezpečnostní síť, protože obvykle musí mít web alespoň přístup ke čtení a zápisu do své příslušné databáze.
Nyní předpokládejme, že web má plnou kontrolupříslušná databáze, která umožňuje mazat záznamy, přidávat / odebírat tabulky, přidávat nové účty zabezpečení atd. Je důležité si uvědomit, že některé webové aplikace mohou potřebovat tento typ povolení, takže není automaticky špatnou věcí, že úplná kontrola je udělené.
Pro ilustraci škody, která může být v této situaci způsobena, použijeme příklad uvedený v komiksu výše zadáním následujícího do pole uživatelského jména: "Robert'; DROP TABLE Users;--". Po jednoduchém nahrazení se ověřovací dotaz stane:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Poznámka: středník je v dotazu SQL, který se používá k označení konce konkrétního příkazu a začátku nového příkazu.
Který bude spuštěn databází jako:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABLE Uživatelé
Stejně tak jsme použili útok SQLI k odstranění celé tabulky Users.
Samozřejmě, mnohem horší lze udělat, v závislosti na tompovolená oprávnění SQL, může útočník změnit hodnoty, výpisové tabulky (nebo celou databázi samotnou) na textový soubor, vytvořit nové přihlašovací účty nebo dokonce unést celou instalaci databáze.
Prevence útoku SQL injection
Jak jsme již několikrát zmínili, SQLinjekčnímu útoku lze snadno zabránit. Jedním z hlavních pravidel vývoje webu je, že nikdy slepě nedůvěřujete vstupu uživatele, jako jsme to udělali, když jsme provedli jednoduché nahrazení v našem dotazu na šablonu výše.
Útok SQLI je snadno zmařen tím, co jenazývá se dezinfekce (nebo unikání) vašich vstupů. Proces dezinfekce je ve skutečnosti docela triviální, protože vše, co v podstatě dělá, je odpovídající manipulace s libovolnými inline jednoduchými uvozovkami (‘), takže je nelze použít k předčasnému ukončení řetězce uvnitř příkazu SQL.
Pokud například chcete vyhledat „O'neil“ vdatabázi, nelze použít jednoduchou substituci, protože jednoduchá nabídka za O by způsobila předčasné ukončení řetězce. Místo toho ji dezinfikujete pomocí únikového charakteru příslušné databáze. Předpokládejme, že znak escape pro inline single quote je před každou nabídkou quote se symbolem. Takže „O'neal“ by bylo dezinfikováno jako „O'neil“.
Tento jednoduchý akt hygieny do značné míry zabraňuje útoku SQLI. Pro ilustraci se podívejme na předchozí příklady a podívejte se na výsledné dotazy, když je vstup uživatele dezinfikován.
myuser'-- / špatný průchod:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Protože je uniklá jednoduchá nabídka po myuserovi (což znamená, že je považována za součást cílové hodnoty), databáze bude doslova hledat uživatelské jméno "myuser'--". Navíc protože pomlčky jsou zahrnuty v hodnotě řetězce a nikoli samotném příkazu SQL, budou považovány za součást cílové hodnoty místo toho, aby byly interpretovány jako komentář SQL.
Robert'; DROP TABLE Users;-- / špatný průchod:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Jednoduše unikne jediný citát po Robertovi, středník i pomlčky jsou obsaženy ve vyhledávacím řetězci UserName, takže databáze bude doslova hledat "Robert'; DROP TABLE Users;--" namísto provedení tabulky odstranit.
Celkem
Zatímco webové útoky se vyvíjejí a stávají se vícesofistikovaný nebo se zaměřit na jiný bod vstupu, je důležité pamatovat na ochranu před vyzkoušenými a skutečný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 je DDoS, nemohou býtsnadno se vyhnout, zatímco ostatní, jako je SQLI, mohou. Škody, které mohou tyto typy útoků způsobit, se však mohou pohybovat od nepohodlí až po katastrofální v závislosti na přijatých opatřeních.
