I když jste jen sledovali události hackerových skupin Anonymous a LulzSec, pravděpodobně jste slyšeli o webových stránkách a služby jsou hacknuty, stejně jako 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 zatímco se nesnažíme dát vám manuál, který by to udělal sami, 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).

Obraz xkcd

Denial of Service Attack

Co je to?

"Denial of Service" útok nastane, když systém, v tomto případě webový server, obdrží tolik požadavků najednou, že zdroje serveru jsou přetížené, systém se jednoduše zamkne a vypne. 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 provoz.

Jak to funguje?

Logistika útoku DDoS může být nejlépe vysvětlena příkladem. > Představte si, že milion lidí (útočníci) se shromáždí s cílem omezit podnikání firmy 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í svoji č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á požadavek, tento typ útoku je obvykle velmi účinný.

Provádění útoku

síla "přírody útoku DDoS, 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ž se používají počítače zombie namísto skutečných počítačů s posádkou.

Jak asi víte, existuje spousta variant malwaru a trojských koní, , jakmile se ve vašem systému setkáte, jste spící a příležitostně "telefonujte domů" pro pokyny. 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 updatáním 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čů není jen efektivní, ale také v jeho anonymitě, protože útočník ve skutečnosti nepoužívá vůbec počítač k útoku.

SQL Injection Attack

Co je to?

Akt "SQL injection" (SQLI) který využívá špatné techniky vývoje webových stránek a obvykle v kombinaci s chybnou 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 správně naprogramována webová aplikace.

Provádění útoku

Kdykoli se přihlásíte na webovou stránku a zadáte uživatelské jméno a heslo, pověření může webová aplikace 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 zadaných hodnot uživatele.

Takže kombinace zadaného uživatelského jména (myuser) a hesla (mypass) musí odpovídat položce v Tabulka uživatelů, aby bylo možné vrátit ID uživatele. 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í.

Nyní se podíváme na dotaz ověřování šablon, který můžeme nahradit hodnoty, které uživatel zadá do webového formuláře:

SELECT UserID FROM Users WHERE UserName = [user] "AND Password =" [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 je v této šabloně provedena jednoduchá náhrada zadaných hodnot uživatelem náchylné k útoku SQLI.

Předpokládejme například, že v poli uživatelského jména je zadáno "myuser" - a do hesla je zadáno "wrongpass". Použijeme-li jednoduchou substituci v našem šablonovém dotazu, získáme toto:

SELECT UserID FROM Users 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živatelé WHERE UserName = "myuser"

Výrazný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 útok SQL injection

Jaká škoda může být provedena?

SQL injekční útok je způsoben nedbalým a nezodpovědným kódováním aplikace a je zcela zabráněno chvíli), 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. Pokud to není jasné, několik příkladů by mělo pomoci 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 uživatelského jména, můžeme okamžitě přihlásit se 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ápisu do příslušné databáze.Nyní předpokládejme, že web má plnou kontrolu nad příslušnou databází, která dává možnost vymazání záznamů, přidávání / odebírání tabulek, přidávání nových bezpečnostních účtů 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, že ​​je poskytována plná kontrola. ilustrujeme škody, které lze v této situaci udělat, použijeme příklad uvedený v komiksu výše zadáním následujícího pole do uživatelského jména:

"Robert"; uživatelé DROP TABLE; - "

Po jednoduše nahradí ověřovací dotaz: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 konkrétního výkazu a zaćátku nového výkazu.

Který se provádí databáze jako:

SELECT UserID z uživatelů WHERE UserName = "Robert"

DROP TABLE Users

Takže jsme použili SQLI útok k odstranění celé tabulky Users

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, vypisovat tabulky (nebo celou databázi sám) do textového souboru, vytvářet nové přihlašovací účty nebo dokonce zatajovat celou instalaci databáze.

Zabránění útoku SQL injection

Jak jsme již několikrát zmínili, útok útoku SQL lze snadno zabránit. Jednou z hlavních pravidel tvorby webových stránek je, že jste nikdy slepě nevěřili uživatelskému vstupu, 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á dezinfekce (nebo únik) 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 jednoduché citáty (') odpovídajícím způsobem tak, že nemohou být použity k předčasnému ukončení řetězce uvnitř příkazu SQL.

Například, pokud jste chtěli vyhledávání "O'neil" v databázi, nemůžete použít jednoduchou náhradu, protože jednoduchá citace po O způsobí, že řetězec bude předčasně ukončen. 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 sanitizován jako "O 'neil".

Tento jednoduchý hygienický postup zabraňuje útoku SQLI. Chcete-li to ilustrovat, přejděte zpět na naše předchozí příklady a zkontrolujte výsledné dotazy, jakmile je uživatelský vstup dezinfikován

myuser '-

/

wrongpass : SELECT UserID FROM Users WHERE UserName = myuser "- 'a heslo =" wrongpass " Protože jednoduchá citace po myuseru uniká (znamená to, že je považována za část cílové hodnoty), databáze bude vyhledávat uživatelské jméno

" 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é -/

wrongpass : SELECT UserID FROM Uživatelé WHERE UserName = "Robert "; DROP TABLE Uživatelé - "AND Password =" wrongpass " Jednoduchým unikáním jediné citace po Robertu jsou mezi vyhledávacím řetězcem UserName obsaženy středník a pomlčky tak, aby databáze doslova vyhledávala

" Robert " , "DROP TABLE Users" - "

namísto provádění vymazání tabulkyV souhrnuZatímco webové útoky se vyvíjejí a stávají se sofistikovanějšími nebo se zaměřují na jiný vstupní bod, proti pokusům a opravdovým útokům, 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, se nedají snadno vyhnout, zatímco jiné, jako je SQLI, mohou. Nicméně škody, které mohou být způsobeny těmito typy útoků, se mohou pohybovat v rozmezí od nepohodlí po katastrofální v závislosti na přijatých opatřeních.

Proč je hlášení systému Windows o této složce příliš dlouhé na kopírování?

Pokud pracujete s Windows dostatečně dlouhou dobu, zejména se složkami a soubory s dlouhými názvy, dojde k bizarní chybě : Systém Windows hlásí, že cesta k souboru nebo název souboru je příliš dlouhá, než se přesune na nový cíl nebo dokonce odstraní. Co je to? Hej How-To Geek! Takže druhý den jsem reorganizoval některé soubory na svém počítači, vytvářel složky, takové věci.

(how-to)

Jak přehrávat Minecraft z Flash disku pro blokování budov Zábava kdekoliv

Co je zábavnější než kreativní blok v budově Minecraft? Budování kdykoli a kdekoli budete chtít s přenosnou instalací Minecraft na flash disku, můžete vzít s sebou. Přečtěte si o tom, jak nakonfigurovat přenosnou kopii Minecraft pro zábavu "build-anywhere" Proč to chci dělat? Standardní instalace Minecraft parkuje vaše herní data Minecraft v systémovém adresáři a až do velmi nedávná aktualizace spouštěče Minecraft, kterou ne všichni hráči ještě využili, se spoléhá na lokální instalaci Java SOUVISEJÍCÍ: Minecraft již nikdy nepotřebuje Java; Je čas na odinstalování Java Dnes se podíváme na dva způsoby, jak přeměnit zážitek Minecraft na přenosný počítač, který vám umožní nejen zaparkovat Minecraft a všechna data Minecraft na vyměnitelném disku, ale i když nejste aby jste si je mohli vzít na cestu s flashovým zařízením, abyste mohli jednoduše zálohovat a obnovit celý zážitek z Minecraft, protože všechny soubory jsou obsaženy v jednom adresáři.

(how-to)