S dotazi nás neváhejte kontaktovat: (420) 777 849 161 - Email info@vyroba-webu.cz

Kategorie zranitelnosti

Následuje slíbený seznam kategorií zranitelností, který průběžně doplňuji při zkoušení různých SAST nástrojů. Pokud vás zajímá, jak vypadají konkrétní výsledky pro nějaký zdrojový kód, podívejte se do sekce “Příklady”. Tento seznam obsahuje pokud možno pouze generický popis problému a vysvětlení + nějaké obecně platné rady. Průběžně jej rozšiřuji o nové typy, tudíž se můžete těšit na další záznamy ;).

SQL Injection

SQL injekce může způsobit ztrátu dat, jejich změnu (inkonzistenci), vyzrazení citlivých údajů jako jsou hesla, šifrovací klíče, personální data, nedostupnost databáze nebo celé aplikace, případně může dojít ke kompletnímu ovládnutí systému.

Příčina problému

SQL injection je způsobená použitím neošetřených dat na vstupu, které jsou následně použité bez úpravy v SQL výrazu.

Příklad zneužití:

SQL query:

“SELECT * FROM accounts WHERE custID='” + request.getParameter(“id”) + “‘”;

V takovém případe útočník modifikuje tuto query tak, že použije booleanovský výraz: http://example.com/app/accountView?id=‘ or ‘1’=’1, který způsobí, že SQL databáze vyhodnotí takový požadavek vždy jako platný.

Pokud je tímto způsobem například chráněný přístup pomocí přihlašovacího loginu, tak útočník tímto způsob dané omezení obejde.

Pomocí SQL injection je možné nejenom data získat, ale je i měnit nebo mazat, pokud se zranitelná hodnota nachází v SQL výrazech jako jsou INSERT, UPDATE nebo DELETE apod.

Doporučení k nápravě problému

Java: Chránit aplikaci před SQL injection je v jazyce Java možné pomocí tzv. “Prepared statement” PDO

Příklad:

String custname = request.getParameter(“name”); 

String query = “SELECT * FROM user_data WHERE user_name = ? “;

PreparedStatement pstmt = connection.prepareStatement( query );

pstmt.setString( 1, name); 

ResultSet results = pstmt.executeQuery( );

PHP: V jazyku PHP je možné aplikaci chránit před SQL injection pomocí tzv. “Prepared statement” PDO. Další možností je použít funkci mysql_real_escape_string(), ale tato funkce má limitované použití pouze pro databázi MYSQL nebo MariaDB.

ASP.NET: Pro platformu ASP.NET je možné použít postup na URL SQL injection prevention

 

XSS – Cross Site Scripting

Útočník by mohl pomocí sociálního inženýrství způsobit, že uživatel odešle vstup vytvořený pomocí webových

stránek, přepíše webové stránky a vloží škodlivé skripty. Útočník pak může předstírat, že jde o původní web,

který by útočníkovi umožnil ukrást heslo uživatele, vyžádat si informace o kreditní kartě uživatele, poskytnout

nepravdivé informace nebo spustit malware. Z pohledu oběti se jedná o původní web a oběť by vinila stránky

za způsobenou škodu.

Příčina problému

Aplikace vytváří webové stránky, které obsahují data z předchozího zadání uživatele. Vstup uživatele je vložen pří mo do HTML stránky, což způsobí, že jej prohlížeč zobrazí jako součást webové stránky. Pokud vstup obsahuje frag menty HTML nebo JavaScript, zobrazí se také tyto a uživatel nemůže říct, že se nejedná o zamýšlenou stránku. Tato chyba zabezpečení je výsledkem vložení libovolného uživatelského vstupu, aniž by jej nejprve kódovala do formátu, který by zabránil prohlížeči, aby s ním zacházel jako s HTML/JS místo prostého textu.

Doporučení k nápravě problému

  1. Validovat a sanitizovat veškeré vstupy bez ohledu na zdroj. Validace by měla být založena na white-listingu, akceptovat pouze známé cookies s daným datovým typem. Je třeba kontrolovat: typ, velikost, rozsah, formát, očekávané hodnoty.
    2. Veškerá dynamická data příslušně zaenkódovat, pokud jsou součástí výstupu. Encoding by měl být citlivý na kontext, např. HTML encoding pro HTML data, encoding HTML atributů pro výstup do hodnot atributů a nebo JavaScript pro serverem generovaný kód.
    3. Zvažte užití knihovny ESAPI nebo vestavěné funkce platformy.
    4. V HTTP hlavičce Content-Type explicitně definujte kódovaní znaků pro celou stránku.
    5. V session cookie nastavte příznak httpOnly, abyste zamezili zneužití ukradené cookie.

 

Use of a One Way Hash without a Salt

Pokud útočník získá přístup k haši hesla, pravděpodobně bude moci kvůli této slabosti prolomit haš a uhádnout

původní heslo. Jakmile jsou hesla objevena, může útočník předstírat identitu uživatelů a plně využívat

jejich oprávnění a přistupovat k jejich osobním údajům. Navíc by to pravděpodobně nebylo odhaleno, protože

útočník je identifikován pouze na základě pověření oběti.

Příčina problému

Typické kryptografické hašovací funkce, jako jsou SHA-1 a MD5, jsou neuvěřitelně rychlé. V kombinaci s technikami

útoku, jako jsou předběžné tabulky Rainbow Tables, je pro útočníky relativně snadné prolomit haš

a objevit původní hesla. Chybějící jedinečná náhodná sůl přidaná do hesla činí útoky hrubou silou ještě jednodušší.

Doporučení k nápravě problému

  • Vždy používejte silné, moderní algoritmy pro šifrování, hašování atd.
  • Nepoužívejte slabé, zastaralé nebo zastaralé algoritmy.
  • Ujistěte se, že jste vybrali správný kryptografický mechanismus podle konkrétních požadavků.

Heap Inspection

Všechny proměnné uložené aplikací v nešifrované paměti může potenciálně získat neoprávněný uživatel s privilegovaným

přístupem ke stroji. Například privilegovaný útočník by mohl ke spuštěnému procesu připojit ladicí

program nebo načíst paměť procesu ze souboru swapfile nebo dump crash. Jakmile útočník najde uživatelská

hesla v paměti, lze je znovu použít, aby se uživatel snadno mohl vydat do systému.

Kompromitované zařízení může být zranitelné pro několik forem útoku tam, kde mají aplikace a služby privilegovaná práva. Jde o operace jako čtení z a psaní do paměti, přístup ke všem souborům a podobně.

Příčina problému

Proměnné řetězce jsou ve většině jazyků neměnné – jinými slovy, jakmile je proměnná řetězce přiřazena, její hodnota nemůže být změněna ani odstraněna. Tyto řetězce tedy mohou zůstat v paměti, možná na více místech, po dobu neurčitou, dokud ji sběratel odpadu nevybere. Citlivá data, jako jsou hesla, zůstanou v paměti exponována jako prostý text bez kontroly nad jejich životností.

 

Doporučení k nápravě problému

Heslo je nutné ihned po použití smazat.

Pokud jde o vyhýbání se inspekci haldy, je důležité si uvědomit, že vzhledem k jakémukoli přístupu ke čtení do

paměti nebo k výpisu paměti aplikace je vždy pravděpodobné, že protivníkovi prozradí některá citlivá data –

tyto návrhy jsou součástí obhajoby – principy hloubky pro ochranu citlivých dat v případech, kdy je takový přístup

ke čtení paměti úspěšně získán. Tato doporučení umožní významné snížení životnosti a vystavení citlivých

dat v paměti; avšak – s dostatečným časem, úsilím a neomezeným přístupem k paměti, jsou doposud

pouze v ochraně citlivých dat používaných aplikací. Jediným způsobem, jak řešit problémy s inspekcí haldy, je

minimalizovat a snížit vystavení dat a zakrýt je v paměti, kdykoli je to možné.

  • Neuchovávejte citlivá data, jako jsou hesla nebo šifrovací klíče, do paměti v prostém textu.
  • Dávejte přednost použití specializovaných tříd, které ukládají šifrovaná data do paměti, aby bylo zajištěno, že

je nebude možné z paměti triviálně získat.

  • Je-li vyžadováno použití citlivých dat v nezpracované formě, dočasně je uložte do proměnných datových

typů, jako jsou například bajtová pole, aby se snížila čitelnost z paměti, a pak okamžitě vynulujte umístění paměti,

aby se zkrátila doba expozice těchto dat v paměti.

  • Zajistěte, aby se výpisy paměti nevyměňovaly s nedůvěryhodnými stranami, a to i zajištěním všech výše

uvedených – stále může být možné prolomit šifrované kontejnery zpětným inženýrstvím nebo načíst bajty

citlivých dat z paměti a znovu je sestavit.

  • V Javě neukládejte hesla do neměnných řetězců – raději použijte šifrovaný paměťový objekt, SealedObject.

 

Code Injection

Útočník by mohl na hostitelském serveru spustit libovolný kód. V závislosti na oprávnění operačního systému apli kace mohou zahrnovat: 

  • Přístup k databázi, jako je čtení nebo úprava citlivých dat; 
  • Akce souborů (čtení / vytvoření / úprava / odstranění); 
  • Změna webové stránky; 
  • Otevření síťové připojení k serveru útočníka; 
  • Spuštění a zastavení systémových služeb; 
  • Kompletní převzetí serveru. 

Útočník by pomocí technik sociálního inženýrství přesvědčil oběť, aby použila kód útočníka, a to buď prostřednic tvím chybného odkazu nebo jinak (podvržením QR kódu pro aktivaci aplikace). To umožní útočníkovi získat kontrolu nad uživatelskou zkušeností s webovou aplikací, únos prohlížeče, změnu zobrazené

Příčina problému

Aplikace provádí nějakou akci vytvořením a spuštěním kódu, který obsahuje nedůvěryhodná data, která mohou být pod kontrolou nebezpečného uživatele. Pokud data obsahují škodlivý kód, mohl by vykonaný kód obsahovat čin nosti na úrovni systému navržené útočníkem, jako by útočník spustil kód přímo na aplikačním serveru.

Doporučení k nápravě problému

  • Aplikace by neměla kompilovat, spouštět ani vyhodnocovat žádný nedůvěryhodný kód z jakéhokoli externího zdroje, včetně vstupu uživatele, nahraných souborů nebo databáze.
  • Pokud je absolutně nezbytné zahrnout externí data do dynamického spouštění, je možné předat data jako parametry do kódu, ale uživatelská data nevykonávat přímo.
  • Pokud je nutné předat nedůvěryhodná data, vynucujte velmi přísné ověřování dat. Například přijímejte pouze celá čísla mezi určitými hodnotami.
  • Ověření všech vstupů bez ohledu na zdroj. Ověření by mělo být založeno na číselníku platných hodnot – spíše než odmítat špatné vzory je vhodné přijímat pouze data odpovídající dané struktuře. Parametry by měly být omezeny na povolenou znakovou sadu a neověřený vstup by měl být zrušen. Kromě znaků kontrolujte:
  • Typ dat, velikost, rozsah, formát, očekávané hodnoty.
  • Pokud je to možné, raději místo porovnání s blacklistem (seznamem nepovolených hodnot) vždy upřednostňujte důvěryhodný vstup.
  • Nakonfigurujte aplikaci tak, aby se spouštěla pomocí omezeného uživatelského účtu, který nemá zbytečná oprávnění.
  • Pokud je to možné, izolujte veškeré dynamické spouštění tak, aby používal samostatný vyhrazený uživatelský účet, který má oprávnění pouze pro specifické operace a soubory používané při dynamickém spouštění, v souladu se zásadou nejmenšího oprávnění.
  • Na straně klienta nepoužívejte žádnou formu vyhodnocení dynamického kódu s nedůvěryhodnými daty. Dynamické vyhodnocení je povoleno pouze u pevně kódovaných příkazů.

 

Missing HSTS header

Pokud nenastavíte záhlaví HSTS a neposkytnete mu přiměřenou maximální trvanlivost alespoň jednoho roku,

mohou být uživatelé zranitelní útoky typu Man-in-the-Middle.

Příčina problému

Mnoho uživatelů přejde na webové stránky jednoduše zadáním názvu domény do adresního řádku bez předpony

protokolu. Prohlížeč automaticky předpokládá, že zamýšleným protokolem uživatele je HTTP, namísto

šifrovaného protokolu HTTPS.

Po podání této počáteční žádosti může útočník provést útok typu Man-in-the-Middle a manipulovat s ním

tak, aby přesměroval uživatele na nebezpečný web, který si útočník zvolí. Z důvodu ochrany uživatele před

takovým výskytem vydává záhlaví HTTP Strict Transport Security (HSTS) prohlížeč uživatele pokyn, aby zakázal

použití nezabezpečeného připojení HTTP k doméně spojené s hlavičkou HSTS.

Jakmile prohlížeč, který podporuje funkci HSTS, navštívil web a byla nastavena záhlaví, již nebude umožňovat

komunikaci s doménou přes připojení HTTP.

Doporučení k nápravě problému

Před nastavením záhlaví HSTS – zvažte důsledky, které může mít:

  • Vynucení HTTPS zabrání jakémukoli budoucímu použití HTTP, což by mohlo bránit některému testování
  • Zakázání HSTS není triviální – jakmile je na webu deaktivováno, musí být také deaktivováno v prohlížeči

Nastavte záhlaví HSTS buď explicitně v kódu aplikace, nebo pomocí konfigurací webového serveru.

Ujistěte se, že hodnota „max-age“ pro záhlaví HSTS je nastavena na 31536000, aby bylo zajištěno, že HSTS

bude přísně vynucováno po dobu alespoň jednoho roku.

 

Deserialization of Untrusted Data

Deserializace nedůvěryhodných dat může útočníkům umožnit vložení nebezpečného kódu. Když je nebezpečný objekt

nezajištěně deserializován, může to mít za následek provedení příkazů v kódu nebo operačním systému vyvoláním tříd a metod,

které jsou pro objekt dostupné během deserializace. Navíc je možné obejít logické ověření objektu v konstruktorech a setterech,

což umožňuje k deserializaci nezkontrolovaného, vadného nebo škodlivého objektu.

Příčina problému

Serializace a deserializace (maršálování) je nedílnou součástí procesu vzdáleného zpracování dat, kdy jsou objekty předávány mezi instancemi procesů prostřednictvím nějakého média, jako je například síť. Během deserializace se vytváří zcela nový objekt ze serializovaného objektu poskytovaného přes vstupní médium; pokud je však deserializvaný objekt nedůvěryhodný, může být podvržen neočekávaný a potenciálně nebezpečný obsah.

Doporučení k nápravě problému

Kontrolovat strukturu souboru a povolené hodnoty, zakázat parsování externích entit u XML

 

Mezi vzdálenými instancemi předávat místo celého serializovaného pouze primitiva a objekt znovu sestavit.

  • Pokud to nejde jinak, použijte whitelist. Předaný objekt musí být známý, důvěryhodný, v danou chvíli očekávaný a nesmí obsahovat jiné nedůvěryhodné objekty.

 

Privacy Violation

Programátor nebo útočník může získat přístup k osobním údajům.

Příčina problému

Aplikace odešle informace o uživateli, jako jsou hesla, informace o účtu nebo čísla kreditních karet, mimo aplikaci –

například provede zápis do místního textového nebo logovacího souboru nebo je odešle externí webové službě.

Doporučení k nápravě problému

  1. Před zápisem do protokolů nebo jiných souborů by měly být odstraněny osobní údaje.
  2. Zkontrolujte potřebu a zdůvodnění zasílání osobních údajů do vzdálených webových služeb.

 

Use of Insufficiently Random Values

https://cwe.mitre.org/data/definitions/330.html

Pokud aplikace používá generované pseudonáhodné hodnoty pro citlivé údaje nebo aplikační procesy, jako je například šifrování, může útočník tuto situaci zneužít ve svůj prospěch, kdy se bude pokoušet tyto pseudonáhodné hodnoty uhodnout.

Příčina problému

Pokud je v kódu použitá třída Random() a některé z volání jako: nextBytes(), nextLong(), nextInt(), tak tato třída negeneruje pomocí těchto metod dostatečně náhodné hodnoty. V případě, kdy jsou takto získané hodnoty následně použité hrozí riziko, že budou tyto hodnoty později uhodnuty.

Doporučení k nápravě problému

V jazyce Java je možné volat třídu SecureRandom(), která generuje pseudonáhodné hodnoty s větší entropií. Příklad:

SecureRandom sr = new SecureRandom();  

byte[] rndBytes = new byte[12]; 

sr.nextBytes(rndBytes); 

 

Trust Boundary Violation

Vývojáři aplikací mohou s uživatelským vstupem zacházet jako s důvěryhodnými daty a potenciálně tak vytvářet

zranitelnost založenou na vstupu, jako je SQL Injection nebo Cross-Site Scripting.

Příčina problému

Aplikace umístí vstup uživatele, což jsou nedůvěryhodná data, do složky Session na straně serveru, která je

považována za důvěryhodné umístění. To by mohlo vést vývojáře k tomu, aby nedůvěryhodná data považovali

za důvěryhodná.

Doporučení k nápravě problému

Validovat a sanitizovat veškeré vstupy bez ohledu na zdroj. Validace by měla být založena na white-listingu, akceptovat pouze známé cookies s daným datovým typem. Je třeba kontrolovat: typ, velikost, rozsah, formát, očekávané hodnoty.

 

Frameable Login Page / Missing X-Frame Options

Příčina problému

Aplikace nepouživá X-FRAME-OPTIONS pro zamezení vložení stránky do cizího obsahu.

Doporučení k nápravě problému

X-Frame-Options: SAMEORIGIN nebo X-Frame-Options: ALLOW-FROM https://example.com/”

 

Information Exposure through Error Message

Aplikace zobrazuje výjimky uživateli; dochází k úniku interních informací prostřednictvím chybových hlášení.

Z tohoto důvodu je nutné výjimky ošetřit a nikdy jejich obsah nevypisovat na aplikační výstup.

Doporučení k nápravě problému

Výjimky se nemají vypisovat do stránky uživateli, ale do provozního logu.

 

Cleartext submission of Sensitive Information

Jedná se o problém, kdy jsou data přenášena v nezašifrované podobě.

 

Doporučení k nápravě problému

Používat HTTPS, parametry odesílat v POST body, nikoliv jako GET parametr.

 

Missing Content Security Policy

V rámci webové aplikace není explicitně definováno Content Security Policy.

 

Doporučení k nápravě problému

Viz https://www.owasp.org/index.php/Content_Security_Policy

 

httpOnly cookie

Aplikace vytváří cookies a vrací jej v odpovědi, ale chybí příznak httpOnly.

 

Příčina problému

Pokud cookie neobsahuje příznak httpOnly je její hodnota přístupná pro skriptovací jazyky (Javascript, VBScript, ActionScript), a útočník může tuto situaci zneužít v případě, kdy se mu podaří vložit do cílové aplikace svůj škodlivý kód.

 

Doporučení k nápravě problému

V session cookie nastavte příznak httpOnly, abyste zamezili zneužití ukradené cookie.

 

Unchecked Input for Loop Condition

Útočník by mohl vložit velmi vysokou hodnotu a potenciálně způsobit odmítnutí služby (DoS).

Příčina problému

Aplikace provádí opakující se úlohu ve smyčce a definuje, kolikrát se má smyčka provést podle vstupu uživatele.

Velmi vysoká hodnota může způsobit, že se aplikace zasekne ve smyčce a nebude moci pokračovat v dalších

operacích..

Doporučení k nápravě problému

V ideálním případě nezakládejte smyčku na datech poskytovaných uživatelem. Je-li to nutné, musí být nejprve

ověřen vstup uživatele a jeho rozsah by měl být omezen.

 

About fotodobias