9 Populárních typů injekcí webových aplikací

Problém s webovými aplikacemi je, že jsou otevřeně vystaveny miliardám uživatelů internetu, z nichž mnozí budou chtít prolomit jeho bezpečnostní opatření – ať už jsou důvody jakékoli.

V počátcích internetu byla jednou z nejběžnějších metod útoku základní, jednoduchá hrubá síla. Tyto útoky obvykle prováděli boti – nebo osoby s dostatkem volna –, kteří zkoušeli miliony kombinací uživatelských jmen a hesel, dokud nenašli takové, které by umožňovalo přístup k cílové aplikaci.

Útoky hrubou silou již nejsou hrozbou díky zásadám hesel, omezeným pokusům o přihlášení a captcha. Ale kyberzločinci rádi objevují nové exploity a používají je k provádění nových typů útoků. Před dlouhou dobou zjistili, že textová pole v aplikacích nebo webových stránkách mohou být zneužita tak, že do nich zadáte – nebo vložíte – neočekávaný text, který by aplikaci donutil udělat něco, co dělat neměla. Na scénu tak vstoupily takzvané injekční útoky.

Injekční útoky lze použít nejen k přihlášení do aplikace bez znalosti uživatelského jména a hesla, ale také k odhalení soukromých, důvěrných nebo citlivých informací nebo dokonce k únosu celého serveru. Proto jsou tyto útoky hrozbou nejen pro webové aplikace, ale také pro uživatele, jejichž data se v těchto aplikacích nacházejí, a v nejhorších případech i pro další připojené aplikace a služby.

Vložení kódu

Vkládání kódu je jedním z nejběžnějších typů útoků vstřikováním. Pokud útočníci znají programovací jazyk, framework, databázi nebo operační systém používaný webovou aplikací, mohou vložit kód pomocí textových vstupních polí, aby přinutili webový server dělat, co chtějí.

Tyto typy injekčních útoků jsou možné u aplikací, kterým chybí ověření vstupních dat. Pokud textové vstupní pole umožňuje uživatelům zadat, co chtějí, pak je aplikace potenciálně zneužitelná. Aby se těmto útokům zabránilo, musí aplikace co nejvíce omezit vstup, který mohou uživatelé vstupovat.

Potřebuje například omezit množství očekávaných dat, zkontrolovat formát dat před jejich přijetím a omezit množinu povolených znaků.

Chyby zabezpečení vkládání kódu lze snadno najít, stačí otestovat textový vstup webové aplikace s různými typy obsahu. Když jsou zranitelnosti nalezeny, je středně těžké zneužít. Ale když se útočníkovi podaří zneužít jednu z těchto zranitelností, dopad může zahrnovat ztrátu důvěrnosti, integrity, dostupnosti nebo funkčnosti aplikace.

  11 Co dělat a co nedělat při výběru správného tématu WordPress

SQL injekce

Podobným způsobem jako vkládání kódu tento útok vkládá skript SQL – jazyk používaný většinou databází k provádění dotazovacích operací – do pole pro zadávání textu. Skript je odeslán do aplikace, která jej spustí přímo ve své databázi. V důsledku toho by útočník mohl projít přihlašovací obrazovkou nebo provádět nebezpečnější věci, jako je číst citlivá data přímo z databáze, upravovat nebo ničit databázová data nebo provádět v databázi operace správce.

Aplikace PHP a ASP jsou náchylné k útokům SQL injection kvůli svým starším funkčním rozhraním. Aplikace J2EE a ASP.Net jsou proti těmto útokům obvykle více chráněny. Když je nalezena zranitelnost SQL injection – a ta by mohla být snadno nalezena – velikost potenciálních útoků bude omezena pouze dovedností a představivostí útočníka. Dopad útoku SQL injection je tedy nepochybně vysoký.

Příkazová injekce

Tyto útoky jsou také možné, především kvůli nedostatečné validaci vstupu. Liší se od útoků vkládáním kódu v tom, že útočník vkládá systémové příkazy namísto částí programovacího kódu nebo skriptů. Hacker tedy nemusí znát programovací jazyk, ve kterém je aplikace založena, ani jazyk používaný databází. Musí však znát operační systém používaný hostitelským serverem.

Vložené systémové příkazy jsou vykonávány hostitelským operačním systémem s oprávněními aplikace, což by mohlo mimo jiné umožnit zpřístupnění obsahu libovolných souborů umístěných na serveru, zobrazení adresářové struktury serveru, změnu uživatelských hesel. .

Těmto útokům může zabránit správce systému tím, že omezí úroveň přístupu k systému webových aplikací běžících na serveru.

Skriptování napříč weby

Kdykoli aplikace vloží vstup od uživatele do výstupu, který generuje, aniž by jej ověřovala nebo kódovala, dává útočníkovi příležitost odeslat škodlivý kód jinému koncovému uživateli. Útoky Cross-Site Scripting (XSS) využívají těchto příležitostí k vkládání škodlivých skriptů do důvěryhodných webových stránek, které jsou nakonec odesílány dalším uživatelům aplikace, kteří se stávají obětí útočníka.

Prohlížeč obětí spustí škodlivý skript, aniž by věděl, že by se mu nemělo věřit. Proto mu prohlížeč umožní přístup k tokenům relace, souborům cookie nebo citlivým informacím uloženým v prohlížeči. Pokud jsou správně naprogramovány, skripty by mohly dokonce přepsat obsah souboru HTML.

XSS útoky lze obecně rozdělit do dvou různých kategorií: uložené a odražené.

V uložených útocích XSS je škodlivý skript trvale umístěn na cílovém serveru, ve fóru zpráv, v databázi, v protokolu návštěvníků atd. Oběť jej získá, když si její prohlížeč vyžádá uložené informace. V odražených útocích XSS se škodlivý skript projeví v odpovědi, která obsahuje vstup odeslaný na server. Může to být například chybová zpráva nebo výsledek hledání.

  Jak spravovat data, která o vás LinkedIn shromažďuje

Injekce XPath

Tento typ útoku je možný, když webová aplikace používá informace poskytnuté uživatelem k vytvoření dotazu XPath na data XML. Způsob, jakým tyto útoky fungují, je podobný SQL injection: útočníci odesílají do aplikace chybné informace, aby zjistili, jak jsou XML data strukturována, a poté znovu zaútočí, aby se k těmto datům dostali.

XPath je standardní jazyk, pomocí kterého můžete, stejně jako SQL, zadat atributy, které chcete najít. K provedení dotazu na data XML používají webové aplikace uživatelský vstup k nastavení vzoru, kterému by se data měla shodovat. Odesláním chybně tvarovaného vstupu se vzor může proměnit v operaci, kterou chce útočník použít na data.

Na rozdíl od toho, co se děje s SQL, v XPath neexistují žádné různé verze. To znamená, že vkládání XPath lze provést v jakékoli webové aplikaci, která používá data XML, bez ohledu na implementaci. To také znamená, že útok může být automatizován; proto, na rozdíl od SQL injection, má potenciál být vystřelen proti libovolnému počtu cílů.

Vložení příkazu pošty

Tuto metodu útoku lze použít ke zneužití e-mailových serverů a aplikací, které vytvářejí příkazy IMAP nebo SMTP s nesprávně ověřeným uživatelským vstupem. Servery IMAP a SMTP občas nemají silnou ochranu proti útokům, jak by tomu bylo u většiny webových serverů, a proto by mohly být více zneužitelné. Při vstupu přes poštovní server by se útočníci mohli vyhnout omezením, jako jsou captchas, omezený počet požadavků atd.

Aby mohli útočníci zneužít SMTP server, potřebují platný e-mailový účet k odesílání zpráv s vloženými příkazy. Pokud je server zranitelný, bude reagovat na požadavky útočníků a umožní jim například přepsat omezení serveru a využívat jeho služby k rozesílání spamu.

Injekce IMAP by mohla být prováděna hlavně v aplikacích webové pošty s využitím funkce čtení zpráv. V těchto případech lze útok provést jednoduchým zadáním adresy URL s vloženými příkazy do adresního řádku webového prohlížeče.

Injekce CRLF

Vkládání znaků pro návrat vozíku a odřádkování – kombinace známá jako CRLF – do vstupních polí webového formuláře představuje metodu útoku zvanou CRLF injection. Tyto neviditelné znaky označují konec řádku nebo konec příkazu v mnoha tradičních internetových protokolech, jako je HTTP, MIME nebo NNTP.

  15 úžasných pluginů WP Block Editor pro vytvoření krásné stránky

Například vložení CRLF do požadavku HTTP, po kterém následuje určitý HTML kód, by mohlo návštěvníkům webu poslat vlastní webové stránky.

Tento útok lze provést na zranitelné webové aplikace, které na vstup uživatele neaplikují správné filtrování. Tato chyba zabezpečení otevírá dveře dalším typům injektážních útoků, jako je XSS a vkládání kódu, a mohla by také pocházet z ukradených webových stránek.

Vložení hlavičky hostitele

Na serverech, které hostují mnoho webových stránek nebo webových aplikací, je hlavička hostitele nezbytná k určení, které z rezidentních webových stránek nebo webových aplikací – každá z nich známá jako virtuální hostitel – by měla zpracovat příchozí požadavek. Hodnota hlavičky sděluje serveru, kterému z virtuálních hostitelů má odeslat požadavek. Když server obdrží neplatnou hlavičku hostitele, obvykle ji předá prvnímu virtuálnímu hostiteli v seznamu. To představuje chybu zabezpečení, kterou mohou útočníci použít k odeslání libovolných hlaviček hostitele prvnímu virtuálnímu hostiteli na serveru.

Manipulace s hlavičkou hostitele běžně souvisí s aplikacemi PHP, i když ji lze provést i pomocí jiných technologií vývoje webu. Útoky hlavičky hostitele fungují jako aktivátory jiných typů útoků, jako je otrava webové mezipaměti. Jeho důsledky by mohly zahrnovat provádění citlivých operací útočníky, například resetování hesla.

Injekce LDAP

LDAP je protokol určený k usnadnění vyhledávání zdrojů (zařízení, souborů, jiných uživatelů) v síti. Je velmi užitečný pro intranet, a když se používá jako součást systému jednotného přihlašování, lze jej použít k ukládání uživatelských jmen a hesel. Dotazy LDAP zahrnují použití speciálních řídicích znaků, které ovlivňují jeho ovládání. Útočníci mohou potenciálně změnit zamýšlené chování dotazu LDAP, pokud do něj mohou vložit řídicí znaky.

Opět platí, že hlavním problémem, který umožňuje útoky injekce LDAP, je nesprávně ověřený uživatelský vstup. Pokud je text, který uživatel odešle aplikaci, použit jako součást dotazu LDAP, aniž by byl dezinfikován, dotaz by mohl skončit načtením seznamu všech uživatelů a jeho zobrazením útočníkovi, pouze pomocí hvězdičky.

na správném místě uvnitř vstupního řetězce.

Prevence injekčních útoků

Jak jsme viděli v tomto článku, všechny injekční útoky směřují na servery a aplikace s otevřeným přístupem pro kteréhokoli uživatele internetu. Odpovědnost za předcházení těmto útokům je rozdělena mezi vývojáře aplikací a správce serverů.

Vývojáři aplikací potřebují znát rizika spojená s nesprávným ověřením uživatelských vstupů a naučit se osvědčené postupy pro dezinfekci uživatelských vstupů za účelem prevence rizik. Správci serverů potřebují pravidelně kontrolovat své systémy, aby odhalili zranitelnosti a co nejdříve je opravili. Existuje mnoho možností, jak tyto audity provádět, buď na vyžádání, nebo automaticky.