door Michal Rada 3 maanden geleden
81
Standard ASVS verze 5 v češtině
door Michal Rada 3 maanden geleden
81
Více na https://www.asvsvcestine.cz
Požadavek V17.3.2 Ověřeno, zda je signalizační server schopen pokračovatve zpracování legitimních signalizačních zpráv, pokud dojde k chybněformátované signalizační zprávě, která by mohla způsobit odmítnutíslužby. To by mohlo zahrnovat implementaci ověřování vstupů, bezpečnézpracování přetečení celých čísel, prevenci přetečení vyrovnávací pamětia použití dalších robustních technik zpracování chyb.
Požadavek V17.3.1 Ověřeno, zda je signalizační server schopen pokračovatve zpracování legitimních příchozích signalizačních zpráv běhempovodňového útoku. Toho by mělo být dosaženo zavedením omezení rychlostina úrovni signalizace.
Požadavek V17.2.8 Ověřeno, že je certifikát DTLS (Datagram TransportLayer Security) porovnán s atributem otisku protokolu SDP (SessionDescription Protocol) a v případě selhání kontroly ukončete datový proudmédia, aby byla zajištěna autenticita datového proudu média.
Požadavek V17.2.7 Ověřeno, zda jsou všechny mechanismy záznamu zvukunebo videa spojené s mediálním serverem schopny pokračovat ve zpracovánípříchozího mediálního provozu během záplavy paketů SRTP (SecureReal-time Transport Protocol) od legitimních uživatelů.
Požadavek V17.2.6 Ověřeno, zda mediální server není náchylný k chybězabezpečení konfliktu časování “ClientHello” v technologii DTLS(Datagram Transport Layer Security), a to kontrolou, zda je server médiíveřejně známý jako chybu zabezpečení, nebo provedením testu stavučasování.
Požadavek V17.2.5 Ověřeno, zda je mediální server schopen pokračovat vezpracování příchozího mediálního provozu během záplavy paketů protokoluSRTP (Secure Real-time Transport Protocol) od oprávněných uživatelů.
Požadavek V17.2.4 Ověřeno, zda je mediální server schopen pokračovat vezpracování příchozího mediálního provozu, pokud dojde k chybněformátovaným paketům protokolu SRTP (Secure Real-time TransportProtocol).
Požadavek V17.2.3 Ověřeno, zda je na mediálním serveru použito ověřováníprotokolem SRTP (Secure Real-time Transport Protocol), aby se zabránilotomu, že útoky prostřednictvím injektáže protokolu RTP (Real-timeTransport Protocol) povedou k odmítnutí služby nebo k vložení zvukovýchnebo obrazových médií do datových proudů médií.
Požadavek V17.2.2 Ověřeno, že je mediální server nakonfigurován tak, abypoužíval a podporoval schválené šifrovací sady DTLS (Datagram TransportLayer Security) a profil zabezpečené ochrany pro rozšíření DTLS provytváření klíčů pro protokol DTLS-SRTP (Secure Real-time TransportProtocol).
Požadavek V17.2.1 Ověřeno, zda je klíč pro certifikát DTLS (DatagramTransport Layer Security) spravován a chráněn na základězdokumentovaných zásad pro správu kryptografických klíčů.
Požadavek V17.1.2 Ověřeno, zda služba Traversal Using Relays around NAT(TURN) není náchylná k vyčerpání zdrojů, když se oprávnění uživatelépokusí otevřít velký počet portů na serveru TURN.
Požadavek V17.1.1 Ověřeno, zda služba Traversal Using Relays around NAT(TURN) umožňuje přístup pouze k IP adresám, které nejsou vyhrazeny prozvláštní účely (např. interní sítě, vysílání, zpětná smyčka). To platípro adresy IPv4 i IPv6.
Požadavek V16.5.4 Ověřeno, zda je definována obslužná rutina chyb“poslední možnost”, která zachytí všechny neošetřené výjimky. To jejednak proto, aby se zabránilo ztrátě podrobností o chybě, které musíjít do souborů protokolu, a jednak aby se zajistilo, že chyba neodstranícelý proces aplikace, což povede ke ztrátě dostupnosti.
Požadavek V16.5.3 Ověřeno, že aplikace selže řádně a bezpečně(failsecurelly), včetně případů, kdy dojde k výjimce, a zabrání tak podmínkámselhání, jako je zpracování transakce navzdory chybám vyplývajícím zlogiky ověřování.
Požadavek V16.5.2 Ověřeno, zda aplikace nadále funguje bezpečně, kdyžselže přístup k externím prostředkům, například pomocí vzorů, jako jsoujističe nebo řádné snížení výkonu.
Požadavek V16.5.1 Ověřeno, že je příjemci vrácena obecná zpráva, kdyždojde k neočekávané chybě nebo chybě citlivé na zabezpečení, azajistěte, aby nedošlo k vystavení citlivých interních systémových dat,jako jsou trasování zásobníku, dotazy, tajné klíče a tokeny.
Požadavek V16.4.3 Ověřeno, že se protokoly bezpečně přenášejí do logickyodděleného systému pro analýzu, detekci, upozorňování a eskalaci. Cílemje zajistit, aby v případě narušení aplikace nedošlo ke kompromitacilogů.
Požadavek V16.4.2 Ověřeno, že jsou protokoly chráněny před neoprávněnýmpřístupem a nelze je upravovat a jak.
Požadavek V16.4.1 Ověřeno, že všechny komponenty protokolování správněkódují data, aby se zabránilo vkládání protokolů.
Požadavek V16.3.4 Ověřeno, že aplikace protokoluje neočekávané chyby aselhání řízení zabezpečení, jako jsou selhání protokolu TLS back-endu.
Požadavek V16.3.3 Ověřeno, že aplikace protokoluje události zabezpečenídefinované v dokumentaci a také pokusy o obejití kontrol zabezpečení,jako je ověření vstupu, obchodní logika a antiautomatizace.
Požadavek V16.3.2 Ověřeno, že jsou protokolovány neúspěšné pokusy oautorizaci. U L3 to musí zahrnovat protokolování všech rozhodnutí oautorizaci, včetně protokolování při přístupu k citlivým datům (bezprotokolování samotných citlivých dat).
Požadavek V16.3.1 Ověřeno, že jsou protokolovány všechny operaceověřování, včetně úspěšných a neúspěšných pokusů. Měla by býtshromažďována i další metadata, jako je typ autentizace nebo použitéfaktory.
Požadavek V16.2.5 Při protokolování citlivých dat aplikace vynucujeprotokolování na základě úrovně ochrany dat. Například nemusí býtpovoleno zaznamenávat určitá data, jako jsou přihlašovací údaje neboplatební údaje. Ostatní data, jako jsou tokeny relace, mohou býtzaznamenána pouze pomocí algoritmu hash nebo masky, a to buď úplně, nebočástečně.
Požadavek V16.2.4 Ověřeno, že protokoly jsou čteny a zpracoványpoužívaným nástrojem manažerem protokolů, nejlépe pomocí společnéhoformátu protokolování.
Požadavek V16.2.3 Ověřeno, že aplikace ukládá nebo vysílá protokolypouze do souborů a služeb, které jsou zdokumentovány v inventářiprotokolů.
Požadavek V16.2.2 Zdroje času pro všechny komponenty protokolování jsousynchronizovány a zda časová razítka v metadatech událostí zabezpečenípoužívají čas UTC nebo obsahují explicitní posun časového pásma. Čas UTCse doporučuje pro zajištění konzistence napříč distribuovanými systémy apro zabránění nejasnostem při přechodech letního času.
Požadavek V16.2.1 Každá položka protokolu obsahuje nezbytná metadata(například kdy, kde, kdo, co), která by umožnila podrobné prozkoumáníčasové osy, když dojde k události.
Požadavek V16.1.1 Existuje inventář protokolů dokumentujícíprotokolování prováděné v každé vrstvě aplikace, jaké události seprotokolují, formáty protokolů, kde se protokolování ukládá, jak sepoužívá, jak se řídí přístup k němu a jak dlouho se protokolyuchovávají.
Požadavek V15.4.4 Ověřeno, že zásady přidělení prostředků zabraňujívyčerpávání vláken tím, že zajišťují spravedlivý přístup ke zdrojům,například využitím fondů vláken, což umožňuje vláknům s nižší prioritoupokračovat v přiměřeném časovém rámci.
Požadavek V15.4.3 Ověřeno, že se zámky používají konzistentně, aby sezabránilo zaseknutí vláken, ať už čekáním na sebe nebo nekonečnýmopakováním, a že logika uzamykání zůstává v kódu zodpovědném za správuprostředku, aby se zajistilo, že zámky nemohou být neúmyslně neboškodlivě upraveny externími třídami nebo kódem.
Požadavek V15.4.2 Ověřeno, že jsou kontroly stavu zdroje, jako je jehoexistence nebo oprávnění, a akce, které na nich závisejí, prováděny jakojedna atomická operace, aby se zabránilo konfliktům časování TOCTOU(time-of-check to time-of-use). Například kontrola, zda soubor existujepřed jeho otevřením, nebo ověření přístupu uživatele před jeho udělením.
Požadavek V15.4.1 Ověřeno, že je ke sdíleným objektům ve vícevláknovémkódu (jako jsou mezipaměti, soubory nebo objekty v paměti, ke kterýmpřistupuje více vláken) bezpečně přistupováno pomocí typů bezpečných propřístup z více vláken a synchronizačních mechanismů, jako jsou zámkynebo semafory, aby se zabránilo konfliktům časování a poškození dat.
Požadavek V15.3.7 Ověřeno, že má aplikace ochranu proti útokům naznečištění parametrů HTTP, zejména pokud rozhraní aplikace nerozlišujezdroj parametrů požadavku (řetězec dotazu, parametry textu, souborycookie nebo pole záhlaví).
Požadavek V15.3.6 Ověřeno, že je kód JavaScript napsán způsobem, kterýzabraňuje znečištění prototypu, například použitím metody Set() neboMap() místo objektových literálů.
Požadavek V15.3.5 Ověřeno, že aplikace explicitně zajišťuje, že proměnnéjsou správného typu, a provádí striktní operace shody a provonání.
Požadavek V15.3.4 Ověřeno, že všechny komponenty proxy a middlewarusprávně přenášejí původní IP adresu uživatele pomocí důvěryhodnýchdatových polí, se kterými koncový uživatel nemůže manipulovat, a žeaplikace a webový server používají tuto správnou hodnotu proprotokolování a bezpečnostní rozhodnutí, jako je omezení rychlosti, sohledem na to, že ani původní IP adresa nemusí být spolehlivá kvůlidynamickým IP adresám, VPN nebo podnikové firewally.
Požadavek V15.3.3 Ověřeno, že aplikace má protiopatření na ochranu předútoky hromadného přiřazování omezením povolených polí na řadič a akci,např. není možné vložit nebo aktualizovat hodnotu pole, pokud nebylazamýšlena jako součást této akce.
Požadavek V15.3.2 Ověřeno, že tam, kde back-end aplikace volá externíadresy URL, je nakonfigurován tak, aby nesledoval přesměrování, pokud senejedná o zamýšlenou funkci.
Požadavek V15.3.1 Ověřeno, že aplikace vrací pouze požadovanoupodmnožinu polí z datového objektu. Neměla by například vracet celýdatový objekt, protože některá jednotlivá pole by neměla být přístupnáuživatelům.
Požadavek V15.2.5 Aplikace implementuje další ochranu kolem částíaplikace, které jsou zdokumentovány jako obsahující “nebezpečné funkce”nebo používající knihovny třetích stran považované za “rizikovékomponenty”. To může zahrnovat techniky, jako je sandboxing,zapouzdření, kontejnerizace nebo izolace na úrovni sítě, které zpozdí aodradí útočníky, kteří kompromitují jednu část aplikace, od přesunujinam v aplikaci.
Požadavek V15.2.4 Ověřeno, že komponenty třetích stran a všechny jejichtranzitivní závislosti jsou zahrnuty z očekávaného úložiště, ať užinterně vlastněného nebo externího zdroje, a že nehrozí riziko útokuzáměnou závislostí.
Požadavek V15.2.3 Ověřeno, že provozní prostředí obsahuje pouze funkce,které jsou vyžadovány pro fungování aplikace, a nezpřístupňujenadbytečné funkce, jako je testovací kód, ukázkové fragmenty kódu avývojové funkce.
Požadavek V15.2.2 Aplikace má implementovanou ochranu proti ztrátědostupnosti v důsledku funkcí, které jsou časově náročné nebo náročné nazdroje, na základě zdokumentovaných bezpečnostních rozhodnutí astrategií pro tento účel.
Požadavek V15.2.1 Ověřeno, že aplikace obsahuje pouze součásti, kteréneporušily dokumentované časové rámce pro aktualizaci a nápravu.
Požadavek V15.1.5 Dokumentace k aplikaci upozorňuje na části aplikace,kde se používá “nebezpečná funkce” (pokud je to umožněno).
Požadavek V15.1.4 Dokumentace k aplikaci upozorňuje na knihovny třetíchstran, které jsou považovány za “rizikové komponenty” (pokud je jejichpoužití připuštěno).
Požadavek V15.1.3 Dokumentace k aplikaci identifikuje funkce, které jsoučasově náročné nebo náročné na prostředky. To musí zahrnovat, jakzabránit ztrátě dostupnosti v důsledku nadužívání této funkce a jak sevyhnout situaci, kdy vytvoření odpovědi trvá déle, než je časový limitspotřebitele. Potenciální obrana může zahrnovat asynchronní zpracování,použití front a omezení paralelních procesů na uživatele a aplikaci.
Požadavek V15.1.2 Je udržován katalog inventářev rámci architekturyaplikace, jako je například seznam software (SBOM), všech používanýchknihoven třetích stran, včetně ověření, že komponenty pocházejí z předemdefinovaných, důvěryhodných a nepřetržitě udržovaných úložišť.
Požadavek V15.1.1 Dokumentace k aplikaci definuje časové rámce nápravyna základě rizik pro verze komponent třetích stran s chybami zabezpečenía pro aktualizaci knihoven obecně, aby se minimalizovalo rizikovyplývající z těchto komponent.
Požadavek V14.3.3 Ověřeno, že data uložená v úložišti prohlížeče(například localStorage, sessionStorage, IndexedDB nebo soubory cookie)neobsahují citlivá data, s výjimkou tokenů relace.
Požadavek V14.3.2 Aplikace nastavuje dostatečná pole hlaviček odpovědíHTTP proti ukládání do mezipaměti (tj. Cache-Control: no-store), abycitlivá data nebyla ukládána do mezipaměti prohlížečů.
Požadavek V14.3.1 Ověřená data po ukončení klienta nebo relace jsou vždyvymazána z úložiště klienta, jako je například model DOM prohlížeče.Pole záhlaví odpovědi HTTP “Clear-Site-Data” s tím může pomoci, alestrana klienta by měla být také schopna vyčistit, pokud připojení kserveru není k dispozici při ukončení relace.
Požadavek V14.2.8 Z metadat souborů odeslaných uživatelem jsouodstraněny citlivé informace, pokud uživatel neudělil souhlas suložením.
Požadavek V14.2.7 Ccitlivé informace podléhají klasifikaci uchovávánídat, a je zajištěno, aby byla zastaralá nebo nepotřebná data odstraněnaautomaticky, podle definovaného plánu nebo podle situace.
Požadavek V14.2.6 Aplikace vrací pouze minimální citlivá data požadovanápro funkčnost aplikace. Například vrátí pouze některé číslice číslaplatební karty a ne celé číslo. Pokud jsou vyžadována úplná data, mělaby být v uživatelském rozhraní maskována, pokud si je uživatel výslovněnezobrazí.
Požadavek V14.2.5 Ověřeno, že jsou mechanismy ukládání do mezipamětinakonfigurovány tak, aby ukládaly do mezipaměti pouze odpovědi, kterémají očekávaný typ obsahu pro daný prostředek a neobsahují citlivýdynamický obsah. Webový server by měl při přístupu k neexistujícímusouboru vracet odpověď 404 nebo 302, místo aby vracel jiný platnýsoubor. To by mělo zabránit útokům Web Cache Deception.
Požadavek V14.2.4 Ověřeno, že jsou implementovány kontroly týkající secitlivých dat souvisejících se šifrováním, ověřováním integrity,uchováváním, způsobem protokolování dat, řízením přístupu k citlivýmdatům v protokolech, ochranou osobních údajů a technologiemi zvyšujícímiochranu osobních údajů, jak je definováno v dokumentaci pro konkrétníúroveň ochrany dat.
Požadavek V14.2.3 Ověřeno, že definovaná citlivá data nejsou odesílánanedůvěryhodným stranám (např. sledovačům uživatelů), aby se zabránilonežádoucímu shromažďování dat mimo kontrolu aplikace.
Požadavek V14.2.2 Ověřeno, že aplikace zabraňuje ukládání citlivých datdo mezipaměti v serverových komponentách, jako jsou nástroje provyrovnávání zatížení a mezipaměti aplikací, nebo zda zajišťuje, aby byladata po použití bezpečně vymazána.
Požadavek V14.2.1 Ověřeno, že jsou citlivá data odesílána na serverpouze v těle zprávy HTTP nebo v polích záhlaví a zda adresa URL ařetězec dotazu neobsahují citlivé informace, jako je klíč rozhraní APInebo token relace.
Požadavek V14.1.2 Všechny úrovně ochrany citlivých dat majízdokumentovanou sadu požadavků na ochranu. To musí zahrnovat (mimo jiné)požadavky týkající se obecného šifrování, ověřování integrity,uchovávání, způsobu protokolování dat, řízení přístupu k citlivým údajůmv protokolech, šifrování na úrovni databáze, použití technologiízvyšujících ochranu soukromí a soukromí a dalších požadavků nadůvěrnost.
Požadavek V14.1.1 Všechna citlivá data vytvořená a zpracovaná aplikacíbyla identifikována a klasifikována do úrovní ochrany. To zahrnuje data,která jsou pouze kódována, a proto je lze snadno dekódovat, jako jsouřetězce Base64 nebo datová část ve formátu prostého textu uvnitř souboruJWT. Úrovně ochrany musí brát v úvahu veškeré předpisy a normy týkajícíse ochrany dat a soukromí, které musí aplikace splňovat.
Požadavek V13.4.7 Ověřeno, že je webová vrstva nakonfigurována tak, abyposkytovala pouze soubory s určitými příponami souborů, aby se zabrániloneúmyslnému úniku informací, konfigurace a zdrojového kódu.
Požadavek V13.4.6 Aplikace nezpřístupňuje podrobné informace o verziback-endových komponent.
Požadavek V13.4.5 Dokumentace (například pro interní rozhraní API) akoncové body monitorování nejsou zpřístupněny, pokud to není výslovněurčeno.
Požadavek V13.4.4 Ověřeno, že použití metody HTTP TRACE není podporovánov produkčních prostředích, abyste předešli možnému úniku informací.
Požadavek V13.4.3 Ověřeno, že webové servery nezpřístupňují výpisyadresářů klientům, pokud to není výslovně zamýšleno.
Požadavek V13.4.2 Ověřeno, že jsou režimy ladění zakázány pro všechnykomponenty v produkčním prostředí, aby se zabránilo odhalení funkcíladění a úniku informací.
Požadavek V13.4.1 Ověřeno, že je aplikace nasazena buď bez metadatsprávy zdrojů, včetně složek .git nebo .svn, nebo tak, aby tyto složkybyly nepřístupné jak externě, tak pro samotnou aplikaci.
Požadavek V13.3.4 Ověřeno, že jsou tajné kódy nakonfigurované tak, abyvypršela jejich platnost a aby se obměňovaly na základě dokumentace kaplikaci.
Požadavek V13.3.3 Všechny kryptografické operace jsou prováděny pomocíizolovaného modulu zabezpečení (jako je trezor nebo modul hardwarovéhozabezpečení) za účelem bezpečné správy a ochrany klíčového materiálupřed odhalením mimo modul zabezpečení.
Požadavek V13.3.2 Přístup k tajným datovým zdrojům dodržuje zásadunejnižších oprávnění.
Požadavek V13.3.1 Řešení pro správu tajných kódů, jako je trezor klíčů,se používá k bezpečnému vytváření, ukládání, řízení přístupu a rušeníback-endových tajných kódů. Ty mohou zahrnovat hesla, materiály klíčů,integrace s databázemi a systémy třetích stran, klíče a semena protokeny založené na čase, další interní tajemství a klíče API. Tajné kódynesmí být zahrnuty ve zdrojovém kódu aplikace ani zahrnuty v artefaktechsestavení. U aplikace L3 to musí zahrnovat hardwarové řešení, jako jeHSM.
Požadavek V13.2.6 V případě, že se aplikace připojuje k samostatnýmslužbám, dodržuje pouze zdokumentovanou konfiguraci pro každé připojení,jako je maximální počet paralelních připojení, chování při dosaženímaximálního povoleného počtu připojení, časové limity připojení astrategie opakování.
Požadavek V13.2.5 Ověřeno, že je webový nebo aplikační servernakonfigurován se seznamem povolených prostředků nebo systémů, dokterých může server odesílat požadavky nebo načítat data nebo soubory.
Požadavek V13.2.4 Ověřeno, že se seznam povolených (allow-list) používák definování externích zdrojů nebo systémů, se kterými může aplikacekomunikovat (např. pro odchozí požadavky, načítání dat nebo přístup ksouborům). Tento seznam povolených může být implementován na aplikačnívrstvě, webovém serveru, firewallu nebo v kombinaci různých vrstev.
Požadavek V13.2.3 Ověřeno, že pokud je nutné použít přihlašovací údajepro ověření služby, přihlašovací údaje používané příjemcem nejsouvýchozími přihlašovacími údaji (např. root/root nebo admin/admin).
Požadavek V13.2.2 Komunikace mezi komponentami back-endových aplikací,včetně místních služeb nebo služeb operačního systému, rozhraní API,middlewaru a datových vrstev, probíhá s účty přiřazenými k nejméněnezbytným oprávněním.
Požadavek V13.2.1 Komunikace mezi komponentami back-endové aplikace,které nepodporují standardní mechanismus uživatelských relací aplikace,včetně rozhraní API, middlewaru a datových vrstev, je ověřena. Ověřovánímusí používat jednotlivé účty služeb, krátkodobé tokeny nebo ověřovánína základě certifikátů, a ne neměnné přihlašovací údaje, jako jsouhesla, klíče rozhraní API nebo sdílené účty s privilegovaným přístupem.
Požadavek V13.1.4 Dokumentace k aplikaci definuje tajné kódy(tajemství),které jsou kritické pro zabezpečení aplikace, a plán jejich rotace nazákladě modelu hrozeb organizace a obchodních požadavků.
Požadavek V13.1.3 Dokumentace k aplikaci definuje strategie správyprostředků pro každý externí systém nebo službu, kterou používá (např.databáze, popisovače souborů, vlákna, připojení HTTP). To by mělozahrnovat postupy uvolňování prostředků, nastavení časového limitu,zpracování chyb a kde je implementována logika opakování, specifikacilimitů opakování, zpoždění a algoritmů zpětného spuštění. Pro synchronníoperace odezvy HTTP by měl nařídit krátké časové limity a buď zakázatopakování, nebo striktně omezit opakování, aby se zabránilo kaskádovýmzpožděním a vyčerpání zdrojů.
Požadavek V13.1.2 V dokumentaci, pro každou službu, kterou aplikacepoužívá, je definován maximální počet souběžných připojení (např. limityfondu připojení) a jak se aplikace chová po dosažení tohoto limitu,včetně všech záložních mechanismů nebo mechanismů obnovení, aby sezabránilo podmínkám odmítnutí služby.
Požadavek V13.1.1 V dokumentaci jsou zdokumentovány všechny komunikačnípotřeby aplikace. To musí zahrnovat externí služby, na kterých jeaplikace závislá, a případy, kdy koncový uživatel může být schopenposkytnout externí umístění, ke kterému se aplikace poté připojí.
Požadavek V12.3.5 Služby komunikující interně v rámci systému(komunikace v rámci služby) používají silné ověřování, aby bylozajištěno ověření každého koncového bodu. K zajištění identity je nutnépoužít silné metody ověřování, jako je ověřování klientů TLS, a topomocí infrastruktury veřejných klíčů a mechanismů, které jsou odolnévůči útokům opakovaného přehrání. U architektur mikroslužeb zvažtepoužití sítě služeb, která zjednoduší správu certifikátů a zvýšízabezpečení.
Požadavek V12.3.4 Připojení TLS mezi interními službami používajídůvěryhodné certifikáty. Pokud se používají interně generovanécertifikáty nebo certifikáty podepsané svým držitelem, musí být služba,která je využívá, nakonfigurovaná tak, aby důvěřovala pouze určitýminterním certifikačním autoritám a konkrétním certifikátům podepsanýmsvým držitelem.
Požadavek V12.3.3 Protokol TLS nebo jiný vhodný mechanismus šifrovánípřenosu se používá pro veškeré připojení mezi interními službamizaloženými na protokolu HTTP v rámci aplikace a nevrací se knezabezpečené nebo nešifrované komunikaci.
Požadavek V12.3.2 Před komunikací se serverem TLS se ověřuje, že klientiTLS ověřují přijaté certifikáty.
Požadavek V12.3.1 Pro všechna příchozí a odchozí připojení k aplikaci az ní, včetně monitorovacích systémů, nástrojů pro správu, vzdálenéhopřístupu a SSH, middlewaru, databází, mainframů, partnerských systémůnebo externích rozhraní API, se používá šifrovaný protokol, jako je TLS.Server se nesmí vrátit k nezabezpečeným nebo nešifrovaným protokolům.
Požadavek V12.2.2 Jsou využívány jen externí služby, které používajíveřejně důvěryhodné certifikáty TLS.
Požadavek V12.2.1 Protokol TLS se používá pro veškeré připojení meziklientem a externími službami založenými na protokolu HTTP a nevrací sek nezabezpečené nebo nešifrované komunikaci.
Požadavek V12.1.5 V nastavení protokolu TLS aplikace je nastavenamožnost Encrypted Client Hello (ECH), aby se zabránilo odhalenícitlivých metadat, jako je například indikace názvu serveru (SNI), běhemprocesů handshake protokolu TLS.
Požadavek V12.1.4 Je povoleno a nakonfigurováno správné odvolánícertifikátů, například využití protokolu OCSP (Online Certificate StatusProtocol).
Požadavek V12.1.3 Před použitím identity certifikátu k ověření neboautorizaci aplikace ověřuje, zda jsou klientské certifikáty mTLSdůvěryhodné.
Požadavek V12.1.2 Jsou povoleny pouze doporučené šifrovací sady, přičemžnejsilnější šifrovací sady jsou nastaveny jako upřednostňované. L3aplikace musí podporovat pouze šifrovací sady, které poskytují dopřednéutajení.
Požadavek V12.1.1 Jsou povoleny pouze nejnovější doporučené verzeprotokolu TLS, například TLS 1.2 a TLS 1.3. Upřednostňovanou možnostímusí být nejnovější verze protokolu TLS.
Požadavek V11.7.2 Je použit princip minimalizace dat zajišťujícíodhalení minimálního množství dat během zpracování a je zajištěno, abybyla data zašifrována ihned po použití nebo co nejdříve.
Požadavek V11.7.1 Používá se úplné šifrování paměti, které chránícitlivá data během jejich používání a zabraňuje přístupu neoprávněnýchuživatelů nebo procesů.
Požadavek V11.6.2 Pro výměnu klíčů se používají výhradně schválenékryptografické algoritmy (například Diffie-Hellman) se zaměřením nazajištění toho, aby mechanismy výměny klíčů používaly zabezpečenéparametry. Předejdete tak útokům na proces vytváření klíčů, které bymohly vést k útokům typu “anti-in-the-middle” nebo k prolomeníkryptografických záznamů.
Požadavek V11.6.1 Pro generování a osazení klíčů a generování aověřování digitálních podpisů se používají pouze schválenékryptografické algoritmy a provozní režimy. Algoritmy generování klíčůnesmí generovat nezabezpečené klíče zranitelné vůči známým útokům,například klíče RSA, které jsou zranitelné vůči Fermatově faktorizaci.
Požadavek V11.5.2 Ověřeno, že je používaný mechanismus generovánínáhodných čísel navržen tak, aby fungoval bezpečně i při velkémzatížení.
Požadavek V11.5.1 Všechna náhodná čísla a řetězce, které jsou určeny ktomu, aby byly neuhodnutelné, jsou vždy generovány pomocí kryptografickyzabezpečeného generátoru pseudonáhodných čísel (CSPRNG) a musí mítalespoň 128 bitů entropie. Všimněte si, že UUID tuto podmínkunerespektují.
Požadavek V11.4.4 Aplikace při odvozování tajných klíčů z hesel používáschválené funkce odvození klíče s parametry roztažení klíčů. Používanéparametry musí vyvážit zabezpečení a výkon, aby se zabránilo útokůmhrubou silou ohrozit výsledný kryptografický klíč.
Požadavek V11.4.3 Funkce hash používané v digitálních podpisech jakosoučást ověřování dat nebo integrity dat jsou odolné proti kolizím amají odpovídající bitovou délku. Pokud je požadována odolnost protikolizi, musí být výstupní délka alespoň 256 bitů. Pokud je požadovánapouze odolnost proti útokům před druhým obrazem, musí být výstupní délkaalespoň 128 bitů.
Požadavek V11.4.2 Hesla jsou uložena pomocí schválené, výpočetně náročnéfunkce odvození klíče (označované také jako “funkce hashování hesel”) snastavením parametrů nakonfigurovaným na základě aktuálních pokynů.Nastavení by mělo vyvážit zabezpečení a výkon tak, aby útoky hrubousilou byly dostatečně náročné pro požadovanou úroveň zabezpečení.
Požadavek V11.4.1 Pro obecné kryptografické případy použití, včetnědigitálních podpisů, HMAC, KDF a generování náhodných bitů se používajípouze schválené funkce hash. Nepovolené funkce hash, jako je MD5, nesmíbýt použity pro žádné kryptografické účely.
Požadavek V11.3.5 Ověřeno, že jakákoli kombinace šifrovacího algoritmu aalgoritmu MAC pracuje v režimu šifrování a následné paměti MAC.
Požadavek V11.3.4 Hodnoty nonce, inicializační vektory a další čísla najedno použití nepoužívají pro více než jeden pár šifrovacího klíče adatového prvku. Metoda generování musí být vhodná pro použitýalgoritmus.
Požadavek V11.3.3 Šifrovaná data jsou chráněna před neoprávněnýmiúpravami, nejlépe pomocí schválené metody ověřeného šifrování nebokombinací schválené metody šifrování se schváleným algoritmem MAC.
Požadavek V11.3.2 Používají pouze schválené šifry a režimy, jako je AESs GCM.
Požadavek V11.3.1 Nikde v aplikaci se nepoužívají nezabezpečené režimyblokování (např. ECB) a schémata slabého odsazení (např. PKCS#1 v1.5).
Požadavek V11.2.5 Všechny pokud kryptografické moduly selhávají, jde ofail-securelly a všechny takové chyby jsou zpracovávány způsobem, kterýneumožňuje chyby zabezpečení, jako jsou například útoky Oracle sodsazením.
Požadavek V11.2.4 Všechny kryptografické operace jsou constant-time, anejde o short-circuit operace při porovnávání, výpočtech nebo vráceních,aby nedošlo k úniku informací.
Požadavek V11.2.3 Všechna kryptografická primární data (primitives)využívají minimálně 128bitové zabezpečení na základě algoritmu,velikosti klíče a konfigurace. Například 256bitový klíč ECC poskytujezhruba 128bitové zabezpečení, zatímco RSA vyžaduje 3072bitový klíč kdosažení 128 bitů zabezpečení.
Požadavek V11.2.2 Aplikace je navržena s kryptografickou flexibilitou,aby bylo možné kdykoli překonfigurovat, upgradovat nebo vyměnitalgoritmy náhodných čísel, ověřené šifrování, MAC nebo hashovacíalgoritmy, délky klíčů, kola, šifry a režimy, aby se chránily předkryptografickým přerušením. Stejně tak musí být možné nahrazovat klíče ahesla a data znovu šifrovat. To umožní bezproblémový upgrade napostkvantovou kryptografii (PQC), jakmile budou široce dostupné vysocespolehlivé implementace schválených schémat nebo standardů PQC.
Požadavek V11.2.1 Pro kryptografické operace se používají oborověověřené implementace (včetně knihoven a hardwarově akcelerovanýchimplementací).
Požadavek V11.1.4 V dokumentaci je udržován kryptografický inventář. Tomusí zahrnovat zdokumentovaný plán, který nastiňuje cestu migrace nanové kryptografické standardy, jako je postkvantová kryptografie, abybylo možné reagovat na budoucí hrozby.
Požadavek V11.1.3 K identifikaci všech instancí kryptografie v systémujsou použity mechanismy zjišťování kryptografických funkcí, včetněoperací šifrování, hodnot hash a podepisování.
Požadavek V11.1.2 Je zpracován, udržován a pravidelně aktualizovánkryptografický soupis a zahrnuje všechny kryptografické klíče, algoritmya certifikáty používané aplikací. Musí také dokumentovat, kde lze a kdenelze klíče v systému použít a jaké typy dat lze a nelze pomocí klíčůchránit.
Požadavek V11.1.1 V dokumentaci jsou zásady pro správu kryptografickýchklíčů a zda se životní cyklus kryptografického klíče řídí standardem prosprávu klíčů, jako je NIST SP 800-57. To by mělo zahrnovat zajištěnítoho, aby klíče nebyly nadměrně sdíleny (například s více než dvěmaentitami pro sdílené tajné klíče a více než jednou entitou pro soukroméklíče).
Požadavek V10.7.3 Ověřeno, že uživatel může kontrolovat, upravovat aodvolávat souhlasy, které uživatel udělil prostřednictvím autorizačníhoserveru.
Požadavek V10.7.2 Autorizační server při výzvě k vyjádření souhlasuuživatele poskytuje dostatečné a jasné informace o tom, s čím je souhlasvyjednáván. Pokud je to možné, mělo by to zahrnovat povahu požadovanýchautorizací (obvykle na základě rozsahu, serveru prostředků, podrobnostío autorizaci RAR (Rich Authorization Requests)), identitu autorizovanéaplikace a dobu platnosti těchto autorizací.
Požadavek V10.7.1 Autorizační server zajišťuje, že uživatel souhlasí skaždou žádostí o autorizaci. Pokud nelze zaručit identitu klienta, musíautorizační server vždy explicitně vyzvat uživatele k vyjádřenísouhlasu.
Požadavek V10.6.2 Poskytovatel OpenID (pokud se používá) zmírňujeodmítnutí služby prostřednictvím vynuceného odhlášení. Získánímvýslovného potvrzení od koncového uživatele nebo, pokud je k dispozici,ověřením parametrů v požadavku na odhlášení (iniciovaném předávajícístranou), jako je například “id_token_hint”.
Požadavek V10.6.1 Poskytovatel OpenID (pokud se používá) povoluje prorežim odpovědi pouze hodnoty ‘code’, ‘ciba’, ‘id_token’ nebo ’id_tokencode. Všimněte si, že “kód” je upřednostňován před “id_token kódem”(hybridní tok OIC) a “token” (jakýkoli implicitní tok) nesmí být použit.
Požadavek V10.5.5 Při použití odhlášení zpětným kanálem OIDC předávajícístrana zmírní odmítnutí služby prostřednictvím vynuceného odhlášení azmatků mezi JWT v toku odhlášení. Klient musí ověřit, že je token proodhlášení správně zadán s hodnotou ‘logout+jwt’, obsahuje deklaraciidentity ‘event’ se správným názvem člena a neobsahuje deklaraci‘nonce’. Všimněte si, že se také doporučuje mít krátkou dobu expirace(např. 2 minuty).
Požadavek V10.5.4 Vyžaduje se, že klient ověřuje, zda je token ID určenk použití pro daného klienta (cílovou skupinu), a to tak, žezkontrolujete, zda se deklarace identity aud z tokenu rovná hodnotěclient_id pro klienta.
Požadavek V10.5.3 Vyžaduje se, že klient odmítá pokusy škodlivéhoautorizačního serveru o zosobnění jiného autorizačního serveruprostřednictvím metadat autorizačního serveru. Klient musí odmítnoutmetadata autorizačního serveru, pokud adresa URL vydavatele v metadatechautorizačního serveru přesně neodpovídá předem nakonfigurované adreseURL vydavatele očekávané klientem.
Požadavek V10.5.2 Vyžaduje se, že klient jednoznačně identifikujeuživatele z deklarací identity tokenu ID, obvykle deklarace identity‘sub’, kterou nelze znovu přiřadit jiným uživatelům (v rozsahuposkytovatele identity).
Požadavek V10.5.1 Vyžaduje se, že klient (jako předávající strana)zmírňuje útoky na přehrání tokenu ID. Například tím, že zajistíte, abydeklarace identity ‘nonce’ v tokenu ID odpovídala hodnotě ‘nonce’odeslané v žádosti o ověření poskytovateli OpenID (v OAuth2 se na niodkazuje jako na žádost o autorizaci odeslanou na autorizační server).
Požadavek V10.4.16 Pokaždé se ověřuje, že klient je důvěrný a žeautorizační server vyžaduje použití silných metod ověřování klientů(založených na kryptografii s veřejným klíčem a odolných vůči útokůmpřehrání), jako je vzájemný protokol TLS (“tls_client_auth”,“self_signed_tls_client_auth”) nebo soukromý klíč JWT(“private_key_jwt”).
Požadavek V10.4.15 U klienta na straně serveru (který není spuštěn nazařízení koncového uživatele) autorizační server zajišťuje, že hodnotaparametru authorization_details pochází z back-endu klienta a že s níuživatel nemanipuloval. Například tím, že vyžaduje použití nabízenéautorizační žádosti (PAR) nebo autorizační žádosti zabezpečené JWT(JAR).
Požadavek V10.4.14 Autorizační server vydává pouze přístupové tokeny somezením odesílatele (Proof-of-Possession), a to buď pomocí přístupovýchtokenů vázaných na certifikát pomocí vzájemného protokolu TLS (mTLS),nebo přístupových tokenů vázaných na DPoP (Demonstration of Possession).
Požadavek V10.4.13 Ověřeno, že typ udělení “code” se vždy používáspolečně s nabízenými autorizačními žádostmi (PAR).
Požadavek V10.4.12 Autorizační server pro daného klienta povoluje pouzehodnotu “response_mode”, kterou tento klient potřebuje použít. Napříkladtím, že autorizační server ověří tuto hodnotu proti očekávaným hodnotámnebo pomocí nabízené autorizační žádosti (PAR) nebo autorizační žádostizabezpečené JWT (JAR).
Požadavek V10.4.11 Autorizační server přiřazuje klientovi OAuth pouzepožadované účely.
Požadavek V10.4.10 Důvěryhodný klient je vždy ověřen pro požadavkyzpětného kanálu mezi klientem a autorizovaným serverem, jako jsoužádosti o tokeny, nabízené žádosti o autorizaci (PAR) a žádosti oodvolání tokenu.
Požadavek V10.4.9 Ověřeno, že mohou být obnovovací tokeny a referenčnípřístupové tokeny odvolány oprávněným uživatelem pomocí uživatelskéhorozhraní autorizačního serveru, abyste snížili riziko škodlivých klientůnebo odcizených tokenů.
Požadavek V10.4.8 Ověřeno, že obnovovací tokeny mají absolutní vypršeníplatnosti, včetně případu, kdy je použito vypršení platnosti klouzavéhoobnovovacího tokenu.
Požadavek V10.4.7 Pokud autorizační server podporuje neověřenoudynamickou registraci klienta, snižuje riziko škodlivých klientskýchaplikací. Musí ověřit metadata klienta, jako jsou všechny registrovanéidentifikátory URI, zajistit souhlas uživatele a upozornit uživatelepřed zpracováním žádosti o autorizaci s nedůvěryhodnou klientskouaplikací.
Požadavek V10.4.6 V případě použití udělení kódu autorizační serverzmírňuje útoky zachycení autorizačního kódu tím, že vyžaduje ověřovacíklíč pro výměnu kódu (PKCE). U požadavků na autorizaci musí autorizačníserver vyžadovat platnou hodnotu “code_challenge” a nesmí přijmouthodnotu “code_challenge_method” “plain”. Žádost o token musí vyžadovatověření parametru code_verifier.
Požadavek V10.4.5 Autorizační server zmírňuje útoky na přehráníobnovovacích tokenů u veřejných klientů, nejlépe pomocí obnovovacíchtokenů s omezením odesílatele, tj. prokázání důkazu vlastnictví (DPoP)nebo přístupových tokenů vázaných na certifikát pomocí vzájemnéhoprotokolu TLS (mTLS). U aplikací L1 a L2 lze použít obměnu obnovovacíchtokenů. Pokud se použije obměna obnovovacích tokenů, musí autorizačníserver po použití zneplatnit obnovovací token a odvolat všechnyobnovovací tokeny pro tuto autorizaci, pokud je poskytnut již použitý azneplatněný obnovovací token.
Požadavek V10.4.4 Autorizační server pro daného klienta umožňuje použitípouze povolení, které tento klient potřebuje použít. Všimněte si, žegranty “token” (implicitní tok) a “password” (tok přihlašovacích údajůvlastníka prostředku) se již nesmí používat.
Požadavek V10.4.3 Ověřeno, že je autorizační kód krátkodobý. Maximálníživotnost může být až 10 minut pro aplikace L1 a L2 a až 1 minuta proaplikace L3.
Požadavek V10.4.2 Pokud autorizační server vrátí autorizační kód vautorizační odpovědi, lze jej pro žádost o token použít pouze jednou. Udruhé platné žádosti s autorizačním kódem, který již byl použit k vydánípřístupového tokenu, musí autorizační server odmítnout žádost o token aodvolat všechny vydané tokeny související s autorizačním kódem.
Požadavek V10.4.1 Autorizační server ověřuje identifikátory URIpřesměrování na základě seznamu povolených předem registrovanýchidentifikátorů URI specifických pro klienta pomocí přesného porovnánířetězců.
Požadavek V10.3.5 Server prostředků brání použití odcizenýchpřístupových tokenů nebo opětovnému přehrání přístupových tokenů (odneoprávněných stran) tím, že vyžaduje přístupové tokeny s omezenímodesílatele, buď vzájemný protokol TLS pro OAuth 2, nebo OAuth 2Demonstration of Proof of Possession (DPoP).
Požadavek V10.3.4 Ověřeno, že pokud server prostředků vyžaduje konkrétnísílu, metody nebo aktuálnost ověřování, ověří, zda prezentovanýpřístupový token splňuje tato omezení. Pokud je například k dispozici,pomocí deklarací identity OIDC ‘acr’, ‘amr’ a ‘auth_time’.
Požadavek V10.3.3 Ověřeno, že pokud rozhodnutí o řízení přístupuvyžaduje identifikaci jedinečného uživatele z přístupového tokenu (JWTnebo související odpověď na introspekci tokenu), server prostředkůidentifikuje uživatele z deklarací, které nelze znovu přiřadit jinýmuživatelům. Typicky to znamená použití kombinace deklarací identity‘iss’ a ‘sub’.
Požadavek V10.3.2 Ověřeno, že server prostředků vynucuje rozhodnutí oautorizaci na základě deklarací identity z přístupového tokenu, kterédefinují delegovanou autorizaci. Pokud jsou přítomny deklarace jako“sub”, “rozsah” a “authorization_details”, musí být součástí rozhodnutí.
Požadavek V10.3.1 Server prostředků přijímá pouze přístupové tokeny,které jsou určeny pro použití s danou službou (cílovou skupinou). Cílováskupina může být zahrnuta do strukturovaného přístupového tokenu(například deklarace identity aud v tokenu JWT) nebo ji lze zkontrolovatpomocí koncového bodu introspekce tokenu.
Požadavek V10.2.3 Klient OAuth požaduje v požadavcích na autorizačníserver pouze požadované obory (nebo jiné autorizační parametry).
Požadavek V10.2.2 Pokud klient OAuth může komunikovat s více než jednímautorizačním serverem, má ochranu proti záměnovým útokům. Může tonapříklad vyžadovat, aby autorizační server vrátil hodnotu parametru‘iss’ a ověřil ji v odpovědi na autorizaci a odpovědi tokenu.
Požadavek V10.2.1 Pokud se používá tok kódu, musí mít klient OAuthochranu před útoky na padělání požadavků v prohlížeči, běžně označovanéjako padělání požadavků mezi weby (CSRF), které aktivují žádosti otokeny, a to buď pomocí funkce PKCE (Proof Key for Code Exchange), nebokontrolou parametru “state”, který byl odeslán v žádosti o autorizaci.
Požadavek V10.1.2 Klient přijímá hodnoty z autorizačního serveru(například autorizační kód nebo token ID), pouze pokud tyto hodnotypocházejí z toku autorizace, který byl iniciován stejnou relací atransakcí uživatelského agenta. To vyžaduje, aby tajné kódy generovanéklientem, jako je ověřovací klíč pro výměnu kódu (PKCE) (PKCE)‘code_verifier’, ‘state’ nebo OIDC ‘nonce’, nebyly odhadnutelné, bylyspecifické pro transakci a byly bezpečně svázány s klientem i relacíuživatelského agenta, ve které byla transakce zahájena.
Požadavek V10.1.1 Tokeny jsou odesílány pouze komponentám, které jenezbytně potřebují. Například při použití vzoru backend pro frontend proaplikace JavaScript založené na prohlížeči musí být přístupové aobnovovací tokeny přístupné pouze pro backend.
Požadavek V9.2.4 Pokud vydavatel tokenu používá stejný soukromý klíč provydávání tokenů různým cílovým skupinám, obsahují vydané tokeny omezenícílové skupiny, které jednoznačně identifikuje zamýšlené cílové skupiny.Tím zabráníte opětovnému použití tokenu u nezamýšlené cílové skupiny.Pokud je identifikátor cílové skupiny dynamicky zřízen, musí vydavateltokenu tyto cílové skupiny ověřit, aby se ujistil, že nevedou kzosobnění cílové skupiny.
Požadavek V9.2.3 Ověřeno, že služba přijímá pouze tokeny, které jsouurčeny pro použití s danou službou (cílovou skupinou). U tokenů JWT toholze dosáhnout ověřením deklarace identity aud proti seznamu povolenýchdefinovaným ve službě.
Požadavek V9.2.2 Před přijetím obsahu tokenu služba, která přijímátoken, ověřuje správný typ tokenu a je určen k zamýšlenému účelu.Například pro rozhodnutí o autorizaci lze přijmout pouze přístupovétokeny a k prokázání ověření uživatele lze použít pouze tokeny ID.
Požadavek V9.2.1 Ověřeno, že pokud je v datech tokenu uveden časovýrozsah platnosti, token a jeho obsah jsou přijaty pouze v případě, žedoba ověření spadá do tohoto časového rozsahu platnosti. Například utokenů JWT je nutné ověřit deklarace identity “nbf” a “exp”.
Požadavek V9.1.3 Klíčový prostředek, který se používá k ověřenísamostatných tokenů, pochází z důvěryhodných předem nakonfigurovanýchzdrojů pro vydavatele tokenu, což útočníkům zabrání v určenínedůvěryhodných zdrojů a klíčů. U souborů JWT a dalších struktur JWSmusí být hlavičky jako ‘jku’, ‘x5u’ a ‘jwk’ ověřeny proti seznamudůvěryhodných zdrojů povolených.
Požadavek V9.1.2 K vytvoření a ověření samostatných tokenů pro danýkontext lze použít pouze algoritmy na seznamu povolených. Seznampovolených musí obsahovat povolené algoritmy, ideálně pouze symetrickénebo asymetrické algoritmy, a nesmí obsahovat algoritmus “None”. Pokudje nutné podporovat symetrickou i asymetrickou metriku, budou zapotřebídalší ovládací prvky, aby se zabránilo záměně klíčů.
Požadavek V9.1.1 Před přijetím obsahu tokenu jsou samostatné tokenyověřeny pomocí jejich digitálního podpisu nebo MAC k ochraně předmanipulací.
Požadavek V8.4.2 přístup k rozhraním pro správu (administračnímrozhraním) zahrnuje více vrstev zabezpečení, včetně průběžného ověřováníidentity spotřebitelů, hodnocení stavu zabezpečení zařízení a kontextovéanalýzy rizik, a zajistěte, aby umístění sítě nebo důvěryhodné koncovébody nebyly jedinými faktory pro autorizaci, i když mohou snížitpravděpodobnost neoprávněného přístupu.
Požadavek V8.4.1 Aplikace s multitenantovým přístupem a více klientypoužívají ovládací prvky mezi klienty, abyste zajistili, že operacepříjemců nikdy neovlivní klienty, se kterými nemají oprávnění kinterakci.
Požadavek V8.3.3 Přístup k objektu je založen na oprávněních původníhosubjektu (např. uživatele nebo prostředku), nikoli na oprávněníchjakéhokoli zprostředkovatele nebo služby jednající jeho jménem. Pokudnapříklad spotřebitel zavolá webovou službu pomocí samostatného tokenupro autentizaci a služba si pak vyžádá data z jiné služby, druhá službapoužije k rozhodování o oprávněních token příjemce, nikoli token typumachine-to-machine z první služby.
Požadavek V8.3.2 Ověřeno, že změny hodnot, na kterých se provádějírozhodnutí o autorizaci, se použijí okamžitě. Pokud změny nelze použítokamžitě (například při spoléhání se na data v samostatných tokenech),musí existovat zmírňující ovládací prvky, které upozorní, kdyžspotřebitel provede akci, když k tomu již není oprávněn, a vrátí změnuzpět. Všimněte si, že tato alternativa by nezmírnila únik informací.
Požadavek V8.3.1 Ověřeno, že aplikace vynucuje autorizační pravidla navrstvě důvěryhodné služby a nespoléhá na ovládací prvky, se kterými bymohl nedůvěryhodný příjemce manipulovat, jako je JavaScript na straněklienta.
Požadavek V8.2.4 Pro rozhodnutí o ověřování a autorizaci jsouimplementovány adaptivní kontrolní prvky zabezpečení založené naatributech prostředí a kontextových atributech uživatele a prostředku(jako je denní doba, umístění, IP adresa nebo zařízení), jak jedefinováno v dokumentaci k aplikaci. Tyto ovládací prvky musí býtpoužity, když se příjemce pokusí zahájit novou relaci a také běhemexistující relace.
Požadavek V8.2.3 Aplikace zajišťuje, že přístup na úrovni pole je omezenna spotřebitelský prostředek s explicitními oprávněními ke konkrétnímpolím, aby se zmírnila porušená autorizace na úrovni vlastností objektu(BOPLA).
Požadavek V8.2.2 Aplikace zajišťuje, že přístup ke konkrétním datům jeomezen na spotřebitelský prostředek s explicitními oprávněními kekonkrétním datovým položkám, aby se zmírnil nezabezpečený přímý odkaz naobjekt (IDOR) a porušená autorizace na úrovni objektu (BOLA).
Požadavek V8.2.1 Aplikace zajišťuje, že přístup na úrovni funkce jeomezen na spotřebitelský prostředek s explicitními oprávněními.
Požadavek V8.1.4 Dokumentace definuje, jak se při rozhodování používajífaktory prostředí a kontextové faktory, kromě autorizace na úrovnifunkce, dat a pole. To by mělo zahrnovat vyhodnocené atributy, prahovéhodnoty rizika a provedené akce (např. povolení, výzva, zamítnutí,stupňovité ověřování).
Požadavek V8.1.3 Dokumentace k aplikaci definuje atributy prostředí akontextové atributy (mimo jiné včetně denní doby, umístění uživatele, IPadresy nebo zařízení), které se v aplikaci používají k rozhodování ozabezpečení, včetně těch, které se týkají ověřování a autorizace.
Požadavek V8.1.2 Dokumentace definuje pravidla pro omezení přístupu naúrovni pole (čtení i zápisu) na základě oprávnění příjemce a atributůzdrojů. Všimněte si, že tato pravidla mohou záviset na jiných hodnotáchatributů příslušného datového objektu, jako je stav nebo stav.
Požadavek V8.1.1 Dokumentace definuje pravidla pro omezení přístupu naúrovni funkce a přístupu specifického pro data na základě oprávněnípříjemce a atributů prostředků.
Požadavek V7.6.2 Vytvoření relace vyžaduje buď souhlas uživatele, neboexplicitní akci, která zabrání vytvoření nových relací aplikace bezzásahu uživatele.
Požadavek V7.6.1 Ověřeno, že se životnost relace a ukončení mezipředávajícími stranami (RP) a poskytovateli identity (IdP) chová tak,jak je uvedeno, a v případě potřeby vyžaduje opětovné ověření, napříkladkdyž je dosaženo maximální doby mezi událostmi ověření IdP.
Požadavek V7.5.3 Ověřeno, že před provedením vysoce citlivých transakcínebo operací aplikace vyžaduje další ověření pomocí alespoň jednohofaktoru nebo sekundárního ověření.
Požadavek V7.5.2 Uživatelé mohou zobrazit a (po opětovném ověřeníalespoň jedním faktorem) ukončit některé nebo všechny aktuálně aktivnírelace.
Požadavek V7.5.1 Ověřeno, že před povolením úprav citlivých atributůúčtu, které mohou mít vliv na ověřování, jako je e-mailová adresa,telefonní číslo, konfigurace MFA nebo jiné informace používané přiobnovení účtu, aplikace vyžaduje úplné opětovné ověření.
Požadavek V7.4.5 Ověřeno, že správci aplikace mohou ukončit aktivnírelace pro jednotlivé uživatele nebo pro všechny uživatele.
Požadavek V7.4.4 Ověřeno, že všechny stránky, které vyžadují ověření,mají snadný a viditelný přístup k funkci odhlášení.
Požadavek V7.4.3 Aplikace nabízí možnost ukončit všechny ostatní aktivnírelace po úspěšné změně nebo odebrání jakéhokoli faktoru ověřování(včetně změny hesla prostřednictvím resetu nebo obnovení a aktualizacenastavení MFA, pokud je k dispozici).
Požadavek V7.4.2 Ověřeno, že aplikace ukončí všechny aktivní relace,když je uživatelský účet zakázán nebo odstraněn (například zaměstnanecopustí společnost).
Požadavek V7.4.1 Ověřeno, že při aktivaci ukončení relace (napříkladodhlášení nebo vypršení platnosti) aplikace nepovolí jakékoli dalšípoužití relace. U referenčních tokenů nebo stavových relací to znamenázneplatnění dat relace na back-endu aplikace. Aplikace používajícísamostatné tokeny budou potřebovat řešení, jako je udržování seznamuukončených tokenů, zakázání tokenů vytvořených před datem a časem projednotlivé uživatele nebo rotace podpisového klíče pro jednotlivéuživatele.
Požadavek V7.3.2 Existuje absolutní maximální životnost relace, aby bylovynuceno opakované ověření na základě analýzy rizik a zdokumentovanýchrozhodnutí o zabezpečení.
Požadavek V7.3.1 Ověřeno, že je aplikován časový limit nečinnosti, abybylo vynuceno opětovné ověření podle analýzy rizik a zdokumentovanýchrozhodnutí o zabezpečení.
Požadavek V7.2.4 Ověřeno, že aplikace generuje nový token relace přiověření uživatele, včetně opětovného ověření, a ukončí aktuální tokenrelace.
Požadavek V7.2.3 Pokud jsou referenční tokeny použity k reprezentaciuživatelských relací, jsou jedinečné a generované pomocí kryptografickyzabezpečeného generátoru pseudonáhodných čísel (CSPRNG) a mají alespoň128 bitů entropie.
Požadavek V7.2.2 Aplikace používá samostatné nebo referenční tokeny,které jsou dynamicky generovány pro správu relací, tj. nepoužívástatické tajné klíče a klíče rozhraní API.
Požadavek V7.2.1 Aplikace provádí všechna ověření tokenu relace pomocídůvěryhodné back-endové služby.
Požadavek V7.1.3 V dokumentaci všechny systémy, které vytvářejí aspravují uživatelské relace jako součást ekosystému správy federovanýchidentit (například systémy jednotného přihlašování), jsou zdokumentoványspolu s ovládacími prvky pro koordinaci životnosti relací, ukončení adalších podmínek, které vyžadují opětovné ověření.
Požadavek V7.1.2 V dokumentaci je definováno, kolik souběžných(paralelních) relací je povoleno pro jeden účet, a také zamýšlenéchování a akce, které mají být provedeny po dosažení maximálního počtuaktivních relací.
Požadavek V7.1.1 V dokumentaci je uveden časový limit nečinnosti relaceuživatele a absolutní maximální životnost relace, zda je vhodnákombinace s dalšími ovládacími prvky a zda dokumentace obsahujeodůvodnění jakýchkoli odchylek od požadavků na opětovné ověření NIST SP800-63B.
Požadavek V6.8.4 Pokud aplikace používá samostatného poskytovateleidentity (IdP) a očekává konkrétní sílu, metody nebo aktuálnostověřování pro konkrétní funkce, aplikace to ověří pomocí informacívrácených poskytovatelem identity. Pokud se například použije OIDC, lzetoho dosáhnout ověřením deklarací identity tokenu ID, jako jsou ‘acr’,‘amr’ a ‘auth_time’ (pokud jsou k dispozici). Pokud poskytovatelidentity tyto informace neposkytne, musí mít aplikace zdokumentovanýzáložní přístup, který předpokládá, že byl použit mechanismus minimálnísíly ověření (například jednofaktorové ověření pomocí uživatelskéhojména a hesla).
Požadavek V6.8.3 Kontrolní výrazy SAML jsou jednoznačně zpracovány apoužity pouze jednou během doby platnosti, aby se zabránilo útokům sopakovaným přehráním.
Požadavek V6.8.2 Přítomnost a integrita digitálních podpisů ukontrolních výrazů ověřování (například u kontrolních výrazů JWT neboSAML) jsou vždy ověřeny a jsou odmítána všechny kontrolní výrazy, kterénejsou podepsány nebo mají neplatné podpisy.
Požadavek V6.8.1 Ověřeno, že pokud aplikace podporuje více poskytovatelůidentity (IDP/QSIDP), nelze identitu uživatele podvrhnoutprostřednictvím jiného podporovaného poskytovatele identity (např.pomocí stejného identifikátoru uživatele). Standardním zmírněním bybylo, kdyby aplikace zaregistrovala a identifikovala uživatele pomocíkombinace ID IdP (sloužícího jako jmenný prostor) a ID uživatele v IdP.
Požadavek V6.7.2 Výzva nonce dlouhá alespoň 64 bitů a je statistickyjedinečná nebo jedinečná po celou dobu životnosti kryptografickéhozařízení.
Požadavek V6.7.1 Certifikáty používané k ověření kontrolních výrazů(hash) kryptografického ověřování uloženy tak, aby byly chráněny předzměnami.
Požadavek V6.6.4 Tam, kde se nabízená oznámení používají provícefaktorové ověřování, se k prevenci útoků push bombingu používáomezení rychlosti. Toto riziko může také zmírnit porovnávání čísel.
Požadavek V6.6.3 Ověřeno, že je mechanismus ověřování mimo pásmozaložený na kódu chráněn proti útokům hrubou silou pomocí omezenírychlosti. Zvažte také použití kódu s alespoň 64 bity entropie.
Požadavek V6.6.2 Ověřeno, zda jsou požadavky na vzdálené ověření, kódynebo tokeny vázány na původní požadavek na ověření, pro který bylyvygenerovány, a že nejsou použitelné pro předchozí nebo následujícípožadavek.
Požadavek V6.6.1 Pokud jsou použity ověřovací mechanismy přes PSTN kdoručování jednorázových hesel prostřednictvím telefonu nebo SMS jsounabízeny pouze v případě, že telefonní číslo bylo dříve ověřeno, jsounabízeny také alternativní silnější metody (například jednorázová heslazaložená na čase) a služba poskytuje uživatelům informace o jejichbezpečnostních rizicích. U L3 aplikací nesmí být telefon a SMS kdispozici jako volitelné příslušenství.
Požadavek V6.5.8 Ověřeno, že jednorázová hesla založená na čase (TOTP)jsou kontrolována na základě zdroje času z důvěryhodné služby, a nikoliz času poskytnutého nedůvěryhodným nebo klientem.
Požadavek V6.5.7 Biometrické autentizační mechanismy se používají pouzejako sekundární faktory společně s faktorem vlastnictví nebo faktoremznalosti.
Požadavek V6.5.6 Jakýkoli faktor ověření (včetně fyzických zařízení) vpřípadě krádeže nebo jiné ztráty lze odvolat nebo zneplatnit.
Požadavek V6.5.5 Ověřeno, že požadavky na ověření, kódy nebo tokeny,stejně jako jednorázová hesla založená na čase (TOTP), mají definovanouživotnost. Požadavky mimo pásmo musí mít maximální životnost 10 minut au TOTP maximální životnost 30 sekund.
Požadavek V6.5.4 Ověřeno, že tajemství a ověřovací kódy mají minimálně20 bitů entropie (obvykle stačí 4 náhodné alfanumerické znaky nebo 6náhodných číslic).
Požadavek V6.5.3 Ověřeno, že tajemství, ověřovací kódy a one-timejednorázová hesla jsou generovány pomocí kryptograficky zabezpečenéhogenerátoru pseudonáhodných čísel (CSPRNG), abyste se vyhnulipředvídatelným hodnotám.
Požadavek V6.5.2 Ověřeno, že při ukládání do back-endu aplikace jsouvyhledávací tajné kódy s méně než 112 bity entropie (19 náhodnýchalfanumerických znaků nebo 34 náhodných číslic) zahashovány schválenýmalgoritmem hash úložiště hesel, který obsahuje 32bitovou náhodná saltdata. Standardní hashovací funkce může být použita, pokud má tajemství112 bitů entropie nebo více.
Požadavek V6.5.1 Ověřeno, že lze kódy jako lookup-codes, nebo kódy ajednorázová hesla (TOTP) úspěšně použít pouze jednou.
Požadavek V6.4.6 Ověřeno, že uživatelé v roli správce mohou iniciovatproces obnovení hesla uživatele, ale že jim to neumožňuje změnit nebozvolit heslo uživatele. Tím se zabrání situaci, kdy znají heslouživatele.
Požadavek V6.4.5 Pokyny k obnovení ověřovacích mechanismů, jejichžplatnost vyprší, jsou uživateli zasílány s dostatečným předstihem, abymohly být provedeny před vypršením platnosti starého ověřovacíhomechanismu, a v případě potřeby nakonfigurujte automatické upomínky.
Požadavek V6.4.4 Pokud dojde ke ztrátě vícefaktorového faktoruověřování, bude provedeno prokázání totožnosti na stejné úrovni jako přiregistraci.
Požadavek V6.4.3 Je zaveden bezpečný proces obnovení zapomenutého hesla,který neobchází žádné povolené mechanismy vícefaktorového ověřování.
Požadavek V6.4.2 Aplikace neumožňuje nápovědy k heslům nebo ověřovánízaložené na znalostech (tzv. “tajné otázky”).
Požadavek V6.4.1 Jsou-li systémem generovaná počáteční hesla neboaktivační kódy, jsou vždy bezpečně náhodně generovány, řídí sestávajícími zásadami pro hesla a zda jejich platnost vyprší po krátkédobě nebo po prvním použití. Tato počáteční tajemství se nesmí státdlouhodobým heslem.
Požadavek V6.3.8 Ověřeno, že z neúspěšných výzev k ověření nelze odvoditplatné uživatele, například na základě chybových zpráv, kódů odpovědiHTTP nebo různých časů odezvy. Tuto ochranu musí mít i funkce registracea zapomenutého hesla.
Požadavek V6.3.7 Uživatelé jsou vždy informováni o aktualizacíchověřovacích údajů, například o resetování pověření nebo změněuživatelského jména či e-mailové adresy.
Požadavek V6.3.6 E-mailová adresa se nepoužívá jako jednofaktorový nebovícefaktorový ověřovací mechanismus.
Požadavek V6.3.5 Uživatelé jsou informováni o podezřelých pokusech oověření (úspěšných nebo neúspěšných). Může jít o pokusy o ověření zneobvyklého místa nebo klienta, částečně úspěšné ověření (pouze jeden zvíce faktorů), pokus o ověření po dlouhé době nečinnosti nebo úspěšnéověření po několika neúspěšných pokusech.
Požadavek V6.3.4 Pokud aplikace obsahuje více způsobů ověřování,neexistují žádné nedokumentované způsoby a zda jsou kontroly zabezpečenía síla ověření důsledně vynucovány.
Požadavek V6.3.3 Pro přístup k aplikaci je nutné použít buďvícefaktorový ověřovací mechanismus, nebo kombinaci jednofaktorovýchověřovacích mechanismů. V případě L3 musí být jedním z faktorůhardwarový ověřovací mechanismus, který zajišťuje odolnost protikompromitaci a zosobnění proti phishingovým útokům a zároveň ověřujezáměr ověřit totožnost tím, že vyžaduje akci iniciovanou uživatelem(například stisknutí tlačítka na hardwarovém klíči FIDO nebo mobilnímtelefonu). Zmírnění jakýchkoli úvah v tomto požadavku vyžaduje plnězdokumentované zdůvodnění a komplexní soubor zmírňujících kontrol.
Požadavek V6.3.2 Pro přístup k aplikaci je nutné použít mechanismusvícefaktorového ověřování nebo kombinaci mechanismů jednofaktorového avícefaktorového ověřování. U L3 musí být jedním z faktorů hardwarovýověřovací mechanismus, který poskytuje ohrožení zabezpečení a odolnostproti phishingovým útokům a zároveň ověřuje záměr ověřit tím, ževyžaduje akci iniciovanou uživatelem (jako je stisknutí tlačítka nahardwarovém klíči FIDO nebo mobilním telefonu). Zmírnění jakýchkoliaspektů v tomto požadavku vyžaduje plně zdokumentované zdůvodnění akomplexní sadu zmírňujících kontrol.
Požadavek V6.3.1 V souladu s dokumentací k zabezpečení aplikace jsouimplementovány mechanismy zabraňující útokům, jako je credentialstuffing a brutal force.”Ověřte, zda v aplikaci nejsou přítomny nebojsou zakázány výchozí uživatelské účty (např. “root”, “admin” nebo“sa”).
Požadavek V6.2.12 Ověřeno, že jsou hesla odeslaná během registrace účtunebo změny hesla porovnána se sadou prolomených hesel.
Požadavek V6.2.11 Využitý a zdokumentovaný seznam kontextověspecifických slov použit k zabránění vytváření snadno uhodnutelnýchhesel.
Požadavek V6.2.10 Heslo uživatele zůstává platné, dokud se nezjistí, žebylo ohroženo, nebo dokud ho uživatel nezmění. Aplikace nesmí vyžadovatpravidelnou rotaci přihlašovacích údajů.
Požadavek V6.2.9 Ověřeno, zda jsou povolena hesla o délce alespoň 64znaků.
Požadavek V6.2.8 Ověřeno, že aplikace ověřuje heslo uživatele přesnětak, jak bylo přijato od uživatele, bez jakýchkoli úprav, jako jezkrácení nebo transformace velkých a malých písmen.
Požadavek V6.2.7 Je povolena funkce “vložení”, pomocníci heselprohlížeče a externí správci hesel.
Požadavek V6.2.6 Ověřeno, že pole pro zadání hesla používají k maskovánípoložky značku type=password. Aplikace mohou uživateli umožnit dočasnézobrazení celého maskovaného hesla nebo posledního zadaného znaku hesla.
Požadavek V6.2.5 Ověřeno, že lze použít hesla libovolné znakové sady,aniž by pravidla omezovala povolený typ znaků. Nesmí existovat žádnýpožadavek na minimální počet velkých nebo malých písmen, číslic nebospeciálních znaků.
Požadavek V6.2.4 Hesla odeslaná během registrace účtu nebo změny heslajsou porovnána s dostupnou sadou alespoň 3000 nejčastějších hesel, kteráodpovídají zásadám pro hesla aplikace, např. minimální délka.
Požadavek V6.2.3 Ověřeno, , žefunkce změny hesla vyžaduje aktuální anové heslo uživatele.
Požadavek V6.2.2 Ověřeno, že uživatelé mohou vždy změnit své heslo.
Požadavek V6.2.1 Ověřeno, že hesla nastavená uživatelem mají vynucenědélku alespoň 8 znaků, i když se důrazně doporučuje minimálně 15 znaků.
Požadavek V6.1.3 Pokud aplikace obsahuje více cest ověřování, jsouvšechny zdokumentovány společně s ovládacími prvky zabezpečení a silouověřování, které je nutné v nich důsledně vynucovat.
Požadavek V6.1.2 Je interně zdokumentován a uveden seznam kontextověspecifických slov za účelem prevence jejich použití v heslech. Seznammůže obsahovat permutace názvů organizace, názvů produktů, systémovýchidentifikátorů, kódových názvů projektů, názvů oddělení nebo rolí apodobně.
Požadavek V6.1.1 Dokumentace aplikace definuje způsob použití kontroljako je omezování rychlosti, anti-automatizace a adaptivní odpověď proobranu proti útokům jako je credential stuffing a brute force útoky nahesla. Dokumentace musí jasně uvádět způsob konfigurace těchto kontrol aprevenci škodlivého uzamčení účtu.
Požadavek V5.4.3 Soubory získané z nedůvěryhodných zdrojů jsou skenoványantivirovými skenery, aby se zabránilo poskytování známého škodlivéhoobsahu.
Požadavek V5.4.2 Názvy souborů podávané (např. v polích hlaviček HTTPodpovědi nebo přílohách e-mailu) jsou zakódovány nebo sanitizovány(např. podle RFC 6266) za účelem zachování struktury dokumentu aprevence injection útoků.
Požadavek V5.4.1 Aplikace validuje nebo ignoruje uživatelem předloženénázvy souborů, včetně těch v JSON, JSONP nebo URL parametru, aspecifikuje název souboru v poli hlavičky Content-Disposition vodpovědi.
Požadavek V5.3.3 Zpracování souborů na straně serveru, jako jedekomprese souborů, ignoruje uživatelem poskytované informace o cestě,aby se zabránilo zranitelnostem jako je zip slip.
Požadavek V5.3.2 Pokud aplikace vytváří cesty k souborům pro souborovéoperace, místo uživatelem předložených názvů souborů používá interněgenerovaná nebo důvěryhodná data, nebo pokud musí být použity uživatelempředložené názvy souborů či metadata souborů, musí být aplikována přísnávalidace a sanitizace. Toto je ochrana proti útokům procházení cest,lokálního nebo vzdáleného zahrnutí souborů (LFI, RFI) a server-siderequest forgery (SSRF).
Požadavek V5.3.1 Soubory nahrané, nebo vygenerované nedůvěryhodnýmvstupem a uložené ve veřejné složce nejsou při přímém přístupu HTTPpožadavkem spouštěny jako kód programu na straně serveru.
Požadavek V5.2.6 Ověřeno, že aplikace odmítá nahrané obrázky s velikostív pixelech větší než je maximální povolená, aby se zabránilo útokůmzahlcením pixely.
Požadavek V5.2.5 Ověřeno, že aplikace nepovolí nahrávání komprimovanýchsouborů obsahujících symbolické odkazy, pokud to není specifickypožadováno (v takovém případě bude nutné vynucovat seznam povolenýchsouborů, na které lze vytvořit symbolické odkazy).
Požadavek V5.2.4 Ověřeno, že je vynucována kvóta velikosti souborů amaximální počet souborů na uživatele, aby se zajistilo, že jedenuživatel nemůže zaplnit úložiště příliš mnoha soubory nebo nadměrněvelkými soubory.
Požadavek V5.2.3 Před rozbalením souboru aplikace kontrolujekomprimované soubory (např. zip, gz, docx, odt) proti maximální povolenénekomprimované velikosti a proti maximálnímu počtu souborů.
Požadavek V5.2.2 Když aplikace přijme soubor, ať už samostatně nebo varchivu, například v souboru ZIP, zkontroluje, zda přípona souboruodpovídá očekávané příponě souboru, a ověří, zda obsah odpovídá mime atypu reprezentovanému příponou. To zahrnuje kontrolu počátku sobouru,zjištění přepisování obrázků a používání specializovaných knihoven proověřování obsahu souborů. V případě L1 se to může zaměřit pouze nasoubory, které se používají ke konkrétním obchodním nebo bezpečnostnímrozhodnutím. Pro L2 a vyšší to musí platit pro všechny přijímanésoubory.
Požadavek V5.2.1 Aplikace přijímá pouze soubory o velikosti, kterou můžezpracovat, aniž by došlo ke ztrátě výkonu, nebo odmítnutí služby.
Požadavek V5.1.1 Dokumentace definuje povolené typy souborů, očekávanépřípony souborů a maximální velikost (včetně velikosti rozbaleného) prokaždou funkci odesílání. Dále se ujistěte, že dokumentace specifikuje,jak mají být soubory bezpečně staženy a zpracovány koncovými uživateli,například jak se aplikace chová při zjištění škodlivého souboru.
Požadavek V4.4.4 Při přechodu existující relace HTTPS na kanál WebSocketjsou vyhrazené tokeny správy relací WebSocket nejprve získány a ověřenyv rámci dříve ověřené relace HTTPS.
Požadavek V4.4.3 V případě, že nelze použít standardní správu relacíaplikace, jsou k tomu pouze použity určené tokeny , které splňujípříslušné požadavky na zabezpečení správy relací.
Požadavek V4.4.2 Ověřeno, že je během prvotního volání metody handshakeprotokolu HTTP WebSocket pole hlavičky povoleno pouze proti seznamuzdrojů povolených pro danou aplikaci.
Požadavek V4.4.1 Ověřeno, že se pro všechna připojení WebSocket používáprotokol WebSocket přes protokol TLS (WSS).
Požadavek V4.3.2 Tzv. introspekční dotazy GraphQL v produkčním prostředízakázány, pokud není rozhraní GraphQL API určeno pro použití jinýmistranami.
Požadavek V4.3.1 Ověřeno, že se používá seznam povolených dotazů, depthlimiting, amount limiting, nebo query cost analysis k zabránění GraphQLnebo výrazu odmítnutí služby (DoS) v důsledku nákladných vnořenýchdotazů.
Požadavek V4.2.5 Ověřeno, že pokud aplikace (back-end nebo front-end)sestavuje a odesílá požadavky, používá pokaždé ověřování, sanitizacinebo jiné mechanismy, aby se vyhnula vytváření identifikátorů URI(například pro volání rozhraní API) nebo polí hlaviček požadavků HTTP(například autorizace nebo soubor cookie), které jsou příliš dlouhé nato, aby je přijímající komponenta přijala. To může způsobit odmítnutíslužby, například při odesílání příliš dlouhého požadavku (např.dlouhého pole hlavičky cookie), což má za následek, že server vždyodpoví chybovým stavem.
Požadavek V4.2.4 Ověřeno, že aplikace přijímá pouze požadavky HTTP/2 aHTTP/3, kde pole a hodnoty záhlaví neobsahují žádné sekvence CR (\r), LF(\n) nebo CRLF (\r\n), abyste zabránili útokům prostřednictvím injektážehlaviček.
Požadavek V4.2.3 Ověřeno, že aplikace neodesílá ani nepřijímá zprávyHTTP/2 nebo HTTP/3 s poli záhlaví specifickými pro připojení, jako jeTransfer-Encoding, aby se zabránilo rozdělení odpovědí a útokůmprostřednictvím injektáže hlaviček.
Požadavek V4.2.2 Ověřeno, že při generování zpráv HTTP není pole záhlavíContent-Length v konfliktu s délkou obsahu určenou rámcem protokoluHTTP, aby se zabránilo útokům na pašování požadavků.
Požadavek V4.2.1 Ověřeno, že všechny součásti aplikace (včetně nástrojůpro vyrovnávání zatížení, bran firewall a aplikačních serverů) určujíhranice příchozích zpráv HTTP pomocí vhodného mechanismu pro verzi HTTP,aby se zabránilo přenosu požadavků HTTP. Pokud je v protokolu HTTP/1.xpřítomno pole hlavičky Transfer-Encoding, musí být hlavičkaContent-Length ignorována podle RFC 2616. Pokud je při použití protokoluHTTP/2 nebo HTTP/3 přítomno pole záhlaví Content-Length, musí příjemcezajistit, aby bylo konzistentní s délkou datových rámců.
Požadavek V4.1.5 Ověřeno, že se digitální podpisy pro jednotlivé zprávypoužívají k poskytnutí dodatečného zajištění ochrany přenosu propožadavky nebo transakce, které jsou vysoce citlivé nebo procházejířadou systémů.
Požadavek V4.1.4 Ověřeno, že lze použít pouze metody HTTP, které jsouvýslovně podporovány aplikací nebo jejím rozhraním API (včetně funkceOPTIONS během předvýstupních požadavků), a zda jsou nepoužívané metodyblokovány.
Požadavek V4.1.3 Ověřeno, že žádné pole záhlaví HTTP používané aplikacía nastavené zprostředkující vrstvou, jako je nástroj pro vyrovnávánízatížení, webový proxy server nebo back-endová služba front-end, nemůžekoncový uživatel přepsat. Příklady hlaviček mohou zahrnovat X-Real-IP,X-Forwarded-* nebo X-User-ID.
Požadavek V4.1.2 Ověřeno, že se z protokolu HTTP na HTTPS automatickypřesměrovávají pouze koncové body orientované na uživatele (určené proruční přístup z webového prohlížeče), zatímco jiné služby nebo koncovébody transparentní přesměrování neimplementují. Předejde se tak situaci,kdy klient chybně odesílá nešifrované HTTP požadavky, ale protože jsoupožadavky automaticky přesměrovány na HTTPS, únik citlivých dat zůstaneneodhalen.
Požadavek V4.1.1 Ověřeno, že každá odpověď HTTP s textem zprávy obsahujepole záhlaví Content-Type, které odpovídá skutečnému obsahu odpovědi,včetně parametru charset pro určení bezpečného kódování znaků (např.UTF-8, ISO-8859-1) podle typů médií IANA, například “text/”, “/+xml” a“/xml”.
Požadavek V3.7.5 Ověřeno, že se aplikace v oblasti bezpečnosti chovápodle dokumentace (například upozornění uživatele nebo blokovánípřístupu), pokud prohlížeč použitý pro přístup k aplikaci nepodporujeočekávané funkce zabezpečení.
Požadavek V3.7.4 Ověřeno, že je doména nejvyšší úrovně aplikace (např.site.tld) přidána do veřejného seznamu předběžných načtení pro protokolHTTP Strict Transport Security (HSTS). Tím se zajistí, že použitíprotokolu TLS pro aplikaci bude integrováno přímo do hlavních prohlížečůa nebude se spoléhat pouze na pole hlavičky odpovědiStrict-Transport-Security.
Požadavek V3.7.3 Aplikace zobrazuje upozornění, když je uživatelpřesměrován na adresu URL mimo kontrolu aplikace, s možností zrušitnavigaci uživatelem.
Požadavek V3.7.2 Pokud aplikace automaticky přesměruje uživatele pouzena jiný název hostitele nebo doménu (která není řízena aplikací), jde oje cíl, který je uveden na seznamu povolených domén a hostitelů.
Požadavek V3.7.1 Ověřeno, že aplikace používá pouze technologie nastraně klienta, které jsou stále podporovány a považovány za bezpečné.Mezi technologie, které tento požadavek nesplňují, patří napříkladzásuvné moduly NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL neboaplety Java na straně klienta.
Požadavek V3.6.1 Datové zdroje na straně klienta, jako jsou knihovnyJavaScriptu, šablony stylů CSS nebo webová písma, jsou hostovány externě(např. v síti Content Delivery Network) pouze v případě, že jeprostředek statický a má konkrétní verzi a k ověření integrity datovéhozdroje se používá integrita dílčího prostředku (SRI). Pokud to nenímožné, mělo by existovat zdokumentované bezpečnostní rozhodnutí, kteréto pro každý zdroj odůvodní.
Požadavek V3.5.8 Ověřené prostředky (například obrázky, videa, skripty adalší dokumenty) lze načíst nebo vložit jménem uživatele pouze vpřípadě, že je to zamýšleno. Toho lze dosáhnout přísným ověřením polízáhlaví požadavku HTTP Sec-Fetch-*, aby se zajistilo, že požadaveknepochází z nevhodného volání mezi zdroji, nebo nastavenímrestriktivního pole záhlaví odpovědi HTTP Cross-Origin-Resource-Policy,které dá prohlížeči pokyn k blokování vráceného obsahu.
Požadavek V3.5.7 Ověřeno, že data vyžadující autorizaci nejsou zahrnutav odpovědích na prostředky skriptu, jako jsou soubory JavaScript, aby sezabránilo útokům XSSI (Cross-Site Script Inclusion).
Požadavek V3.5.6 Nikde v aplikaci není povolena funkce JSONP, abynedocházelo k útokům XSSI (Cross-Site Script Inclusion).
Požadavek V3.5.5 Ověřeno, zda jsou zprávy přijaté rozhraním postMessagevždy odmítnuty a zahozeny, pokud původ zprávy není důvěryhodný nebopokud je syntaxe zprávy neplatná.
Požadavek V3.5.4 Samostatné aplikace jsou hostovány na různých názvechhostitelů, aby se využila omezení stanovená zásadami stejného původu,včetně toho, jak mohou dokumenty nebo skripty načtené jedním zdrojeminteragovat se zdroji z jiného zdroje a omezení souborů cookie nazákladě názvu hostitele.
Požadavek V3.5.3 Ppožadavky HTTP na citlivé funkce používají vhodnémetody HTTP, jako jsou POST, PUT, PATCH nebo DELETE, a nikoli metodydefinované ve specifikaci HTTP jako “bezpečné”, jako jsou HEAD, OPTIONSnebo GET. Alternativně lze použít přísné ověření polí záhlaví požadavkuSec-Fetch-*, aby se zajistilo, že požadavek nepochází z nevhodnéhovolání mezi zdroji, požadavku na navigaci nebo zatížení zdroje(například zdroje obrázku), pokud se to neočekává.
Požadavek V3.5.2 Pokud aplikace spoléhá na mechanismus kontroly předvýstupem CORS, aby zabránila nepovolenému použití citlivých funkcí mezizdroji, není možné volat tuto funkci s požadavkem, který neaktivujepožadavek CORS-preflight. To může vyžadovat kontrolu hodnot v políchzáhlaví požadavku “Origin” a “Content-Type” nebo použití dalšího polezáhlaví, které není polem záhlaví chráněným CORS.
Požadavek V3.5.1 Pokud aplikace nespoléhá na mechanismus kontroly předvýstupem CORS, který brání nepovoleným žádostem mezi zdroji o použitícitlivých funkcí, jsou tyto požadavky ověřeny, aby se zajistilo, žepocházejí ze samotné aplikace. To lze provést pomocí a ověření tokenůproti padělání nebo vyžadováním dalších polí hlaviček HTTP, která nejsouuvedena v seznamu záhlaví požadavků bezpečných CORS.
Požadavek V3.4.8 Ověřeno, zda všechny odpovědi HTTP, které iniciujívykreslování dokumentu (například odpovědi s textem/html typu obsahu),obsahují pole záhlaví Cross-Origin-Opener-Policy s direktivousame-origin nebo direktivou same-origin-allow-popups podle potřeby. Tímse zabrání útokům, které zneužívají sdílený přístup k objektům okna,jako je tabnabbing a počítání snímků.
Požadavek V3.4.7 Ověřeno, zda je v poli záhlaví Content-Security-Policyuvedeno místo, kde lze nahlásit porušení bezpečnosti a incident a jakýje kontakt pro nahlášení.
Požadavek V3.4.6 Aplikace používá direktivu frame-ancestors polehlavičky Content-Security-Policy pro každou odpověď HTTP, abystezajistili, že ji ve výchozím nastavení nelze vložit a že vkládáníkonkrétních prostředků je povoleno pouze v případě potřeby. Všimněte si,že pole záhlaví X-Frame-Options, i když je podporováno prohlížeči, jezastaralé a nelze se na něj spoléhat.
Požadavek V3.4.5 Aplikace nastavuje zásady odkazování, aby se zabrániloúniku technicky citlivých dat do služeb třetích stran prostřednictvímpole hlavičky požadavku HTTP “Referer”. To lze provést pomocí polehlavičky odpovědi HTTP Referrer-Policy nebo pomocí atributů elementuHTML. Citlivá data mohou obsahovat cestu a dotaz v URL a u interníchneveřejných aplikací také název hostitele.
Požadavek V3.4.4 Ověřeno, že všechny odpovědi HTTP obsahují pole záhlavíX-Content-Type-Options: nosniff. To dává prohlížečům pokyn, aby prodanou odpověď nepoužívaly čichání obsahu a odhadování typu MIME a abyvyžadovaly, aby hodnota pole hlavičky Content-Type odpovědi odpovídalacílovému prostředku. Například odpověď na požadavek na styl je přijatapouze v případě, že typ obsahu odpovědi je ‘text/css’. To také umožňujepoužívat funkci Cross-Origin Read Blocking (CORB) prohlížečem.
Požadavek V3.4.3 Ověřeno, že odpovědi HTTP obsahují pole hlavičkyodpovědi Content-Security-Policy, které definuje direktivy, kterézajistí, že prohlížeč načte a spustí pouze důvěryhodný obsah neboprostředky, aby se omezilo spouštění škodlivého JavaScriptu. Minimálněje nutné použít globální zásadu, která obsahuje direktivy object-src‘none’ a base-uri ‘none’ a definuje buď seznam povolených, nebo používáhodnoty nonce nebo hashe. Pro aplikaci L3 musí být definována zásada projednotlivé odpovědi s hodnotou nonce nebo hash.
Požadavek V3.4.2 Ověřeno, že pole hlavičky Access-Control-Allow-Originsdílení prostředků mezi zdroji (CORS) je pevnou hodnotou aplikace, nebože je použita hodnota pole hlavičky požadavku HTTP Původ, je ověřenopodle seznamu povolených důvěryhodných zdrojů. Pokud je třeba použít“Access-Control-Allow-Origin: *”, ověřte, že odpověď neobsahuje žádnécitlivé informace.
Požadavek V3.4.1 Ověřeno, že pole hlavičky Strict-Transport-Security jezahrnuto do všech odpovědí, aby se vynutila zásada HTTP Strict TransportSecurity (HSTS). Musí být definováno maximální stáří alespoň 1 rok a proL2 a vyšší se zásady musí vztahovat i na všechny subdomény.
Požadavek V3.3.5 Ověřeno, že když aplikace zapisuje soubor cookie, názevsouboru cookie a délka hodnoty nejsou větší než 4096 bajtů. Příliš velkésoubory cookie prohlížeč neukládá, a proto je neodesílá s požadavky, cožuživateli brání v používání funkcí aplikace, které jsou na tomto souborucookie závislé.
Požadavek V3.3.4 Ověřeno, že pokud hodnota souboru cookie není určena kpřístupu pro skripty na straně klienta (například token relace), má vždytakový mít soubor cookie nastaven atribut “HttpOnly” a stejná hodnota(např. token relace) musí být přenesena klientovi pouze prostřednictvímpole záhlaví “Set-Cookie”.
Požadavek V3.3.3 Ověřeno, že všechny soubory cookie mají pro názevsouboru cookie předponu “__Host-“, pokud nejsou výslovně navrženy prosdílení s jinými hostiteli.
Požadavek V3.3.2 Ověřeno, že hodnota atributu každého souboru cookieSameSite je nastavena podle účelu souboru cookie, aby se omezilovystavení útokům na ovlivnění uživatelského rozhraní a útokům napadělání požadavků na základě prohlížeče, které se běžně označují jakopadělání požadavků mezi weby (CSRF).
Požadavek V3.3.1 Ověřeno, že všechny soubory cookie mají nastavenatribut “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.2.3 Ověřeno, že se aplikace vyhýbá přetěžování modelu DOMpři použití JavaScriptu na straně klienta použitím explicitníchdeklarací proměnných, prováděním přísné kontroly typu, vyhýbáním seukládání globálních proměnných na objekt dokumentu a implementacíizolace oboru názvů.
Požadavek V3.2.2 Ověřeno, že obsah, který má být zobrazen jako text, anikoli jako HTML, je zpracováván pomocí bezpečných funkcí vykreslování(například createTextNode nebo textContent), aby se zabránilo nechtěnémuspuštění obsahu, jako je HTML nebo JavaScript.
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 vnesprávném kontextu (např. když je přímo požadováno rozhraní API, soubornahraný uživatelem nebo jiný zdroj). Mezi možné ovládací prvky mohoupatř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 nebopoužití typu dispozice přílohy v poli záhlaví Content-Disposition.
Požadavek V3.1.1 V dokumentaci k aplikaci jsou uvedeny očekávané funkcezabezpečení, které musí prohlížeče používající aplikaci podporovat(například HTTPS, HSTS (HTTP Strict Transport Security), ContentSecurity Policy (CSP) a další relevantní mechanismy zabezpečení HTTP).Musí také definovat, jak se aplikace musí chovat, když některé z těchtofunkcí nejsou k dispozici (například varování uživatele nebo blokovánípřístupu).
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í.
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éstk 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ýchzdrojů.
Požadavek V2.3.5 Ověřeno, že všechny toky byznysové logiky s vysokouhodnotou vyžadují schválení více uživateli, aby se zabrániloneoprá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 nebobezpečnostní opatření ve výrobě.
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.3 Ověřeno, že jednotlivé transakce jsou používány naúrovni logiky tak, aby byla daná operace úspěšná v plném rozsahu, nebobyla vrácena zpět do předchozího správného stavu.
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.1 Aplikace bude zpracovávat pouze toky pro logiku prostejného uživatele v očekávaném sekvenčním pořadí kroků a bez přeskočeníkroků.
Požadavek V2.2.3 Aplikace zajišťuje, že kombinace souvisejících datovýchpoložek jsou přiměřené podle předem definovaných pravidel.
Požadavek V2.2.2 Aplikace navržena tak, aby vynucovala ověřování vstupuna straně serveru služby. I když ověřování na straně klienta zlepšujepoužitelnost a mělo by být podporováno, nesmí se na něj spoléhat jako naovládací prvek zabezpečení.
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 seznamupovolených hodnot, vzorů a rozsahů, nebo je založeno na porovnání vstupus očekávanou strukturou a logickými limity podle předem definovanýchpravidel. V případě L1 se může zaměřit na vstup, který se používá kekonkrétním obchodním nebo bezpečnostním rozhodnutím. Pro L2 a vyšší byto mělo platit pro všechny vstupy.
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 proglobální vstupy a použití v rámci celé aplikace.
Požadavek V2.1.2 Dokumentace k aplikaci definuje, jak ověřit logickou akontextovou konzistenci kombinovaných datových položek, jako jenapříklad kontrola shody předměstí a PSČ.
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 číslakreditních karet, e-mailové adresy, telefonní čísla, nebo se může jednato interní datový formát.
Požadavek V1.5.3 Všechny různé analyzátory používané v aplikaci prostejný datový typ (např. analyzátory JSON, analyzátory XML, analyzátoryURL), 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 jsouchyby zabezpečení interoperability JSON nebo zneužití jinéhoidentifikátoru URI nebo chování analýzy souborů při útocích vzdálenéhozačlenění souborů (RFI) nebo SSRF (Server-side Request Forgery).
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ů neboomezení typů objektů definovaných klientem, aby se zabránilo útokůmdeserializace. Mechanismy deserializace, které jsou explicitnědefinovány jako nezabezpečené, nesmí být použity s nedůvěryhodnýmvstupem.
Požadavek V1.5.1 aplikace konfiguruje XML parsery s restriktivnímnastavení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.4.3 Ověřeno, že se dynamicky alokovaná paměť a prostředkysprá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 azranitelnostem typu use-after-free.
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.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 neboprevenci přetečení zásobníku, vyrovnávací paměti nebo integer-overflow.
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ý vstupočištěn, aby se zmírnily útoky ReDoS nebo Runaway Regex.
Požadavek V1.3.11 Ověřeno, že aplikace před předáním do poštovníchsysté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.10 V každém případě jsou formátovací řetězce, které by sepři použití mohly přeložit neočekávaným nebo škodlivým způsobem, předzpracováním dezinfikovány.
Požadavek V1.3.9 Ověřeno, že aplikace před odesláním do memcachedezinfikuje obsah, aby se zabránilo útokům prostřednictvím injektáže.
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, abyzabránila útokům prostřednictvím injektáže JNDI.
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éhovstupu. Pokud neexistuje žádná alternativa, musí být jakýkolinedůvěryhodný vstup, který je dynamicky zahrnut během vytváření šablony,upraven nebo omezen.
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 protiseznamu 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.5 Aplikace dezinfikuje nebo zakazuje uživatelemposkytnutý skriptovatelný obsah pro jazyky výrazů, jako jsou Markdown,CSS nebo XSL styly, BBCode nebo podobně.
Požadavek V1.3.4 Uživatelem zadaný skriptovatelný obsah SVG (ScalableVector Graphics) je vždy prověřen nebo upraven tak, aby obsahoval pouzeznačky a atributy (například kreslenou grafiku), které jsou pro aplikacibezpečné, např. neobsahují skripty a foreignObject.
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, aoříznutí vstupu, který je příliš dlouhý.
Požadavek V1.3.2 Aplikace nepoužívá a neumožňuje funkce eval() nebojiných funkcí pro dynamické spouštění kódu, jako je jazyk SpEL (SpringExpression Language).
Požadavek V1.3.1 Veškerý nedůvěryhodný vstup HTML z editorů WYSIWYG nebopodobný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.2.10 Aplikace je chráněna proti zneužití souboru CSV ainjekci vzorce. Aplikace při exportu obsahu CSV dodržuje pravidlauvozovací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říkladXLS, XLSX nebo ODF) aplikace správně uvozuje speciální znaky.
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.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ýchpříkazů.
Požadavek V1.2.7 Ověřeno, že je aplikace chráněna proti útokůmprostřednictvím injektáže XPath pomocí parametrizace dotazů nebopředkompilovaných dotazů.
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.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.4 Výběry dat nebo databázové dotazy (např. SQL, HQL,NoSQL, Cypher) používají parametrizované dotazy, ORM, entity frameworkynebo jsou jinak chráněny před injektáží SQL a dalšími útokyprostřednictvím injektáže databáze. Zajištěno, že je také realizovánopři psaní programových procedur.
Požadavek V1.2.3 Ověřeno, že se při dynamickém vytváření každého obsahuJavaScriptu (včetně JSON) používá kódování výstupu nebo escapování, abynedošlo ke změně struktury zprávy nebo dokumentu (aby nedocházelo kinjektáži JavaScriptu a JSON).
Požadavek V1.2.2 Ověřeno, že jsou při dynamickém vytváření adres URLnedůvěryhodná data kódována podle jejich kontextu (např. kódování URLnebo 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.1 Ověřeno, že je výstupní kódování pro odpověď HTTP,dokument HTML nebo dokument XML relevantní pro požadovaný kontext, jakoje 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.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.
Požadavek V1.1.1 Ověřeno, že vstup je dekódován nebo unescapen dokanonického tvaru pouze jednou, je dekódován pouze v případě, že jsouočekávána zakódovaná data v tomto tvaru, a že se to provádí před dalšímzpracováním vstupu, například se to neprovádí po ověření vstupu nebosanitizaci.
