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

Enduro.js

Dnes si zkusíme otestovat nějaký menší projekt v Javasriptu. Konkrétně malou knihovnu pro CMS nad Node.js, Enduro. Abychom nemuseli mít dilema, zda zakládat tikety pro vývojáře dané aplikace a jednalo se pouze o ukázku, otestujeme nějakou starší verzi. Vybral jsem verzi 1.4.20. Každý si jako vždy můžete tento kód zkusit otestovat vaším nástroje, tato verze je k dispozici zde:

https://github.com/Gottwik/Enduro/archive/1.4.20.zip

Prohnal jsem aplikaci SAST nástrojem (jako vždy neuvádím kterým, nechávám na fantazii čtenářů). Níže je přehled nálezů z krátkým popisem jak by mělo/mohlo vypadat vyhodnocení takových nálezů:

Reflected XSS

V souboru get_cms.js

Popis chyby:

Aplikace ziskává data z položky req.query.filename. Tato následně neošetřena pluje kódem a je následně použita k sestavení dat zpět uživateli. To může umožnit Cross-Site-Scripting útok.

Doporučení:

  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.

 

Security Misconfiguration

V souboru server.js

Popis chyby:

Aplikace získává sensitivní, personální data, keyboard cat, a ukládá je nebezpečným způsobem, bez šifrování, do session.

Doporučení:

https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A6-Security_Misconfiguration

 

Missing Encryption of Sensitive Data

V souboru trollhunter.js

Popis chyby:

Aplikace ukládá sensitivní personální data nebezpečným způsobem

Doporučení:

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

 

Missing HSTS Header

V souboru login_by_password.js

Popis chyby:

Webová aplikace nedefinuje záhlaví HSTS, takže je náchylná k útoku.

 

Doporučení:

Nastavte Strict-Transport-Security header

 

Unprotected cookie

V souboru ab_tester.js

Popis chyby:

Webová aplikace vytváří cookie ale nestavuje httpOnly atribut.

 

Doporučení:

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

 

Client Insecure Randomness

V souboru admin_security.js

Popis chyby:

Aplikace používá slabou metodu Math.random() ke generování náhodných čísel.

Doporučení:

Nepoužívejte statistický generátor pseudonáhodných čísel, místo toho použijte kryptorandom generátor.

 

Missing CSP Header

V souboru login_by_password.js

Popis chyby:

Chybějící nastavení CSP pro moderní prohlížeče.

Doporučení:

res.setHeader(

‘Content-Security-Policy’,

Jenkins Build Server

Dnes si zkusíme otestovat nějaký větší projekt. Vybral jsem Open-Source build server Jenkins. Abychom nemuseli mít dilema zda zakládat tikety pro vývojáře dané aplikace a jednalo se pouze o ukázku, otestujeme nějakou starší verzi. Vybral jsem verzi 1.649. Každý si jako vždy můžete tento kód zkusit otestovat vaším nástroje, tato verze je k dispozici zde:

https://github.com/jenkinsci/jenkins/releases/tag/jenkins-1.649

Prohnal jsem aplikaci SAST nástrojem (jako vždy neuvádím kterým, nechávám na fantazii čtenářů). Níže je přehled vybraných nálezů z krátkým popisem jak by mělo/mohlo vypadat vyhodnocení takových nálezů:

Code Injection

V Service.java

Popis chyby:

Aplikace spouští nedůvěryhodný kód – instanciace třídy ze souboru podle názvu.

Doporučení:

Jedná se o nález, který je důsledkem open-source pluginové architektury aplikace. Bylo by vhodné zvolit omezení formou whitelistingu, například názvy důvěryhodných tříd. Je třeba nasadit provozní opatření – aplikace by měla být spuštěna pod uživatelem s minimálním oprávněním a mít nakonfigurované role tak, že plug-iny může nasazovat pouze administrátor (ideálně po provedení code-review nebo statického testu).

 

Code Injection

V Service.java (další výskyt)

Popis chyby:

Aplikace spouští nedůvěryhodný kód – instanciace třídy ze souboru.

Doporučení:

Jedná se o nález, který je důsledkem open-source pluginové architektury aplikace. Bylo by vhodné zvolit omezení formou whitelistingu, například názvy důvěryhodných tříd. Je třeba nasadit provozní opatření – aplikace by měla být spuštěna pod uživatelem s minimálním oprávněním a mít nakonfigurované role tak, že plug-iny může nasazovat pouze administrátor (ideálně po provedení code-review nebo statického testu).

 

Stored Code Injection

V PluginManager

Popis chyby:

Metoda createPluginStrategy přijímá a dynamicky spouští uživatelský kód pomocí metody loadClass. To by mohlo umožnit útočníkovi vložit a spustit libovolný kód.
Útočník může kód vložit pomocí standardních textových polí do databáze nebo místního souboru. Tento text je pak načten metodou createPluginStrategy pomocí getProperty a následně odeslán spouštěcí metodě.

 

Doporučení:

Aplikace, která spouští kód třetí strany (pluginy), by měla být spuštěna pod uživatelem s minimálním oprávněním. Pokud je to možné, izolovat veškeré dynamické spouštění do separátního dedikovaného uživatelského účtu, který má oprávnění pouze pro specifické operace a soubory použité pro dynamické spouštění, podle principu nejmenší nutné zodpovědnosti.

 

Stored Code Injection

V Lifecycle.java

Popis chyby:

Metoda get přijímá a dynamicky spouští uživatelský kód pomocí metody loadClass. To by mohlo umožnit útočníkovi vložit a spustit libovolný kód.
Útočník může kód vložit pomocí standardních textových polí do databáze nebo místního souboru. Tento text je pak načten metodou get pomocí getProperty a následně odeslán spouštěcí metodě.

 

Doporučení:

Aplikace, která spouští kód třetí strany, by měla být spuštěna pod uživatelem s minimálním oprávněním. Pokud je to možné, izolovat veškeré dynamické spouštění do separátního dedikovaného uživatelského účtu, který má oprávnění pouze pro specifické operace a soubory použité pro dynamické spouštění, podle principu nejmenší nutné zodpovědnosti.

 

Stored Code Injection

V ConfigFile

Doporučení:
Jelikož se již správně používá whitelist a podepisování tříd nepřipadá v úvahu, riziko je nutné akceptovat (jedná se o základní funkčnost aplikace). Útočník nesmí získat přístup na úrovni file systému.

Stored XSS

V ConfigDirectory.java

Popis chyby:

Metoda load načítá data ze souborů *.conf pomocí funkce readLine. Tato data jsou bez kontroly zobrazena v ConfigFile.java:27. Stav umožňuje podvrhnout škodlivá data v konfiguraci.

 

Doporučení:

Validujte všechny vstupy bez ohledu na zdroj. Validace by měla být založená na whitelistu: namísto odmítání známých chyb akceptujte pouze data, která pasují do specifikované struktury. Kontrolujte datový typ, velikost, rozsah, formát a očekávané hodnoty.
Veškeré dynamické data plně zaenkódujte, před vložením do výstupu. Encoding byl měl být kontextově senzitivní, například:
• HTML encoding pro HTML obsah
• HTML Attribute encoding pro data zapisovaná do hodnot atributů
• JavaScript encoding pro serverem generovaný JavaScript.
Zvažte užití encoding knihovny ESAPI, nebo vestavených funkcí platformy. V hlavičce Content-Type explicitně určete podporované kódování znaků pro celou stránku.
Na session cookie nastavte atribut httpOnly, abyste zamezili zneužití formou XSS při krádeži cookie.

 

Stored XSS

V TcpSlaveAgentListener.java

Popis chyby:

Metoda run ziskava data z db,  pro element readUTF. Tento element prochazi volne kodem aniz by byl validovan a sanitizovan a je zobrazen uzivateli v metode error. To muze umožnit útok typu Stored Cross-Site-Scripting.

 

Doporučení:

Veškeré dynamické data plně zaenkódujte, před vložením do výstupu.

 

Reflected XSS All Clients

V Jenkins.java

Popis chyby:

Metoda doLoginEntry přesměrovává uživatele na jím zadaný parametr “from”; může uživatele přesměrovat na jiné stránky.

 

Doporučení:

Metoda by měla ověřovat parametr “from” a přesměrovávat pouze v rámci domény, ve které aplikace běží.

 

Deserialization of Untrusted Data

Nejčastější chyba v Jenkins. Níže uvádím několik z mnoha výskytů:

ConsoleNote.java

Popis chyby:

Serializovaný objekt buf je deserializován pomocí return (ConsoleNote) ois.readObject(); – není ověřena autentičnost, spoléhá se na casting. Jedná se o parser build-logu, takže veškerá data jsou implicitně nedůvěryhodná.

 

Doporučení:

Pokud je to třeba, využijte whitelist povolených objektů. Vždy se ujistěte, že objekt je známý, očekávaný a důvěryhodný. Nikdy nesestavujte dynamicky objekt, pokud jeho zdroj nebyl verifikován a považován za důvěryhodný a sám neobsahuje žádné nedůvěryhodné objekty.

 

AtomicFileWriter.java

Popis chyby:

Serializovaný objekt tmpFile zpracovaný v AtomicFileWriteru je bez kontroly deserializován pomocí XStream2.unmarshal.

 

Doporučení:

Pokud je to třeba, využijte whitelist povolených objektů. Vždy se ujistěte, že objekt je známý, očekávaný a důvěryhodný. Nikdy nesestavujte dynamicky objekt, pokud jeho zdroj nebyl verifikován a považován za důvěryhodný a sám neobsahuje žádné nedůvěryhodné objekty. Zakázat parsování externích entit (až to v XStreamu půjde, zatím jde o známou zranitelnost https://nvd.nist.gov/vuln/detail/CVE-2016-3674).

 

Run.java

Popis chyby:

Serializovaný objekt zpracovaný v Integer.parseInt uvnitř Run.java je bez kontroly deserializován pomocí unmarshal v XStream2 do proměnné LIST_CUTOFF. 

 

Doporučení:

Parametr LIST_CUTOFF by měl být ověřen na maximální povolený rozsah, aby se tak zamezilo potenciálnímu DoS při zobrazení komplexnější struktury artefaktů. Zakázat parsování externích entit (až to v XStreamu půjde, zatím jde o známou zranitelnost https://nvd.nist.gov/vuln/detail/CVE-2016-3674).

 

Run.java (další výskyt)

Popis chyby:

Serializovaný objekt zpracovaný v Integer.parseInt uvnitř Run.java je bez kontroly deserializován pomocí unmarshal v XStream2 do proměnné TREE_CUTOFF.

 

Doporučení:

Parametr TREE_CUTOFF by měl být ověřen na maximální povolený rozsah, aby se tak zamezilo potenciálnímu DoS při zobrazení komplexnější struktury artefaktů. Zakázat parsování externích entit (až to v XStreamu půjde, zatím jde o známou zranitelnost https://nvd.nist.gov/vuln/detail/CVE-2016-3674).

 

UpdateCenter.java

Popis chyby:

Serializovaný objekt zpracovaný v System.getProperty uvnitř UpdateCenter.java je bez kontroly deserializován pomocí unmarshal v XStream2 do proměnné UPDATE_CENTER_URL. Výsledem je riziko stažení podvrženého kódu ve formě aktualizace pluginu.

 

Doporučení:

Správným řešením je fixace aktualizačního URL na pevně definovanou hodnotu namísto generovaného názvu. Může mít nicméně negativní dopad na funkčnost. Zakázat parsování externích entit (až to v XStreamu půjde, zatím jde o známou zranitelnost https://nvd.nist.gov/vuln/detail/CVE-2016-3674).

 

FingerprintCleanupThread.java

Popis chyby:

Serializovaný objekt File zpracovaný v execute uvnitř FingerprintCleanupThread.java je bez kontroly deserializován pomocí fromXML v XmlFile.java.

 

Doporučení:

Kontrolovat strukčturu souboru a povolené hodnoty, zakázat parsování externích entit (až to v XStreamu půjde, zatím jde o známou zranitelnost https://nvd.nist.gov/vuln/detail/CVE-2016-3674).

 

Nodes.java

Popis chyby:

Serializovaný objekt File zpracovaný v getNodesDir uvnitř FingerprintCleanupThread.java je bez kontroly deserializován pomocí fromXML v XmlFile.java.

 

Doporučení:

Zakázat parsování externích entit (až to v XStreamu půjde, zatím jde o známou zranitelnost https://nvd.nist.gov/vuln/detail/CVE-2016-3674).

 

View.java

Popis chyby:

Serializovaný objekt getInputStream zpracovaný v metodě create je bez kontroly deserializován pomocí fromXML.

 

Doporučení:

Zakázat parsování externích entit (až to v XStreamu půjde, zatím jde o známou zranitelnost https://nvd.nist.gov/vuln/detail/CVE-2016-3674).

 

Unchecked Input for Loop Condition

LargeText.java

Popis chyby:

Metoda doProgressText získá vstup uživatele od prvku “” start “”.
Hodnota tohoto prvku protéká kódem, aniž by byla ověřena, a nakonec se používá ve stavu smyčky. To představuje nekontrolovaný vstup pro podmínku smyčky.

 

Doporučení:

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.

 

Frameable Login Page

V RememberMeServicesProxy.java

Popis chyby:

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

 

Doporučení:

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

 

C# Example Application

Dnes si zkusíme otestovat opět nějakou menší aplikaci vytvořenou přímo jako příklad bezpečnostních zranitelností. Jedná se o aplikaci v C#, kterou můžete nalézt zde:

https://www.codeproject.com/Articles/102284/SQL-Injection-and-Cross-Site-Scripting-2

Prohnal jsem aplikaci SAST nástrojem (jako vždy neuvádím kterým, nechávám na fantazii čtenářů). Níže je přehled nálezů z krátkým popisem jak by mělo/mohlo vypadat vyhodnocení takových nálezů:

SQL Injection

V souboru AddComment.aspx.cs

Popis chyby:

Aplikace SQL sestavuje query z parametru ViewState[“StrID”].

Doporučení:

Nesestavovat sql query dynamicky a použít druhý argument k ExecuteDataSet, tedy parameterValues.

 

Heuristic SQL injection

V souboru ListComments.aspx.cs

Popis chyby:

Aplikace spouští query GetComments sestavené mimo jiné z neošetřeného vstupu Request.QueryString[“cid”].

Doporučení:

Nesestavovat sql query dynamicky a použít druhý argument k ExecuteDataSet, tedy parameterValues.

 

Reflected XSS All Clients

V souboru ListComments.aspx.cs

Popis chyby:

Aplikace stejný parametr Request.QueryString[“cid”] zapisuje neošetřený na výstup.

Doporučení:

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.

 

Stored XSS

V souboru ListComments.aspx

Popis chyby:

Aplikace bere data z databáze a vypisuje je bez jakéhokoli ošetření na výstup uživateli (<%# DataBinder.Eval(Container.DataItem, “Comment”)%>).

Doporučení:

Veškerá dynamická data příslušně zaenkódovat, pokud jsou součástí výstupu.

 

Heap Inspection

V souboru LoginPage.aspx

Popis chyby:

Aplikace ukládá plain text heslo v položce txtPassword. Později nikde nedochází mazání této položky, tudíž je pořád v paměti.

Doporučení:

Mazat hesla hned po jejich použití. Pokud jsou v proměnné typu String, použít datový typ který není imutabilní aby šel obsah smazat.

 

Heuristic 2nd order SQL Injection

V souboru AddComment.aspx.cs

Popis chyby:

Aplikace v metodě BindListView načitá data z databáze, která následně použije pro další dotaz do databáze. To umožňuje útočníkovi upravit data v databázi a provést nepřímí útok typu SQL Injection.

Doporučení:

Nesestavovat sql query dynamicky a použít druhý argument k ExecuteDataSet, tedy parameterValues.

 

Missing HSTS Header

V souboru ListComments.aspx.cs

Popis chyby:

Webová aplikace nedefinuje záhlaví HSTS (metoda Page_Load), takže je náchylná k útoku.

 

Doporučení:

Nastavte Strict-Transport-Security header

XSRF

V souboru AddComment.aspx.cs

Popis chyby:

Aplikace v metodě UpdateComment získává parametr od uživatele od z hodnoty Value. Tato hodnota prochází kódem a je eventuálně použita k získání aplikačního stavu který ovlivňuje funkcionalitu. To umožňuje útok typu XSRF.

 

Doporučení:

Implementace standardního nebo knihovního anti-CSRF mechanismu: nejlépe zabudovaný mechanismus poskytovaný platformou.

InsecureWebApp

První aplikace, kterou si zkusíme oskenovat je InsecureWebApp, která, jak již název napovídá, schválně zavádí některé bezpečnostní chyby. Tudíž se na ní dá pěkně pocvičit práce se SAST nástroji. O aplikaci se dočtete zde:

http://insecurewebapp.sourceforge.net/main/index.html

Stáhnout zdrojové kódy si můžete zde:

https://sourceforge.net/projects/insecurewebapp/files/

Prohnal jsem aplikaci SAST nástrojem (jako vždy neuvádím kterým, nechávám na fantazii čtenářů). Níže je přehled nálezů z krátkým popisem jak by mělo/mohlo vypadat vyhodnocení takových nálezů:

Heuristic SQL injection

V souboru productListing

Popis chyby:

Proměnná productSearch není sanitizována a je zobrazena pomocí product.getImageFile()

Doporučení:

Escapovat např. pomocí WebUtils.esc()

 

V souboru sqltest.jsp

Popis chyby:

Proměnná sql je zobrazena bez validace a bez escapingu v sqltest.jsp:34. Ke zpracování lze podvrhnout libovolný SQL dotaz jako parametr.

Doporučení:

Escapovat např. pomocí WebUtils.esc(); pokud možno omezit změny v DB.

 

Cleartext submission of Sensitive Information

V souboru activateAccount

Popis chyby:

Identifikátor účtu accountId je přenášen v nezašifrované podobě. 

Doporučení:

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

Heap Inspection

Popis chyby:

Heslo po použití zůstává v paměti.

Doporučení:

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

 

Privacy Violation

V souboru accountDetail.jsp

Popis chyby:

Parametr accountId může být podvržen uživatelem ke zjištění údajů z cizího účtu.

Doporučení:

Parametru accountId dodanému uživatelem nelze důvěřovat, je nutné používat vlastní cookie-session nebo identifikátor dohledat v databázi na základě loginu.

 

Trust Boundary Violation

Popis chyby:

Aplikace importuje veškeré Cookies; cookies poté tečou programem bez validace/sanitace.

Doporučení:

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

Login.jsp

 

Popis chyby:

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

 

Doporučení:

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

 

Information Exposure through Error Message

V souboru sqltest.java

Popis chyby:

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

 

Doporučení:

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

 

Missing Content Security Policy

htmlHeader.jsp

Popis chyby:

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

Doporučení:

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

 

Reflected XSS All Clients

Popis chyby:

Proměnná productSearch není sanitizována a je zobrazena jako součást stránky. Může obsahovat JavaScript nebo dříve uložený škodlivý obsah.

Doporučení:

  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.

 

httpOnly cookie

v souboru Login.jsp

 

Popis chyby:

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

 

Doporučení:

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

 

Missing HSTS Header

V souboru htmlHeader.jsp

Popis chyby:

Webová aplikace nedefinuje záhlaví HSTS, takže je náchylná k útoku.

 

Doporučení:

Nastavte Strict-Transport-Security header

Unchecked Input for Loop Condition

V souboru sqltest.jsp

Popis chyby:

Metoda request.getParameter v  souboru sqltest.jsp získá vstup uživatele od prvku “” sql “”.
Hodnota tohoto prvku protéká kódem, aniž by byla ověřena, a nakonec se používá ve stavu smyčky. To představuje nekontrolovaný vstup pro podmínku smyčky.

Doporučení:

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.

 

Pico (CMS)

Dnes si zkusíme otestovat nějaký menší projekt v PHP. Konkrétně jednu z populárních PHP knihoven, Pico (CMS). Abychom nemuseli mít dilema zda zakládat tikety pro vývojáře dané aplikace a jednalo se pouze o ukázku, otestujeme nějakou starší verzi. Vybral jsem verzi 2.0.0. Každý si jako vždy můžete tento kód zkusit otestovat vaším nástroje, tato verze je k dispozici zde:

https://github.com/picocms/Pico/archive/v2.0.0.zip

Prohnal jsem aplikaci SAST nástrojem (jako vždy neuvádím kterým, nechávám na fantazii čtenářů). Níže je přehled nálezů z krátkým popisem jak by mělo/mohlo vypadat vyhodnocení takových nálezů:

Reflected XSS

V souboru Pico.php

Popis chyby:

Metoda getBaseUrl ziskava data  z HTTP_POST. Tato data nasledne prochazi kodem a jsou eventuálně zobrazena uživateli.

Doporučení:

  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.

 

Stored code Injection

V souboru Pico.php

Popis chyby:

Aplikace v metodě handleEVent přijímá a dynamicky spouští kód ovlivnitelný uživatelem použitím call_user_func_array.

Doporučení:

Aplikace, která spouští kód třetí strany (pluginy), by měla být spuštěna pod uživatelem s minimálním oprávněním. Pokud je to možné, izolovat veškeré dynamické spouštění do separátního dedikovaného uživatelského účtu, který má oprávnění pouze pro specifické operace a soubory použité pro dynamické spouštění, podle principu nejmenší nutné zodpovědnosti.

 

Missing HSTS Header

V souboru index.php

Popis chyby:

Webová aplikace nedefinuje záhlaví HSTS,takže je náchylná k útoku.

 

Doporučení:

Nastavte Strict-Transport-Security header

Possible Flow Control

V souboru Pico.php

Popis chyby:

Možný flow control nalezen v metodě evaluateRequestUrl.

Doporučení:

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

Path traversal

V souboru Pico.php

Popis chyby:

Metoda evaluateRequestUrl získavá data z položky REQUEST_URI. Hodnota poté neošetřená protéká kódem a je použita k získání cesty na disku. Soubor je následně načten.

Doporučení:

  1. V ideálním případě se vyhněte závislosti na dynamických datech pro výběr souboru.
  2. Ověření všech vstupů bez ohledu na zdroj. Ověření by mělo být založeno na whitelistu: spíše než odmítat

špatné vzory přijímat pouze data odpovídající dané struktuře. Kontrolujte datový typ, velikost, rozsah, formát,

očekávané hodnoty.

  1. Přijímejte dynamická data pouze pro název souboru, nikoli pro cestu a složky.

 

Příklady SAST skenů

V následující sekci najdete konkrétní příklady SAST skenů, vždy s odkazem na zdrojové kódy (Open-source). To vám umožnuje:

  • Podívat se na konkrétní nálezy přímo v kódu a nalézt si přesný výskyt
  • Spustit nějaký volně dostupný SAST nástroj nebo vám dostupný komerční a zkusit si to také,
    případně porovnat výsledky

Schválně neuvádím, jaký nástroj jsem kde použil, jde mi spíše o konkrétní příklad toho, jak pracovat s výsledky a orientovat se v daném kódu než vlastnosti konkrétních nástrojů. Skeny vznikali v různém čase a přidávám je sem postupně, když nějaký zajímavý udělám a je na to čas. Vždy skenuji pro potřeby ukázky starší verze, výsledky nad aktuální verzí daného sw nikdy nesdílím takto veřejně.

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.

 

Statická analýza bezpečnosti aplikací

Statické testování zabezpečení aplikací – nebo SAST (Static application security testing) – je typ testování zranitelnosti softwarového zabezpečení. Při analýze SAST kontrolujeme a analyzujeme kód aplikace, abychom zjistily slabiny zabezpečení.

SAST best-practices

Dodržování doporučených postupů SAST je nezbytné pro bezpečný a zabezpečený kód, protože kontrola problémů přímo ve zdrojových souborech nám pomáhá detekovat bezpečnostní chyby v rané fázi vývoje, dříve než bude produkt spuštěn.

Z tohoto důvodu je nezbytné, abychom pomocí statické kontroly kódu zajistili, že kód je bezpečný. Spoléhat se ale pouze na manuální práci byť zkušeného bezpečnostního analytika samozřejmě nejde. I u projektu malého rozsahu je ruční kontrola možná maximálně jednorázově, těžko představitelné je procházet veškeré zdrojové soubory s každou verzí a u větších projektů. Na druhou stranu ani automatizované nástroje nejsou samospásné, mají určitou chybovost a vyžadují ruční kontrolu výsledků, tj. odstranění tzv. „falešných pozitiv“. Umožňují nám vyvarovat se „slepého“ procházení velkého množství kódu a minimalizovat čas potřebný na danou kontrolu. Krom toho, že nás bezpečně upozorní na chyby, které bychom mohli jednoduše přehlédnout, nás upozorní na místa se zvýšeným rizikem zranitelnosti dané použitými technologiemi, chybou programátora nebo nepřehledností kódu které můžeme následně prozkoumat ručně.

Automatizované nástroje

Nástroje SAST analyzují zdrojový kód nebo binární soubory vytvářených aplikací.

Přicházejí do hry v průběhu programování, abychom dostali bezpečnostní testy do dřívějších fází životního cyklu vývoje softwaru a mohli tak najít zranitelnosti v kódu co nejdříve.

Tím zabráníme nákladným opravám v pozdějších fázích vývoje.

Tyto nástroje provádí v principu 2 typy analýz:

  • Lokální analýzu
  • Analýzu toku dat

Lokální analýzou rozumíme hledání chyb v kontextu odpovídajícímu nejvýše jednomu zdrojovému souboru, maximálně do kontextu jednoho typu (třídy, struktury apod. dle typu programovacího jazyka), tj. bez hlubší znalosti vazeb mezi jednotlivými funkcemi/metodami a komponentami systému. Taková analýza je samozřejmě mnohem jednodušší a soutředí se na obvyklé chyby v daném programovacím jazyku, hledání slabých šifrovacích algoritmů, špatně/vůbec (ne)nakonfigurovaných bezpečnostních pravidel a ochran, hesla natvrdo uložená v kódu apod. Pro takovou analýzu je obvykle plně dostačující porozumět struktuře daného kódu na úrovni tokenizace vstupů a rozlišení základních stavebních bloků dle daného paradigmatu. To ve většině případů umí kompilátor daného jazyka, který lze často rozšířit o další kontroly, nebo jiné nástroje pro konkrétní jazyk. Například pro většinu i nekompilovaných jazyků je k dispozici tzv. „linter“, nástroj který kontroluje formátování kódu a nejjednodušší typy chyb. Tyto nástroje a nástroje primárně specializované pro hledání bugů v daném jazyce fungují na stejném principu jako tyto jednoduché bezpečnostní kontroly. Proto jsou typy základní bezpečnostní kontroly obvykle dostupné i pro volně dostupné nástroje pro kontrolu chyb v daném jazyce ve formě dodatečných pravidel.
Analýza toku dat se naproti tomu snaží pochopit celý životní cyklus dat získaných jakýmkoli způsobem jako vstup od uživatele, od jejich vstupu do systému až po jejich následné odeslání zpět uživateli nebo uložení do databáze, na souborový systém nebo do jiných externích systémů. Snaží se tedy hledat tok dat mezi hranicemi kontrolovaného systému, od vstupu do systému po opuštění daného systému a jejich vliv na další proměnné v průběhu pobytu.
Na základě těchto znalostí lze provádět pokročilé analýzy bezpečnostních chyb, z nichž základní a nejčastější je tzv. “taint (poskrvněný, zamořený, nakažený) analýza”, která vychází z předpokladu, že jakákoli proměnná kterou lze ovlivnit zvějšku externím uživatelem systému představuje potencionální bezpečnostní riziko. Pokud je takováto proměnná použita ve výrazu, který vytváří/modifikuje další proměnnou, je tato další rovněž brána jako podezřelá. Pokud je následně jakákoli z těchto proměnných použita v potencionálně nebezpečných operacích, které posílají data na výstup (například přímé dotazy do databáze, spuštění příkazu na operačním systému, generování výstupu pro uživatele apod.) analyzátor toto vyhodnotí jako potencionálně možný vektor útoku daného typu.
Takovouto analýzu obvykle provádějí pouze pokročilé SAST nástroje, z nichž většina je placených.

Kategorizace zranitelností

Při statické kontrole kódu narazíme na různé druhy zranitelností, ať už ručně nebo automatizovaným nástrojem. Pro většinu známých zranitelností existují obecně platná pojmenování daná zažitou praxí, proto většina kategorií je stejná napříč SAST nástroji, články na webu, výukovými materiály na školách i obecně uznávanými standardy jako je OWASP Top 10, PCI DSS apod. Dále je možné druhy zranitelností kategorizovat podle tříd závažnosti, které má každý produkt lehce odlišné, ale nejzávažnější zranitelnosti, které jsou zařazeny do dané nejvyšší hodnoty pro daný produkt, bývají až na drobné odchylky totožné.

Pokud se jedná o práci se statickými nástroji pro analýzu kódu a vyhodnocování výsledků, musíme vždy chápat, o jaký druh zranitelnosti se jedná, rozumět tomu jakým způsobem se docílí zneužití ve zdrojovém kódu, abychom mohli kvalifikovaně rozhodnout, zda je v daném místě tento nález skutečně relevantní a jedná se o potencionální možný vektor útoku, nebo nikoli. Proto jsme vypracovali katalog nejčastějších zranitelností společně s popisem:

  • Rizika, která daná zranitelnost představuje
  • Příčiny jakým způsobem se toto děje
  • Následným doporučením jak se tomuto problému vyhnout

Zejména doporučení ale nemusí být obecně platná pro daný programovací jazyk, dané konkrétní místo v kódu, použití konkrétní knihovny apod. Tyto doporučení lze ale chápat jako obecný příklad toho, jak se daný problém může v některých konkrétních výskytech řešit a může dále posloužit jako inspirace ke konkrétnímu doporučení v reálné situaci.