Dokumentace splnění relevantních požadavků standardu ASVS

Tento dokument je uvedením naplnění požadavků standardu ASVS ve verzi 5 pro dodanou aplikaci a její části.

Je součástí dodavatelské vývojové dokumentace.

Slouźí jako jeden z podkladů pro akceptační řízení ze strany zadavatele.

Obecná deklarace

Dodavatel prohlašuje, že jím dodané aplikace a jejich části byly vyvíjeny stran technických řešení bezpečnosti, kontinuity provozu, robustnosti a důvěryhodnosti v souladu s požadavky standardu ASVS ve verzi 5 a to minimálně v povinném rozsahu požadovaném zadavatelem v zadávací dokumentaci.

Dodavatel uvede a případně popíše splnění požadavků v následující tabulce. Dodavatel prohlašuje, že informace uvedené v tomto dokumentu jsou pravdivé a aktuální a že v případě jakékoliv změny vůči požadavkům ASVS předloží zadavateli aktualizaci tohoto dokumentu. Dodavatel na místech, kde je uvedena povinnost vztahu k dokumentaci, uvede také konkrétní část dokumentace, kde se požadavek řeší, pokud takové konkrétní místo v dokumentaci existuje.

Splnění jednotlivých požadavků ASVS

Následující tabulka slouží pro deklarování a popis splnění jednotlivých požadavků ASVS verze 5. Dodavatel vyplní u každého požadaky to, jak jej splnil a případně uvede, kterou variantu technické realizace implementoval, pokud jsou u daného požadavku různé možnosti řešení. U požadavků, které nejsou pro danou aplikaci technicky relevantní, to dodavatel uvede.

Požadavek	Vyjádření dodavatele
Kapitola V1 Kódování a sanitizace
Skupina V1.1 Architektura kódování a sanitizace
Požadavek V1.1.1 Ověřeno, že vstup je dekódován nebo unescapen do kanonického tvaru pouze jednou, je dekódován pouze v případě, že jsou očekávána zakódovaná data v tomto tvaru, a že se to provádí před dalším zpracováním vstupu, například se to neprovádí po ověření vstupu nebo sanitizaci.
Požadavek V1.1.2 Aplikace vždy provádí výstupní kódování a escapování buď jako poslední krok před tím, než ji použije interpreter, pro který je určena, nebo je provádí samotný interpreter.
Skupina V1.2 Prevence injekce
Požadavek V1.2.1 Ověřeno, že je výstupní kódování pro odpověď HTTP, dokument HTML nebo dokument XML relevantní pro požadovaný kontext, jako je kódování příslušných znaků pro elementy HTML, atributy HTML, komentáře HTML, CSS nebo pole záhlaví HTTP, abyste se vyhnuli změně struktury zprávy nebo dokumentu.
Požadavek V1.2.2 Ověřeno, že jsou při dynamickém vytváření adres URL nedůvěryhodná data kódována podle jejich kontextu (např. kódování URL nebo kódování base64url pro parametry dotazu nebo cesty). Dále ověřeno, že jsou povoleny pouze bezpečné protokoly URL (např. zakázat javascript: nebo data:).
Požadavek V1.2.3 Ověřeno, že se při dynamickém vytváření každého obsahu JavaScriptu (včetně JSON) používá kódování výstupu nebo escapování, aby nedošlo ke změně struktury zprávy nebo dokumentu (aby nedocházelo k injektáži JavaScriptu a JSON).
Požadavek V1.2.4 Výběry dat nebo databázové dotazy (např. SQL, HQL, NoSQL, Cypher) používají parametrizované dotazy, ORM, entity frameworky nebo jsou jinak chráněny před injektáží SQL a dalšími útoky prostřednictvím injektáže databáze. Zajištěno, že je také realizováno při psaní programových procedur.
Požadavek V1.2.5 Ověřeno, že aplikace chrání před injektáží příkazů operačního systému a zda volání operačního systému používají parametrizované dotazy operačního systému nebo kontextové výstupní kódování příkazového řádku.
Požadavek V1.2.6 Ověřeno, že aplikace chrání před chybami zabezpečení prostřednictvím injektáže LDAP nebo byly implementovány specifické bezpečnostní kontroly zabraňující injektáže LDAP.
Požadavek V1.2.7 Ověřeno, že je aplikace chráněna proti útokům prostřednictvím injektáže XPath pomocí parametrizace dotazů nebo předkompilovaných dotazů.
Požadavek V1.2.8 Procesory LaTeX jsou nakonfigurovány bezpečně (například nepoužívají příznak "–shell-escape") a zda se k zabránění útokům prostřednictvím injektáže LaTeXu používá seznam povolených příkazů.
Požadavek V1.2.9 Aplikace používá řídicí znaky v regulárních výrazech (obvykle pomocí zpětného lomítka), aby se zabránilo jejich nesprávné interpretaci jako metaznaků.
Požadavek V1.2.10 Aplikace je chráněna proti zneužití souboru CSV a injekci vzorce. Aplikace při exportu obsahu CSV dodržuje pravidla uvozovacích znaků definovaná v oddílech 2.6 a 2.7 dokumentu RFC 4180. Při exportu do formátu CSV nebo jiných tabulkových formátů (například XLS, XLSX nebo ODF) aplikace správně uvozuje speciální znaky.
Skupina V1.3 Sanitizace
Požadavek V1.3.1 Veškerý nedůvěryhodný vstup HTML z editorů WYSIWYG nebo podobných aplikací je vždy upraven pomocí dobře známé a bezpečné knihovny pro sanitizaci HTML nebo funkce rámce.
Požadavek V1.3.2 Aplikace nepoužívá a neumožňuje funkce eval() nebo jiných funkcí pro dynamické spouštění kódu, jako je jazyk SpEL (Spring Expression Language).
Požadavek V1.3.3 Ověřeno, že jsou data předávaná do potenciálně nebezpečného kontextu upravena, aby byla vynucena bezpečnostní opatření, jako je povolení pouze znaků, které jsou bezpečné pro tento kontext, a oříznutí vstupu, který je příliš dlouhý.
Požadavek V1.3.4 Uživatelem zadaný skriptovatelný obsah SVG (Scalable Vector Graphics) je vždy prověřen nebo upraven tak, aby obsahoval pouze značky a atributy (například kreslenou grafiku), které jsou pro aplikaci bezpečné, např. neobsahují skripty a foreignObject.
Požadavek V1.3.5 Aplikace dezinfikuje nebo zakazuje uživatelem poskytnutý skriptovatelný obsah pro jazyky výrazů, jako jsou Markdown, CSS nebo XSL styly, BBCode nebo podobně.
Požadavek V1.3.6 Ověřeno, že aplikace chrání před útoky SSRF (Server-Side Request Forgery), a to ověřením nedůvěryhodných dat proti seznamu povolených protokolů, domén, cest a portů a sanitizací potenciálně nebezpečných znaků před použitím dat k volání jiné služby.
Požadavek V1.3.7 Aplikace chrání před útoky prostřednictvím injektáže šablon tím, že neumožňuje vytváření šablon na základě nedůvěryhodného vstupu. Pokud neexistuje žádná alternativa, musí být jakýkoli nedůvěryhodný vstup, který je dynamicky zahrnut během vytváření šablony, upraven nebo omezen.
Požadavek V1.3.8 Ověřeno, že aplikace před použitím v dotazech JNDI (Java Naming and Directory Interface) správně dezinfikuje nedůvěryhodný vstup a pokud je použito, je JNDI bezpečně nakonfigurována, aby zabránila útokům prostřednictvím injektáže JNDI.
Požadavek V1.3.9 Ověřeno, že aplikace před odesláním do memcache dezinfikuje obsah, aby se zabránilo útokům prostřednictvím injektáže.
Požadavek V1.3.10 V každém případě jsou formátovací řetězce, které by se při použití mohly přeložit neočekávaným nebo škodlivým způsobem, před zpracováním dezinfikovány.
Požadavek V1.3.11 Ověřeno, že aplikace před předáním do poštovních systémů dezinfikuje vstup uživatele, aby byla chráněna před injektáží SMTP nebo IMAP a nebo jiných poštovních protokolů.
Požadavek V1.3.12 Regulární výrazy neobsahují prvky způsobující exponenciální navracení, a je zajištěno, aby byl nedůvěryhodný vstup očištěn, aby se zmírnily útoky ReDoS nebo Runaway Regex.
Skupina V1.4 Paměť, řetězec a nespravovaný kód
Požadavek V1.4.1 Aplikace vždy používá řetězec bezpečný pro paměť, bezpečnější kopírování do paměti a aritmetiku ukazatele k detekci nebo prevenci přetečení zásobníku, vyrovnávací paměti nebo integer-overflow.
Požadavek V1.4.2 U číselných hodnot se používají techniky ověřování znaménka, rozsahu a vstupu, aby se zabránilo přetečení celých čísel.
Požadavek V1.4.3 Ověřeno, že se dynamicky alokovaná paměť a prostředky správně uvolňují a že se odkazy či ukazatele na uvolněnou paměť odstraní nebo nastaví na null, aby se předešlo visícím ukazatelům a zranitelnostem typu use-after-free.
Skupina V1.5 Bezpečná deserializace
Požadavek V1.5.1 aplikace konfiguruje XML parsery s restriktivním nastavením a že jsou zakázané nebezpečné funkce jako rozlišování externích entit, aby se předešlo útokům typu XXE (XML eXternal Entity).
Požadavek V1.5.2 Deserializace nedůvěryhodných dat vynucuje bezpečné zpracování vstupů, jako je použití seznamu povolených typů objektů nebo omezení typů objektů definovaných klientem, aby se zabránilo útokům deserializace. Mechanismy deserializace, které jsou explicitně definovány jako nezabezpečené, nesmí být použity s nedůvěryhodným vstupem.
Požadavek V1.5.3 Všechny různé analyzátory používané v aplikaci pro stejný datový typ (např. analyzátory JSON, analyzátory XML, analyzátory URL), provádějí analýzu konzistentním způsobem a používají stejný mechanismus kódování znaků, a předchází se tím problémům, jako jsou chyby zabezpečení interoperability JSON nebo zneužití jiného identifikátoru URI nebo chování analýzy souborů při útocích vzdáleného začlenění souborů (RFI) nebo SSRF (Server-side Request Forgery).
Kapitola V2 Validace a obchodní logika
Skupina V2.1 Validace a dokumentace byznys logiky
Požadavek V2.1.1 Dokumentace k aplikaci definuje pravidla pro ověřování vstupů, jak kontrolovat platnost datových položek oproti očekávané struktuře. Může se jednat o běžné datové formáty, jako jsou čísla kreditních karet, e-mailové adresy, telefonní čísla, nebo se může jednat o interní datový formát.
Požadavek V2.1.2 Dokumentace k aplikaci definuje, jak ověřit logickou a kontextovou konzistenci kombinovaných datových položek, jako je například kontrola shody předměstí a PSČ.
Požadavek V2.1.3 V dokumentaci sou zdokumentována očekávání ohledně limitů a ověření logiky, a to jak pro jednotlivé uživatele, tak pro globální vstupy a použití v rámci celé aplikace.
Skupina V2.2 Ověření vstupu
Požadavek V2.2.1 Vstup v aplikaci je vždy ověřen za účelem vynucení očekávání pro daný vstup. To je pozitivní ověření proti seznamu povolených hodnot, vzorů a rozsahů, nebo je založeno na porovnání vstupu s očekávanou strukturou a logickými limity podle předem definovaných pravidel. V případě L1 se může zaměřit na vstup, který se používá ke konkrétním obchodním nebo bezpečnostním rozhodnutím. Pro L2 a vyšší by to mělo platit pro všechny vstupy.
Požadavek V2.2.2 Aplikace navržena tak, aby vynucovala ověřování vstupu na straně serveru služby. I když ověřování na straně klienta zlepšuje použitelnost a mělo by být podporováno, nesmí se na něj spoléhat jako na ovládací prvek zabezpečení.
Požadavek V2.2.3 Aplikace zajišťuje, že kombinace souvisejících datových položek jsou přiměřené podle předem definovaných pravidel.
Skupina V2.3 Zabezpečení obchodní logiky
Požadavek V2.3.1 Aplikace bude zpracovávat pouze toky pro logiku pro stejného uživatele v očekávaném sekvenčním pořadí kroků a bez přeskočení kroků.
Požadavek V2.3.2 V dokumentaci k aplikaci implementovány limity logiky, aby se zabránilo zneužití chyb logiky.
Požadavek V2.3.3 Ověřeno, že jednotlivé transakce jsou používány na úrovni logiky tak, aby byla daná operace úspěšná v plném rozsahu, nebo byla vrácena zpět do předchozího správného stavu.
Požadavek V2.3.4 Ověřeno, že zamykací mechanismy na úrovni obchodní logiky (pokud jsou použity) používají k zajištění toho, aby omezené množství prostředků (například sedadla v divadle nebo dodací sloty) nemohlo být dvakrát rezervováno manipulací s logikou aplikace.
Požadavek V2.3.5 Ověřeno, že všechny toky byznysové logiky s vysokou hodnotou vyžadují schválení více uživateli, aby se zabránilo neoprávněným nebo náhodným akcím. To může mimo jiné zahrnovat velké peněžní převody, schvalování smluv, přístup k utajovaným informacím nebo bezpečnostní opatření ve výrobě.
Skupina V2.4 Anti-automatizace
Požadavek V2.4.1 Jsou zavedeny antiautomatizační kontrolní mechanismy, které chrání před nadměrným voláním funkcí aplikace, které by mohla vést k exfiltraci dat, vytváření nesmyslných dat, vyčerpání kvót, porušení limitu rychlosti, odmítnutí služby nebo nadměrnému využívání nákladných zdrojů.
Požadavek V2.4.2 Toky byznysové logiky vyžadují realistické lidské načasování, což zabraňuje příliš rychlému odesílání transakcí.
Kapitola V3 Zabezpečení webového frontendu
Skupina V3.1 Dokumentace zabezpečení webového frontendu
Požadavek V3.1.1 V dokumentaci k aplikaci jsou uvedeny očekávané funkce zabezpečení, které musí prohlížeče používající aplikaci podporovat (například HTTPS, HSTS (HTTP Strict Transport Security), Content Security Policy (CSP) a další relevantní mechanismy zabezpečení HTTP). Musí také definovat, jak se aplikace musí chovat, když některé z těchto funkcí nejsou k dispozici (například varování uživatele nebo blokování přístupu).
Skupina V3.2 Nezamýšlená interpretace obsahu
Požadavek V3.2.1 Jsou zavedeny bezpečnostní mechanismy, které brání prohlížečům ve vykreslování obsahu nebo funkcí v odpovědích HTTP v nesprávném kontextu (např. když je přímo požadováno rozhraní API, soubor nahraný uživatelem nebo jiný zdroj). Mezi možné ovládací prvky mohou patřit: neposkytování obsahu, pokud pole záhlaví požadavku HTTP (například Sec-Fetch-*) neindikují, že se jedná o správný kontext, použití direktivy sandbox v poli záhlaví Content-Security-Policy nebo použití typu dispozice přílohy v poli záhlaví Content-Disposition.
Požadavek V3.2.2 Ověřeno, že obsah, který má být zobrazen jako text, a nikoli jako HTML, je zpracováván pomocí bezpečných funkcí vykreslování (například createTextNode nebo textContent), aby se zabránilo nechtěnému spuštění obsahu, jako je HTML nebo JavaScript.
Požadavek V3.2.3 Ověřeno, že se aplikace vyhýbá přetěžování modelu DOM při použití JavaScriptu na straně klienta použitím explicitních deklarací proměnných, prováděním přísné kontroly typu, vyhýbáním se ukládání globálních proměnných na objekt dokumentu a implementací izolace oboru názvů.
Skupina V3.3 Nastavení souborů cookie
Požadavek V3.3.1 Ověřeno, že všechny soubory cookie mají nastaven atribut "Secure", a pokud pro název souboru cookie není použita předpona "Host-", je nutné pro název souboru cookie použít předponu "Secure-".
Požadavek V3.3.2 Ověřeno, že hodnota atributu každého souboru cookie SameSite je nastavena podle účelu souboru cookie, aby se omezilo vystavení útokům na ovlivnění uživatelského rozhraní a útokům na padělání požadavků na základě prohlížeče, které se běžně označují jako padělání požadavků mezi weby (CSRF).

Správa Detach Close

Stránka s tímto názvem ještě neexistuje

Odkaz vás zavedl na stránku, která ještě neexistuje. Můžete ji vytvořit stisknutím tlačítka Vytvořit stránku.