I když jste jen volně sledovali události hackerských skupin Anonymous a LulzSec, pravděpodobně jste už slyšeli o hackování webových stránek a služeb, jako jsou nechvalně známé hackery Sony. Přemýšleli jste někdy, jak to dělají?
Existuje několik nástrojů a technik, které tyto skupiny používají, a přestože se vám nepokoušíme poskytnout vám návod, jak to udělat sami, je užitečné pochopit, o co jde. Dva z útoků, které o nich neustále slyšíte, jsou „(Distribuované) odmítnutí služby“ (DDoS) a „Injekce SQL“ (SQLI). Zde fungují.
Obrázek od xkcd
Útok odmítnutí služby
Co je to?
K útoku typu „odmítnutí služby“ (někdy nazývané „distribuované odmítnutí služby“ nebo DDoS) dojde, když systém, v tomto případě webový server, přijme tolik požadavků najednou, že jsou prostředky serveru přetíženy, systém se jednoduše uzamkne a vypne se. Cílem a výsledkem úspěšného útoku DDoS je, že webové stránky na cílovém serveru nejsou k dispozici pro legitimní požadavky na přenos.
Jak to funguje?
Logistiku útoku DDoS lze nejlépe vysvětlit na příkladu.
Představte si, že se milion lidí (útočníků) spojí s cílem bránit podnikání společnosti X tím, že zničí jejich call centrum. Útočníci se koordinují tak, že v úterý v 9:00 budou všichni volat na telefonní číslo společnosti X. Telefonní systém společnosti X s největší pravděpodobností nebude schopen zvládnout milion hovorů najednou, takže útočníci budou spojovat všechny příchozí linky. Výsledkem je, že legitimní hovory zákazníků (tj. Ty, které nejsou útočníky) se nedostanou přes, protože telefonní systém je svázán s vyřizováním hovorů od útočníků. V podstatě tedy společnost X potenciálně ztrácí obchod kvůli tomu, že legitimní požadavky nemohou projít.
Útok DDoS na webový server funguje přesně stejným způsobem. Protože prakticky neexistuje způsob, jak zjistit, jaký provoz pochází od legitimních požadavků vs. útočníků, dokud webový server požadavek nezpracovává, je tento typ útoku obvykle velmi efektivní.
Provedení útoku
Kvůli povaze DDoS útoku „hrubou silou“ musíte mít spoustu počítačů koordinovaných k útoku současně. Když se vrátíme k našemu příkladu call centra, bude to vyžadovat, aby všichni útočníci věděli, že mají dorovnat v 9:00 a skutečně dorovnat v té době. I když tento princip určitě bude fungovat, pokud jde o útok na webový server, je výrazně jednodušší, když se místo skutečných počítačů s posádkou využijí počítače zombie.
Jak pravděpodobně víte, existuje spousta variant malwaru a trojských koní, které ve vašem systému jednou dřímají a občas „telefonují domů“. 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. Díky jediné aktualizaci domovského umístění příslušného malwaru může jeden útočník okamžitě koordinovat stovky tisíc napadených počítačů a provést tak rozsáhlý útok DDoS.
Krása využití zombie počítačů není jen v jeho efektivitě, ale také v jeho anonymitě, protože útočník ve skutečnosti k provedení útoku nemusí vůbec používat svůj počítač.
SQL Injection Attack
Co je to?
Útok „SQL injection“ (SQLI) je zneužití, které využívá špatné techniky vývoje webu a obvykle je kombinováno s chybným zabezpečením databáze. Výsledek úspěšného útoku se může pohybovat od zosobnění uživatelského účtu až po úplný kompromis příslušné databáze nebo serveru. Na rozdíl od útoku DDoS je možné útoku SQLI zcela a snadno zabránit, pokud je webová aplikace správně naprogramována.
Provedení útoku
Kdykoli se přihlásíte na webovou stránku a zadáte své uživatelské jméno a heslo, může webová aplikace za účelem otestování vašich přihlašovacích údajů spustit dotaz, jako je následující:
VYBERTE ID UŽIVATELE OD uživatelů WHERE UserName = 'myuser' AND Password = 'mypass';
Poznámka: Hodnoty řetězců v dotazu SQL musí být uzavřeny do jednoduchých uvozovek, proto se objevují kolem hodnot zadaných uživatelem.
Kombinace zadaného uživatelského jména (myuser) a hesla (mypass) se tedy musí shodovat se záznamem v tabulce Users, aby bylo možné UserID vrátit. Pokud neexistuje žádná shoda, nevrátí 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í.
Podívejme se tedy na ověřovací dotaz šablony, který můžeme nahradit hodnotami, které uživatel zadá do webového formuláře:
VYBERTE ID UŽIVATELE OD uživatelů WHERE UserName = '[user]' AND Password = '[pass]'
Na první pohled se to může zdát jako přímý a logický krok pro snadnou validaci uživatelů, ale pokud se na této šabloně provede jednoduchá náhrada 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é heslo“. Pomocí jednoduchého nahrazení v našem dotazu na šablonu bychom dostali toto:
VYBERTE ID UŽIVATELE OD uživatelů 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 vše, co se objeví po dvou pomlčkách (včetně), bude ignorováno. V podstatě je výše uvedený dotaz spuštěn databází jako:
VYBERTE ID UŽIVATELE OD uživatelů WHERE UserName = 'myuser'
Do očí bijícím opomenutím je absence kontroly hesla. Zahrnutím těchto dvou pomlček jako součásti uživatelského pole jsme úplně obcházeli podmínku kontroly hesla a mohli jsme se přihlásit jako „myuser“, aniž bychom znali příslušné heslo. Tento akt manipulace s dotazem za účelem dosažení nezamýšlených výsledků je útokem SQL injection.
Jaké škody lze způsobit?
Útok SQL Injection je způsoben nedbalým a nezodpovědným kódováním aplikace a lze mu zcela zabránit (kterému se za chvíli věnujeme), avšak rozsah poškození, které lze způsobit, závisí na nastavení databáze. Aby mohla webová aplikace komunikovat s back-endovou databází, musí aplikace zadat přihlašovací údaje do databáze (všimněte si, že se liší od přihlašovacího jména uživatele na samotný web). 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 vám několik příkladů poskytnout jistou srozumitelnost.
Na základě výše uvedeného příkladu můžete vidět, že například zadáním
"youruser '-", "admin' -"
nebo jakékoli jiné uživatelské jméno, můžeme se okamžitě přihlásit jako uživatel bez znalosti hesla. Jakmile jsme v systému, neví, že ve skutečnosti nejsme tímto uživatelem, takže máme plný přístup k příslušnému účtu. Oprávnění k databázi k tomu neposkytují bezpečnostní síť, protože web obvykle musí mít alespoň přístup ke čtení / zápisu do příslušné databáze.
Nyní předpokládejme, že web má plnou kontrolu nad svou příslušnou databází, která umožňuje mazat záznamy, přidávat / odebírat tabulky, přidávat nové bezpečnostní účty atd. Je důležité si uvědomit, že některé webové aplikace mohou tento typ oprávnění potřebovat, takže není automaticky špatná věc, že je zaručena plná kontrola.
Abychom ilustrovali poškození, které lze v této situaci způsobit, použijeme příklad uvedený v komiksu výše zadáním následujícího do pole uživatelské jméno:
"Robert '; Uživatelé DROP TABLE; -".
Po jednoduchém nahrazení se autentizační dotaz stane:
VYBERTE ID UŽIVATELE OD uživatelů WHERE UserName = 'Robert'; Uživatelé DROP TABLE; - 'AND Password =' wrongpass '
Poznámka: středník je v dotazu SQL slouží k označení konce konkrétního příkazu a začátku nového příkazu.
Který je spuštěn databází jako:
VYBERTE ID UŽIVATELE OD uživatelů WHERE UserName = 'Robert'Uživatelé DROP TABLE
Právě tak jsme použili útok SQLI k odstranění celé tabulky Users.
Samozřejmě lze udělat mnohem horší, protože v závislosti na povolených oprávněních SQL může útočník změnit hodnoty, vypsat tabulky (nebo celou databázi samotnou) do textového souboru, vytvořit nové přihlašovací účty nebo dokonce unést celou instalaci databáze.
Prevence útoku s vložením SQL
Jak jsme již několikrát zmínili, útoku pomocí SQL injection se dá 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 jednoduchou substituci v našem dotazu na šablonu výše.
Útok SQLI lze snadno zmařit tím, co se nazývá sanitace (nebo únik) vašich vstupů. Proces sanitace je ve skutečnosti docela triviální, protože v podstatě pouze zpracovává všechny znaky inline single quote (‘) vhodně tak, aby nemohly být použity k předčasnému ukončení řetězce uvnitř příkazu SQL.
Například pokud jste chtěli vyhledat „O’neil“ v databázi, nemůžete 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 znaku příslušné databáze. Předpokládejme, že únikový znak pro vloženou jednoduchou citaci předznamenává každou citaci symbolem \. Takže „O’neal“ by byl dezinfikován jako „O \ 'neil“.
Tento jednoduchý proces sanitace do značné míry zabraňuje útoku SQLI. Pro ilustraci se vraťme k našim předchozím příkladům a uvidíme výsledné dotazy, když bude vstup uživatele dezinfikován.
myuser '-
/
špatný průchod
:
VYBERTE ID UŽIVATELE OD uživatelů WHERE UserName = 'myuser \' - 'AND Password =' wrongpass '
Vzhledem k tomu, že jediná uvozovka po myuser unikla (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 v 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 '; Uživatelé DROP TABLE; -
/
špatný průchod
:
VYBERTE ID UŽIVATELE OD uživatelů WHERE UserName = 'Robert \'; Uživatelé DROP TABLE; - 'AND Password =' wrongpass '
Jednoduše uniknutím jednoduché nabídky za Robertem jsou středník a pomlčky obsaženy ve vyhledávacím řetězci UserName, takže databáze bude doslova hledat
„Robert“; Uživatelé DROP TABLE; - “
namísto provedení odstranění tabulky.
Celkem
Zatímco se webové útoky 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 vyzkoušenými a opravdovými útoky, které byly inspirací několika volně dostupných „hackerských nástrojů“ určených k jejich zneužití.
Určitým typům útoků, jako je DDoS, se nelze snadno vyhnout, zatímco jiným, jako je například SQLI, ano. Škody, které lze těmito typy útoků napáchat, se však mohou pohybovat kdekoli od nepříjemnosti až po katastrofické, v závislosti na přijatých preventivních opatřeních.
