9 Populární typy útoků vstřikování webové aplikace

Problém s webovými aplikacemi spočívá v tom, že jsou otevřeně vystaveny miliardám uživatelů internetu, z nichž mnozí budou chtít porušit svá bezpečnostní opatření – z jakýchkoli důvodů.


V prvních dnech internetu byla jednou z nejčastějších metod útoku základní jednoduchá síla brutální. Bots tyto útoky obvykle prováděli – nebo u osob se spoustou volna -, kteří vyzkoušeli zilliony kombinací uživatelských jmen a hesel, dokud nenalezly ten, který by udělil přístup k cílové aplikaci..

Útoky hrubou silou již nejsou hrozbou, a to díky zásadám pro hesla, omezeným pokusům o přihlášení a captchas. Počítačoví zločinci však rádi objevují nové vykořisťování a používají je k provádění nových typů útoků. Už dávno zjistili, že textová pole na aplikacích nebo na webových stránkách mohou být využita tak, že do nich zadáte – nebo vstříknete – neočekávaný text, který nutí aplikaci udělat něco, co by nemělo dělat. Tímto způsobem vstoupily na scénu tzv. Injekční útoky.

Injekční útoky lze použít nejen k přihlášení k aplikaci 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 tyto útoky nejsou pouze hrozbou pro webové aplikace, ale také pro uživatele, jejichž data jsou uložena v těchto aplikacích a v nejhorších případech i pro další připojené aplikace a služby..

Vložení kódu

Injekce kódu je jedním z nejčastějších typů injekčních útoků. Pokud útočníci znají programovací jazyk, rámec, databázi nebo operační systém používaný webovou aplikací, mohou vložit kód pomocí polí pro zadávání textu, aby donutili webový server dělat, co chtějí..

Tyto typy injekčních útoků jsou možné u aplikací, u nichž chybí ověření vstupních dat. Pokud pole pro zadávání textu umožňuje uživatelům zadat, co chtějí, je aplikace potenciálně využitelná. Aby se těmto útokům zabránilo, musí aplikace omezit na maximální možnou míru vstupy, kterým mohou uživatelé vstupovat.

Například je třeba omezit množství očekávaných dat, zkontrolovat formát dat před jejich přijetím a omezit sadu povolených znaků.

Zranitelnosti kódu lze snadno najít pouhým testováním textového vstupu webové aplikace s různými typy obsahu. Pokud jsou chyby zjištěny, je obtížné je zneužít. Pokud se však útočníkovi podaří zneužít jednu z těchto chyb zabezpečení, může to mít za následek ztrátu důvěrnosti, integrity, dostupnosti nebo funkčnosti aplikace..

SQL injekce

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

PHP a ASP aplikace jsou náchylné k SQL injekčním útokům kvůli starším funkčním rozhraním. Před těmito útoky jsou obvykle chráněny aplikace J2EE a ASP.Net. Pokud bude nalezena zranitelnost s injekcí SQL – a lze je snadno najít – velikost potenciálních útoků bude omezena pouze dovedností a představivostí útočníka. Dopad SQL injekčního útoku je tedy nepochybně vysoký.

Příkazová injekce

Tyto útoky jsou také možné, hlavně kvůli nedostatečné validaci vstupů. Liší se od útoků na vstřikování kódu tím, že útočník vkládá systémové příkazy místo kusů programovacího kódu nebo skriptů. Hacker proto nemusí znát programovací jazyk, ve kterém je aplikace založena, ani jazyk používaný v databázi. Potřebují však znát operační systém používaný hostitelským serverem.

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

Těmto útokům může zabránit systémový administrátor tím, že omezí úroveň přístupu k systému webových aplikací spuštěných na serveru.

Cross-site skriptování

Kdykoli aplikace vloží vstup od uživatele do výstupu, který generuje, bez ověření nebo kódování, dává útočníkovi příležitost poslat škodlivý kód jinému koncovému uživateli. Útoky typu cross-site Scripting (XSS) využívají tyto příležitosti k vložení škodlivých skriptů na důvěryhodné weby, které jsou nakonec zasílány dalším uživatelům aplikace, které se stávají oběťmi útočníka.

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

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

v uložené Útoky XSS, škodlivý skript je trvale umístěn na cílovém serveru, ve fóru zpráv, v databázi, v protokolu návštěv atd. Oběť jej dostane, když jeho prohlížeč požaduje uložené informace. v odráží Útoky XSS, škodlivý skript se projeví v odezvě, která zahrnuje vstup odeslaný na server. Může to být například chybová zpráva nebo výsledek vyhledávání.

XPath injekce

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

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

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

Pošta příkazového injekce

Tuto metodu útoku lze využít k využívání e-mailových serverů a aplikací, které vytvářejí příkazy IMAP nebo SMTP s nesprávně ověřeným vstupem uživatele. Servery IMAP a SMTP občas nemají silnou ochranu proti útokům, jako by tomu bylo u většiny webových serverů, a proto by mohly být více využ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 útočníci mohli využívat server SMTP, potřebují platný e-mailový účet k odesílání zpráv pomocí příkazů injektovaných. Pokud je server zranitelný, bude reagovat na požadavky útočníků, což jim umožní například potlačit omezení serveru a používat jeho služby k odesílání spamu.

Injekci IMAP lze provádět hlavně na webových poštovních aplikacích využívajících funkce čtení zpráv. V těchto případech lze útok provést jednoduše tak, že do adresního řádku webového prohlížeče zadáte adresu URL s injikovanými příkazy..

Injekce CRLF

Vložení znaku návratu vozíku a posunu řádku – kombinace známé jako CRLF – do vstupních polí webového formuláře představuje metodu útoku nazvanou injekce CRLF. 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..

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

Tento útok lze provést na zranitelných webových aplikacích, které na vstup uživatele nepoužívají správné filtrování. Tato chyba zabezpečení otevírá dveře dalším typům útoků typu injekce, jako je XSS a vstřikování kódu, a mohla by se také odvodit z únosu webových stránek..

Injekce hlavičky hostitele

Na serverech, které hostují mnoho webových stránek nebo webových aplikací, se záhlaví hostitele stane nezbytným k určení toho, který z rezidentních webů nebo webových aplikací – z nichž je znám jako virtuální hostitel -, by měl zpracovat příchozí požadavek. Hodnota záhlaví říká serveru, kterému z virtuálních hostitelů 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 záhlaví hostitele prvnímu virtuálnímu hostiteli na serveru.

Manipulace s hlavičkou hostitele běžně souvisí s PHP aplikacemi, ačkoli to lze také provést pomocí jiných technologií pro vývoj webových aplikací. Útoky hlavičky hostitele fungují jako aktivátory pro další typy útoků, jako je například otrava webovou mezipamětí. 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ů, ostatních uživatelů) v síti. Je velmi užitečný pro intranety a pokud je použit jako součást systému jednotného přihlášení, lze jej použít k ukládání uživatelských jmen a hesel. Dotazy LDAP zahrnují použití speciálních ovládací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 kontrolní znaky.

Kořenovým problémem, který umožňuje útoky injekcí LDAP, je opět nesprávně ověřený vstup uživatele. Pokud je text, který uživatel odešle do aplikace, použit jako součást dotazu LDAP, aniž by jej dezinfikoval, mohl by dotaz skončit načtením seznamu všech uživatelů a jeho ukázáním útočníkovi pouhým použitím hvězdičky (*) vpravo místo uvnitř vstupního řetězce.

Prevence injekčních útoků

Jak jsme viděli v tomto článku, všechny útoky injekcí jsou směrovány na servery a aplikace s otevřeným přístupem k libovolnému uživateli internetu. Odpovědnost za prevenci těchto útoků je rozdělena mezi vývojáře aplikací a správce serverů.

Vývojáři aplikací musí znát rizika spojená s nesprávnou validací vstupu uživatele a naučit se osvědčené postupy pro dezinfekci vstupu uživatele za účelem prevence rizik. Správci serverů musí pravidelně auditovat své systémy, aby zjistili zranitelnosti a opravili je co nejdříve. Existuje mnoho možností provedení těchto auditů, buď na vyžádání, nebo automaticky.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map