Bezpečná standardní aplikace
Informace o produktu
Specifikace
- Název produktu: Standard bezpečných aplikací CSA
- Verze: 1.0
- Datum vydání: 10. ledna 2024
O Standardu
Standard bezpečných aplikací CSA je soubor pokynů a nejlepších
postupy pro implementaci bezpečnostních kontrol ověřování v
mobilní aplikace. Jeho cílem je zajistit bezpečnou autentizaci
mechanismy a chránit citlivá data před neoprávněným přístupem. The
standard je vyvíjen po konzultaci s různými organizacemi
a odborníky v oblasti kybernetické bezpečnosti.
Účel, rozsah a zamýšlené publikum
Účelem standardu bezpečné aplikace CSA je poskytovat
vývojářům s doporučeními a osvědčenými postupy pro implementaci
bezpečné autentizační kontroly v mobilních aplikacích. Standardní
je použitelný pro vývojáře a organizace zapojené do
vývoj mobilních aplikací, které vyžadují autentizaci. To
je navržen tak, aby zvýšil celkovou bezpečnost autentizace
zpracovávat a chránit soukromí uživatelů.
Upozornění a pokyny pro vývojáře
Standard bezpečných aplikací CSA poskytuje vývojářům návod
implementace bezpečnostních kontrol ověřování. Zdůrazňuje to
je důležité dodržovat osvědčené postupy v odvětví a zajistit
bezpečná implementace autentizačních mechanismů. Vývojáři
by měl odkazovat na normu pro podrobné pokyny k implementaci
doporučené bezpečnostní kontroly.
Definice dokumentu a normativní odkazy
Standard bezpečných aplikací CSA zahrnuje definice dokumentů a
normativní odkazy, které objasňují použitou terminologii
a odkazovat na další příslušné průmyslové normy a směrnice.
Vývojáři by se měli obrátit na tyto definice a odkazy pro a
lepší porozumění standardu.
Návod k použití produktu
Autentizace
Autentizace je nezbytnou součástí většiny mobilních zařízení
aplikací. Ověřuje identitu uživatelů, klientů,
aplikací a zařízení před udělením přístupu ke konkrétním
zdrojů nebo povolení určitých akcí. Standard bezpečné aplikace ČSA
poskytuje doporučení a osvědčené postupy pro implementaci secure
autentizační kontroly.
Bezpečnostní kontroly
Standard bezpečných aplikací CSA zahrnuje následující
autentizační bezpečnostní kontroly:
| ID | Řízení |
|---|---|
| AUTHN-BP01 | Aplikace používá k ověření vícefaktorové ověřování (MFA). vysoce rizikové transakce. |
| AUTHN-BP02 | Popis ovládání |
| AUTHN-BP03 | Popis ovládání |
| AUTHN-BP04 | Popis ovládání |
| AUTHN-BP05 | Popis ovládání |
| AUTHN-BP06 | Popis ovládání |
AUTHN-BP01 – Multi-Factor Authentication (MFA)
V tradičním jednofaktorovém autentizačním systému uživatelé
obvykle stačí zadat něco, co znáte (například uživatelská jména
a hesla). MFA však přidává další vrstvy ověřování identity
vyžadováním dalších faktorů, jako je Něco, co máte a
Něco-Ty-Jsi. Tím se stává náročnější pro zlomyslné
aktéry kompromitovat účty a zvyšuje celkovou bezpečnost
proces ověřování.
Pokyny pro implementaci
Vývojáři by měli implementovat Step-up MFA, což vyžaduje
další úroveň ověřování pro transakce s vyšším rizikem. The
Standard Safe App Standard společnosti CSA upřednostňuje následující MFA
kombinace:
- Něco-Vy-Víte
- Něco-ty-máš
- Něco-Ty-Jsi
Často kladené otázky (FAQ)
Otázka: Jaký je účel standardu bezpečných aplikací CSA?
Odpověď: Účelem standardu bezpečných aplikací CSA je poskytovat
vývojářům s doporučeními a osvědčenými postupy pro implementaci
bezpečné autentizační kontroly v mobilních aplikacích.
Otázka: Kdo je zamýšleným publikem bezpečné aplikace CSA
Norma?
Odpověď: Standard bezpečných aplikací CSA je určen pro vývojáře a
organizace zabývající se vývojem mobilních aplikací
které vyžadují ověření.
Otázka: Jaké jsou výhody implementace Multi-Factor
Autentizace (MFA)?
Odpověď: Implementace MFA přidává vrstvy ověřování identity, vytváření
pro zlomyslné aktéry je obtížnější kompromitovat účty a
zvýšení celkové bezpečnosti autentizačního procesu.
1
Standardní verze 1.0 bezpečné aplikace CSA vydaná 10. ledna 2024
2
Při konzultaci s:
Asociace bank Singapur, Stálý výbor pro kybernetický výbor Poradenství pro rizika v jihovýchodní Asii společnosti Deloitte Ernst & Young Advisory Pte. Ltd. KPMG v Singapuru Lazada Microsoft Singapur PricewaterhouseCoopers Risk Services Pte. Ltd.
Vyloučení odpovědnosti:
S těmito organizacemi byl standard konzultován za účelem zpětné vazby a připomínek k bezpečnostní kontrole, popisu bezpečnostní kontroly a pokynům k technické implementaci. V maximálním rozsahu povoleném zákonem nenesou CSA ani externí konzultanti odpovědnost za žádné nepřesnosti, chyby a/nebo opomenutí obsažené v tomto dokumentu ani za žádné ztráty nebo škody jakéhokoli druhu (včetně jakékoli ztráty zisku, obchodu, dobrého jména nebo reputace a/nebo jakékoli zvláštní, náhodné nebo následné škody) v souvislosti s jakýmkoli používáním tohoto standardu nebo spoléháním se na něj. Organizacím vyvíjejícím mobilní aplikace, poskytovatelům služeb a vývojářům se doporučuje, aby zvážily, jak může být standard aplikován na jejich konkrétní okolnosti, získaly vlastní právní a/nebo technické poradenství ve vztahu k obsahu a/nebo implementaci doporučení v organizacích vyvíjejících mobilní zařízení. aplikace, poskytovatelé služeb a vývojáři by měli uplatňovat odborný úsudek, zda a při implementaci doporučení ve standardu, a měli by také zvážit, zda jsou ve vztahu k jejich konkrétním okolnostem nezbytná další opatření.
3
Obsah
V konzultaci s: ………………………………………………………………………………………………………………………… 3 Prohlášení: … …………………………………………………………………………………………………………………………. 3 O standardu……………………………………………………………………………………………………………………… 6 Účel, Rozsah a zamýšlené publikum ………………………………………………………………………………………… 6 Upozornění a pokyny pro vývojáře …………………… …………………………………………………………………………. 7 Definice dokumentu a normativní odkazy ……………………………………………………………………………… 8 1. Autentizace ………………………………… ………………………………………………………………………… 10
AUTHN-BP01 …………………………………………………………………………………………………………………………………. 11 AUTHN-BP01a ………………………………………………………………………………………………………………………. 13 AUTHN-BP01b ………………………………………………………………………………………………………………………. 14 AUTHN-BP01c……………………………………………………………………………………………………………………….. 15
AUTHN-BP02 …………………………………………………………………………………………………………………………………. 16 AUTHN-BP03 …………………………………………………………………………………………………………………………………. 17
AUTHN-BP03a ………………………………………………………………………………………………………………………. 18 AUTHN-BP03b ………………………………………………………………………………………………………………………. 19 AUTHN-BP04 …………………………………………………………………………………………………………………………………. 20 AUTHN-BP05 …………………………………………………………………………………………………………………………………. 21 AUTHN-BP06 …………………………………………………………………………………………………………………………………. 22 ………………………………………………………………………………………………………………………………………… ……….. 23 2. Oprávnění ………………………………………………………………………………………………………………………… ….. 24 AUTHOR-BP01 ………………………………………………………………………………………………………………………… .. 25 AUTHOR-BP02 …………………………………………………………………………………………………………………………. 26 AUTHOR-BP03 ………………………………………………………………………………………………………………….. 27 AUTHOR-BP04 ………………………………………………………………………………………………………………………….. 28 ………………………………………………………………………………………………………………………………………… …….. 29 3. Ukládání dat (Data-at-Rest) ………………………………………………………………………………………………… …. 30 SKLADOVÁNÍ-BP01 …………………………………………………………………………………………………………………………. 31 SKLADOVÁNÍ-BP02 …………………………………………………………………………………………………………………………. 32 SKLADOVÁNÍ-BP02a ……………………………………………………………………………………………………………………. 33 SKLADOVÁNÍ-BP02b ……………………………………………………………………………………………………………………. 34 SKLADOVÁNÍ-BP03 …………………………………………………………………………………………………………………………. 35 ………………………………………………………………………………………………………………………………………… ……….. 36 4. Anti-Tampering & Anti-Reversing………………………………………………………………………………………………………..37 ODOLNOST-BP01 ………………… …………………………………………………………………………………………………. 38 ODOLNOST-BP02 ………………………………………………………………………………………………………………………. 39
4
ODOLNOST-BP03 ………………………………………………………………………………………………………………………. 41 ODOLNOST-BP04 ………………………………………………………………………………………………………………………. 42 ODOLNOST-BP05 ………………………………………………………………………………………………………………………. 43 ODOLNOST-BP06 ………………………………………………………………………………………………………………………. 44 ODOLNOST-BP07 ………………………………………………………………………………………………………………………. 45 Reference……………………………………………………………………………………………………………………………………………… 46
5
O Standardu
Úvod Standard Safe App Standard je doporučený standard pro mobilní aplikace (aplikace), vyvinutý Agenturou pro kybernetickou bezpečnost Singapuru (CSA) po konzultaci s průmyslovými partnery z finančních institucí, technologických organizací, poradenských firem a vládních agentur. Přesview Cílem standardu je předložit doporučenou základní linii bezpečnostních kontrol, kterou by měli vývojáři a poskytovatelé mobilních aplikací dodržovat. To by zajistilo, že všechny místní aplikace budou dodržovat podobnou sadu bezpečnostních kontrol pro mobilní aplikace, čímž se zvýší úroveň zabezpečení aplikací hostovaných a vytvořených v Singapuru.
Účel, rozsah a zamýšlené publikum
Tento dokument byl vyvinut, aby poskytoval doporučení a návrhy vývojářům, aby jim pomohl při implementaci funkcí zabezpečení do jejich aplikací. Taková doporučení a návrhy jsou zaměřeny na pomoc vývojářům při zmírňování širokého spektra kybernetických hrozeb a při ochraně jejich aplikací před nejnovějšími mobilními podvody a zneužitím mobilního malwaru. Obsah zde není závazný, je poskytován na základě nespolehlivosti a má být informativní povahy a není určen k vyčerpávající identifikaci potenciálních hrozeb kybernetické bezpečnosti, ani vyčerpávajícímu specifikaci procesů nebo systémů, které by vývojáři měli zavést, aby se vypořádali s takovýmito hrozbami nebo jim zabránili. hrozby. Verze 1 pokynů a bezpečnostních kontrol Safe App Standard se zaměří především na poskytování bezpečnostních pokynů vývojářům vysoce rizikových aplikací, aby čelili nejnovějšímu mobilnímu malwaru a podvodům, které lze pozorovat v singapurském prostředí hrozeb. Tyto ovládací prvky zabezpečení však mohou být také přínosné a mohou být implementovány jinými aplikacemi. Doporučuje se, aby se všichni vývojáři snažili implementovat tato opatření pro zvýšení bezpečnosti mobilních aplikací. Ačkoli je tento standard primární oblastí zájmu, budoucí iterace se rozšíří tak, aby se zabývaly nejlepšími bezpečnostními postupy a pokyny pro celou sadu mobilních aplikací.
6
Upozornění a pokyny pro vývojáře
Toto je živý dokument, který bude podroben review a periodicky revize. Stejně jako mnoho dalších zavedených standardů je standard Safe App Standard živým dokumentem, který bude pravidelně aktualizován, aby odpovídal aktuálnímu a vyvíjejícímu se prostředí hrozeb a novým vektorům útoků. Podívejte se prosím na CSA webstránky, aby zůstaly aktualizovány s nejnovější verzí standardu Safe App Standard a podle toho přizpůsobily bezpečnostní opatření a ovládací prvky. Tento standard je třeba číst ve spojení s a nenahrazuje, nemění ani nenahrazuje žádné právní, regulační nebo jiné povinnosti a povinnosti vývojářů a poskytovatelů aplikací, včetně těch, které vyplývají ze zákona o kybernetické bezpečnosti z roku 2018 a jakýchkoli podpůrných právních předpisů, kodexů praxe, standardy výkonu nebo písemné pokyny vydané v jejich rámci. Použití tohoto dokumentu a implementace zde uvedených doporučení také nezbavuje vývojáře a poskytovatele aplikace žádných takových závazků nebo povinností ani je automaticky nezbavuje. Obsah tohoto dokumentu není zamýšlen jako autoritativní prohlášení zákona ani jako náhrada za právní nebo jiné odborné rady. Pokyny pro vývojáře k bezpečnostnímu rámci Safe App Standard Pro usnadnění použití by si vývojáři měli uvědomit, že verze 1 standardu Safe App se zaměřuje na následující kritické oblasti a samotný dokument lze rozdělit do následujících podsekcí:
· Autentizace · Autorizace · Ukládání dat (Data-at-Rest) · Anti-Tamper & Anti-Reversing Tyto kritické oblasti jsou zahrnuty proto, aby byla zajištěna standardizace zabezpečení mobilních aplikací proti nejběžnějším vektorům útoků používaných zákeřnými aktéry v našem místním ekosystému. Standard Safe App Standard poskytuje jasnou a stručnou sadu bezpečnostních kontrol, pokynů a osvědčených postupů pro zvýšení bezpečnosti mobilních aplikací, které poskytují nebo umožňují vysoce rizikové transakce.
7
Definice dokumentu a normativní odkazy
Definice dokumentu Níže jsou uvedeny některé definice, které by vývojáři a čtenáři měli mít na paměti při používání tohoto dokumentu: Citlivá data Uživatelská data, jako jsou osobní identifikační údaje (PII) a ověřovací data, jako jsou přihlašovací údaje, šifrovací klíče, jednorázová hesla, biometrická data , bezpečnostní tokeny, certifikáty atd. Vysoce rizikové transakce zahrnují:
· Změny finančních funkcí některé napřampzahrnují mimo jiné registraci údajů o příjemci platby třetí strany, zvýšení limitu převodu prostředků atd.
· Zahájení finančních transakcí některé napřampMezi tyto druhy patří mimo jiné transakce s vysokou hodnotou finančních prostředků, převody finančních prostředků s vysokou hodnotou, transakce online kartou, přístup k přímému debetu, funkce ukládání peněz a dobíjení atd.
· Změny v konfiguraci zabezpečení aplikace, některé napřampMezi tyto činnosti patří mimo jiné deaktivace metod ověřování, aktualizace digitálních tokenů nebo pověření atd.
Bezpečnostní kontroly Provozní nebo technická opatření doporučená v tomto dokumentu, která by měla být implementována pro řízení, monitorování a zmírňování potenciálních bezpečnostních slabin nebo incidentů. K těmto bezpečnostním kontrolám jsou připojena následující ID, např. AUTHN-BP01, AUTHOR-BP01, STORAGE-BP01, RESILIENCE-BP01. Normativní reference Standard Safe App odkazuje na průmyslové standardy z Open Web Projekt zabezpečení aplikací (OWASP), Agentura Evropské unie pro bezpečnost sítí a informací (ENISA) a Standard zabezpečení dat v odvětví platebních karet (PCI DSS). Seznam referencí je následující:
· OWASP MASVS (standard pro ověřování zabezpečení mobilních aplikací) · OWASP MASTG (Průvodce testováním zabezpečení mobilních aplikací) · Směrnice ENISA pro bezpečný vývoj (SSDG) · Bezpečnostní pokyny PCI DSS pro vývojáře pro přijímání mobilních plateb
8
9
1. Autentizace
Zavedení
Autentizace je nezbytnou součástí většiny mobilních aplikací. Tyto aplikace běžně využívají různé formy autentizace, včetně biometrických údajů, PINů nebo generátorů vícefaktorových ověřovacích kódů. Pro ověření identity uživatele je zásadní zajistit, aby byl ověřovací mechanismus bezpečný a implementovaný podle osvědčených postupů v oboru.
Implementací robustních bezpečnostních kontrol pro autentizaci mohou vývojáři zajistit, že pouze ověření uživatelé, klienti, aplikace a zařízení budou mít přístup ke konkrétním zdrojům nebo provádět určité akce. Prostřednictvím bezpečných autentizačních kontrol mohou vývojáři také zmírnit riziko neoprávněného přístupu k datům, udržovat integritu citlivých dat, chránit soukromí uživatelů a chránit integritu vysoce rizikových transakčních funkcí.
Kontroly v této kategorii mají za cíl doporučit kontroly zabezpečení autentizace, které by aplikace měla implementovat, aby ochránila citlivá data a zabránila neoprávněnému přístupu. Poskytuje také vývojářům relevantní osvědčené postupy pro implementaci těchto bezpečnostních kontrol.
bezpečnostní kontroly
ID
Řízení
AUTHN-BP01 AUTHN-BP01a AUTHN-BP01b AUTHN-BP01c AUTHN-BP02 AUTHN-BP03 AUTHN-BP03a AUTHN-BP03b AUTHN-BP04 AUTHN-BP05 AUTHN-BP06
K ověřování vysoce rizikových transakcí použijte vícefaktorovou autentizaci. Implementujte ověřování Something-You-Know jako jeden z faktorů MFA. Implementujte ověřování Something-You-Have jako jeden z faktorů MFA. Implementujte ověřování Something-You-Are jako jeden z faktorů MFA. K ověření použijte faktory založené na kontextu. Implementujte autentizaci zabezpečené relace. Implementujte zabezpečené stavové ověřování. Implementujte zabezpečené bezstavové ověřování. Implementujte zabezpečené ukončení relace během odhlášení, nečinnosti nebo uzavření aplikace. Implementujte ochranu hrubou silou pro ověřování. Implementujte mechanismus ověřování integrity transakcí.
10
AUTHN-BP01
Řízení
Aplikace používá Multi-Factor Authentication (MFA) k ověřování vysoce rizikových transakcí.
Popis
V tradičním jednofaktorovém autentizačním systému uživatelé obvykle potřebují pouze zadat něco, co víte1, jako jsou uživatelská jména a hesla. Pokud však tento jediný faktor selže nebo je kompromitován, je celý proces ověřování zranitelný vůči hrozbám.
MFA je autentizační procedura, která přidává vrstvy ověřování identity a vyžaduje nejen Něco-ty-znáš, ale také Něco-ty-máš2 a Něco-ty-jsi3. Implementace MFA ztěžuje zlovolným aktérům kompromitaci účtů a zvyšuje celkovou bezpečnost procesu ověřování.
Návod k implementaci
Vývojáři by měli používat Step-up MFA. Jedná se o specifický typ MFA, kde aplikace zahrnuje strategii ověřování, která vyžaduje další úroveň ověřování, zejména při pokusech o transakce s vyšším rizikem.
Vývojáři by měli upřednostnit následující kombinace MFA v pořadí 1, 2, 3 a 4, s možností 1 jako nejbezpečnější volbou.
Faktory / možnost Něco-ty-víš-něco-ty-máš
· Softwarový token · Hardwarový token · SMS OTP Something-You-Are
1
2
3
4
1 Something-You-Know odkazuje na informace, které uživatel zná, jako je PIN (Personal Identification Number), heslo nebo vzor atd. 2 Something-You-Have odkazuje na vlastnictví fyzického zařízení, aplikace nebo tokenu, které generuje autentizační pověření, která mohou zahrnovat časově podmíněná jednorázová hesla (OTP). PřampMezi tyto tokeny patří softwarové tokeny, hardwarové tokeny a SMS OTP. 3 Something-You-Are odkazuje na biometrické identifikátory, kde se k ověření používají jedinečné fyzické vlastnosti uživatele, jako jsou otisky prstů, skeny sítnice, rozpoznávání obličeje nebo rozpoznávání hlasu.
11
Vývojářům důrazně doporučujeme, aby se nespoléhali na SMS a e-mail OTP jako kanál pro ověřování vysoce rizikových transakcí. Pokud to není možné, je důležité implementovat biometrický faktor nebo další autentizační faktor ve spojení s SMS OTP a e-mailovým OTP. Věci k poznámce
· Pokud je to možné, důrazně se doporučuje volit standardní řešení. · Vývojáři by měli zajistit, aby byl na straně klienta ověřen alespoň jeden faktor MFA se všemi
ostatní ověřené na straně serveru. V případech, kdy je ověřování ověřeno na straně klienta, zejména pro Android, vynucujte kód založený na Trusted Execution Environment (TEE). · Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
o OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 21.
o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 51, 56. o MAS Technology Risk Management Guidelines (2021), str. 34, 50. o ENISA Smartphone Secure Development Guidelines (2016), str. 11.
12
AUTHN-BP01a Control Aplikace implementuje ověřování Something-You-Know jako jeden z faktorů MFA. Popis Something-You-Know představuje základní vrstvu ověření identity zahrnující informace známé pouze uživateli, jako je PIN (Personal Identification Number), heslo, vzor atd. Implementace Something-You-Know jako jednoho z MFA faktorů zajišťuje základní úroveň ověření identity, která vyžaduje, aby uživatelé poskytli jedinečné informace spojené s jejich účty. Je to zásadní faktor v principu „Něco-Vy-Znáte, Něco-Vy-Máte a Něco-Vy-Jste“, což přispívá ke komplexní a efektivní vícevrstvé bezpečnostní strategii. Pokyny k implementaci Vývojáři by měli při vytváření silných a bezpečných hesel přijmout následující pokyny:
· Zajistěte minimální délku hesla 12 znaků nebo více. · Zahrňte kombinaci velkých a malých písmen, číslic a speciálních znaků omezených na
~`! @#$%^&*()_-+=:;,.? Vývojáři by také měli rozpoznat a vyhnout se běžným nástrahám při vytváření hesel:
· Vyhněte se používání hádatelných slov, frází nebo kombinací. · Neuvádějte osobní údaje. · Vyvarujte se po sobě jdoucích znaků (např. „123456“) nebo opakovaných znaků (např. „aaaaa“). Věci k poznámce · Vývojáři by měli vynutit střídání pověření pouze u aktiv organizace nebo pokud neexistují
Implementace MFA na straně uživatele, např. změněná ročně nebo podle vhodného časového rámce. · Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Podívejte se prosím na dokumentaci(y)
obsaženo v: o MAS Technology Risk Management Guidelines (2021), str. 34. o ENISA Smartphone Secure Development Guidelines (2016), str. 10.
13
AUTHN-BP01b Control Aplikace implementuje ověřování Something-You-Have jako jeden z faktorů MFA. Popis Something-You-Have vyžaduje, aby se uživatelé autentizovali pomocí fyzického zařízení, aplikace nebo tokenu, který generuje ověřovací pověření, která mohou zahrnovat časově založená jednorázová hesla (OTP). PřampMezi tyto tokeny patří softwarové tokeny, hardwarové tokeny a SMS OTP. Implementace Something-You-Have jako jednoho z faktorů MFA zvyšuje složitost procesu autentizace tím, že vyžaduje vlastnictví hmatatelného prvku, což výrazně snižuje pravděpodobnost neoprávněného přístupu. Je to zásadní faktor v principu „Něco-Vy-Víte, Něco-Máte a Něco-Vy-Jste“, přispívající ke komplexní a efektivní vícevrstvé bezpečnostní strategii. Pokyny k implementaci Vývojáři by měli používat jednorázové heslo založené na čase pro softwarové tokeny, hardwarové tokeny a SMS OTP. Je třeba dodržovat následující pokyny:
· Jednorázové heslo by mělo být platné maximálně 30 s. · Jednorázové heslo, které je nesprávně zadáno po 3 pokusech, by mělo být zneplatněno a relace uživatele
by měla být zrušena nebo zamítnuta. Věci k poznámce
· Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Podívejte se prosím na dokumentaci poskytnutou v: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 56-57. o Směrnice řízení rizik technologie MAS (2021), str. 50, 51. o ENISA Smartphone Secure Development Guidelines (2016), str. 10.
14
AUTHN-BP01c
Kontrola Aplikace implementuje ověřování Something-You-Are jako jeden z faktorů MFA.
Popis Something-You-Are vyžaduje, aby se uživatelé autentizovali pomocí biometrických identifikátorů, jako jsou otisky prstů, skeny sítnice nebo rozpoznávání obličeje. Implementace Something-You-Are jako jednoho z MFA faktorů přidává vysoce personalizovaný a obtížně replikovatelný autentizační faktor. Poskytuje robustnější prostředky k ověření identity uživatele než faktory Něco-ty-víš a Něco-ty-máš, čímž se snižuje riziko neoprávněného přístupu. Je to zásadní faktor v principu „Něco-Vy-Víte, Něco-Vy-Máte a Něco-Vy jste“, který přispívá ke komplexní a efektivní vícevrstvé bezpečnostní strategii. Pokyny k implementaci Vývojáři by měli implementovat biometrické ověřování na straně serveru pomocí důvěryhodné platformy biometrické identifikace, jako je Singpass. Pokud to však není možné, vývojáři by měli implementovat biometrickou autentizaci na straně klienta prostřednictvím mechanismů Trusted Execution Environments (TEE) zařízení, jako jsou CryptoObject a Android Protected Confirmation pro Android nebo služby Keychain pro iOS. Věci k poznámce
· Vývojáři by měli omezit funkce aplikací na zařízeních bez hardwaru Trusted Executed Environment (TEE) nebo biometrie. NapřampZařízení Android bez TEE lze detekovat pomocí rozhraní Android API „isInsideSecureHardware“.
· Vývojáři by měli zrušit biometrické ověření, pokud dojde ke změnám v biometrickém mechanismu, jako je registrace nového otisku prstu na zařízení. Platformy iOS i Android podporují nastavení šifrovacího klíče aplikace, jehož platnost v reakci na takové změny vyprší.
· Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Podívejte se prosím na dokumentaci poskytnutou v: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 227233, 422-426. o Směrnice řízení rizik technologie MAS (2021), str. 51. o ENISA Smartphone Secure Development Guidelines (2016), str. 11, 26.
15
AUTHN-BP02
Ovládání Aplikace používá k ověření kontextové faktory. Popis Kontextové faktory zavádějí dynamické prvky, jako je poloha uživatele a atributy zařízení. Zatímco MFA poskytuje robustní vrstvu zabezpečení tím, že vyžaduje více faktorů autentizace, začlenění faktorů založených na kontextu vytváří komplexnější a adaptivnější proces autentizace, který může nabídnout další výhody při řešení vyvíjejících se rizik neoprávněného přístupu. Implementace kontextově založených faktorů minimalizuje spoléhání se na statické přihlašovací údaje, takže je pro zlomyslné aktéry obtížnější pokusit se o neoprávněný přístup. Pokyny k implementaci Vývojáři by měli při ověření identity uživatele zvážit následující kontextové faktory:
· Geolokace: Povolte přístup na základě skutečné polohy zařízení pomocí geolokace GPS, Wi-Fi nebo IP adresy.
· Typ zařízení: Povolení přístupu na základě vlastností zařízení. např. velikost obrazovky může určit, zda je zařízení smartphone nebo tablet.
Důležité poznámky Na tento ovládací prvek zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 56, 58. · ENISA Smartphone Secure Development Guidelines (2016), str. 11.
16
AUTHN-BP03
Kontrola Aplikace implementuje autentizaci zabezpečené relace. Popis Zabezpečená autentizace relace zajišťuje robustní správu relací pro stavovou i bezstavovou autentizaci. Špatně spravované relace, bez ohledu na to, zda aplikace používá stavové4 nebo bezstavové5 metody ověřování, mohou vést k bezpečnostním hrozbám, jako je neoprávněný přístup, únos relace nebo narušení dat. Implementace autentizace zabezpečené relace pro stavové relace využívá identifikátory zabezpečené relace, šifrovanou komunikaci a správné časové limity, aby se zabránilo neoprávněnému přístupu. U bezstavové autentizace zajišťuje, že tokeny jsou tampodolné, zachovává integritu ověřování bez spoléhání se na úložiště na straně serveru. Pokyny k implementaci Vývojáři by měli implementovat autentizaci zabezpečené relace přijetím následujících osvědčených postupů pro stavové (AUTHN-BP03a) a bezstavové (AUTHN-BP03b) metody autentizace pro relace. Důležité poznámky Na tento ovládací prvek zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 51-55. · Pokyny pro řízení technologických rizik MAS (2021), str. 51. · ENISA Smartphone Secure Development Guidelines (2016), str. 10. XNUMX.
4 Stavová autentizace se týká správy stavů relace na straně serveru, obvykle vyžaduje použití identifikátorů relace. 5 Bezstavové ověřování se týká správy relací bez ukládání informací souvisejících s uživatelem na straně serveru.
17
AUTHN-BP03a Control Aplikace implementuje bezpečné stavové ověřování. Popis Bezpečné stavové ověřování zahrnuje ochranu a udržování trvalých relací. Zatímco stavová autentizace poskytuje bezproblémovou uživatelskou zkušenost prostřednictvím trvalých uživatelských relací, může být zranitelná vůči různým bezpečnostním hrozbám, jako jsou například zlomyslní aktéři pokoušející se ukrást identifikátory relací. Implementace bezpečné stavové autentizace chrání uživatelské účty před neoprávněným přístupem a potenciálními zranitelnostmi spojenými se správou relací, aniž by byla ohrožena rovnováha mezi použitelností a bezpečností. Pokyny k implementaci Vývojáři by měli identifikovat koncové body na straně serveru, které odhalují citlivé informace nebo kritické funkce. Vývojáři by také měli přijmout následující doporučené postupy ověřování stavových relací:
· Odmítněte požadavky s chybějícími nebo neplatnými ID relace nebo tokeny. · Generujte ID relace náhodně na straně serveru, aniž byste je k nim připojovali URLs. · Vylepšete zabezpečení ID relace se správnou délkou a entropií, což ztěžuje hádání. · ID relací Exchange pouze přes zabezpečené připojení HTTPS. · Neukládejte ID relací do trvalého úložiště. · Ověřte ID relací pro přístup uživatelů k privilegovaným prvkům aplikace. · Ukončete relace na straně serveru a vymažte informace o relaci po vypršení časového limitu nebo odhlášení. Důležité informace Máte-li pochybnosti, zvažte použití důvěryhodných ověřovacích platforem a protokolů. Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 52.
18
AUTHN-BP03b Control Aplikace implementuje bezpečné bezstavové ověřování. Popis Bezpečné bezstavové ověřování zahrnuje postupy bezpečného tokenu pro efektivní a škálovatelné ověřování. I když bezstavové ověřování poskytuje výhody, může být zranitelnější vůči bezpečnostním hrozbám, jako je předstírání identity uživatele, pokud tokeny nejsou bezpečně generovány, přenášeny a ukládány. Implementace bezpečné bezstavové autentizace zajišťuje, že s každým autentizačním tokenem je bezpečně zacházeno a zároveň těží z výhod efektivity a škálovatelnosti, což snižuje riziko neoprávněného přístupu. Pokyny k implementaci Vývojáři by měli přijmout následující doporučené postupy pro ověřování bezstavových relací:
· Generujte tokeny na straně serveru, aniž byste je připojovali URLs. · Vylepšete zabezpečení tokenů správnou délkou a entropií, což ztěžuje hádání. · Výměna tokenů pouze přes zabezpečené připojení HTTPS. · Ověřte, že v tokenech nejsou vložena žádná citlivá data, jako jsou PII. · Vyhněte se ukládání tokenů do trvalého úložiště. · Ověřte tokeny pro uživatelský přístup k prvkům privilegované aplikace. · Ukončení tokenů na straně serveru, odstranění informací o tokenech po vypršení časového limitu nebo odhlášení. · Kryptograficky podepisujte tokeny pomocí zabezpečeného algoritmu, vyhněte se použití nulových algoritmů. Důležité poznámky · Máte-li pochybnosti, zvažte použití důvěryhodných ověřovacích platforem a protokolů. · Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Podívejte se prosím na dokumentaci(y)
obsaženo v: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 52-53.
19
AUTHN-BP04
Kontrola Aplikace implementuje zabezpečené ukončení relace během odhlášení, nečinnosti nebo uzavření aplikace. Popis Zabezpečené ukončení relace zajišťuje efektivní uzavření uživatelských relací. Ve scénářích, jako jsou scénáře odhlášení, nečinnosti nebo uzavření aplikace, existuje možnost, že aktéři se zlými úmysly zneužijí jakékoli přetrvávající přístupové body, pokud nejsou relace správně spravovány. Implementace zabezpečeného ukončení relace během odhlášení, nečinnosti nebo uzavření aplikace může výrazně snížit riziko neoprávněného přístupu automatickým ukončením uživatelských relací a zabezpečením uživatelských informací před přístupem neoprávněných stran. Pokyny k implementaci Vývojáři by měli znovu ověřit uživatele po odhlášení, nečinnosti aplikace, nečinnosti, pozadí, absolutních vypršeních relací nebo náhlém/vynuceném uzavření. Vývojáři by také měli na serveru generovat nové identifikátory relací, kdykoli uživatelé přejdou na novou úroveň ověřování, aby se zabránilo fixaci relací. Věci k poznámce
· Vývojáři by měli zajistit, aby ukončení relace zahrnovalo vymazání nebo zrušení autorizace všech místně uložených tokenů nebo identifikátorů relace.
· Vývojáři by měli určit hodnotu časového limitu nečinnosti na základě rizika a povahy finančních služeb.
· Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Podívejte se prosím na dokumentaci poskytnutou v: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 55-56, 58. o MAS Technology Risk Management Guidelines (2021), str. 51. o ENISA Smartphone Secure Development Guidelines (2016), str. 11.
20
AUTHN-BP05
Kontrola Aplikace implementuje ochranu hrubou silou pro ověřování. Popis Útoky hrubou silou zahrnují automatizované a systematické pokusy uhodnout přihlašovací údaje uživatele, napřample, zkoušením různých kombinací uživatelských jmen a hesel k získání neoprávněného přístupu. Ochrana hrubou silou omezuje počet pokusů o přihlášení během zadaného období. Implementace ochrany hrubou silou pro autentizaci může výrazně snížit riziko neoprávněného přístupu, chránit uživatelské účty a zachovat integritu procesu ověřování. Pokyny k implementaci Vývojáři by měli zavést mechanismy hrubé síly pomocí následujících osvědčených postupů:
· Zavést anti-automatizační kontroly. · Použít omezení rychlosti pro pokusy o přihlášení. · Zahrňte progresivní přírůstková časová zpoždění (např. 30 sekund, 1 minuta, 2 minuty, 5
minut) pro pokusy o přihlášení. · Vynutit uzamčení účtů. Poznámky · Vývojáři by si měli uvědomit, že všechny mechanismy MFA jsou citlivé na hrubou sílu. · Vývojáři by měli sdělit důvody pro uzamčení účtu a poskytnout dostupné prostředky
aby se uživatelé mohli ověřit a odstranit uzamčení. PřampMezi takové případy patří zavolání na linku pomoci nebo využití biometrického ověření. · Tato kontrola zabezpečení je uvedena v jiných normách. Podívejte se prosím na dokumentaci(y) v:
o ENISA Smartphone Secure Development Guidelines (2016), str. 10, 16.
21
AUTHN-BP06
Kontrola Aplikace implementuje mechanismus ověřování integrity transakcí. Popis Zatímco autentizace zajišťuje identitu uživatele, nevylučuje možnost podvodných aktivit během transakčního procesu. Mechanismy ověřování integrity transakcí jsou pomocné bezpečnostní funkce, které uživatelům poskytují čas a nástroje k reakci na potenciální podvody. Implementace mechanismu ověřování integrity transakcí zajišťuje, že každá transakce projde důkladnou kontrolou za účelem potvrzení její přesnosti a pravosti. Pokyny k implementaci Vývojáři mohou implementovat následující doporučené postupy:
· Zahájit hovor pro ověření/potvrzení transakce. · Poskytněte historii transakcí v reálném čase. · Zaveďte dobu ochlazení 12 až 24 hodin. · Ve výchozím nastavení zakázat zahraniční transakce; povolit pouze prostřednictvím MFA. Důležité poznámky Na tento ovládací prvek zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 57-58.
22
23
2. Autorizace
Zavedení
Zabezpečení autorizace funguje ve spojení se zabezpečením ověřování. Zabezpečení autorizace v mobilních aplikacích je klíčovou linií obrany, protože určuje, kdo má v rámci aplikace přístup k jakým zdrojům. Vytváří systematické ovládací prvky a ověřuje uživatelská přístupová práva v rámci aplikace.
Vývojáři mohou zajistit, že pouze autorizovaní uživatelé, klienti, aplikace a zařízení budou mít přístup ke konkrétním zdrojům nebo provádět určité akce implementací silných autorizačních kontrol a nastavení autorizace. Prostřednictvím autorizačních kontrol mohou vývojáři také zmírnit riziko neoprávněného přístupu k datům, udržovat integritu citlivých dat, chránit soukromí uživatelů a chránit integritu vysoce rizikových transakčních funkcí. Přestože vynucení těchto mechanismů musí být na vzdáleném koncovém bodu, je stejně důležité, aby aplikace na straně klienta dodržovala příslušné osvědčené postupy, aby bylo zajištěno bezpečné používání příslušných autorizačních protokolů.
Ovládací prvky v této kategorii poskytují kontroly zabezpečení autorizace, které by aplikace měla implementovat, aby ochránila citlivá data a zabránila neoprávněnému přístupu. Poskytuje také vývojářům relevantní osvědčené postupy, jak tyto bezpečnostní kontroly implementovat.
bezpečnostní kontroly
ID
Řízení
AUTHOR-BP01 Implementujte autorizaci na straně serveru.
AUTHOR-BP02 Implementujte autorizaci na straně klienta prostřednictvím vazby zařízení.
AUTHOR-BP03 Informujte uživatele o všech požadovaných oprávněních, než začnou aplikaci používat.
AUTOR-BP04
Informujte uživatele o všech vysoce rizikových transakcích, které byly autorizovány a dokončeny.
24
AUTOR-BP01
Kontrola Aplikace implementuje autorizaci na straně serveru. Popis Autorizace na straně serveru se týká ověřování a udělování přístupových oprávnění uživatelům nebo aplikacím serverem nebo autorizačním serverem. To zajišťuje, že rozhodnutí o řízení přístupu a oprávnění jsou spravována a vynucována na straně serveru, nikoli na straně klienta. Implementací autorizace na straně serveru vývojáři omezují příležitosti pro útočníky se zlými úmysly na tampnebo obejít bezpečnostní opatření v aplikaci, abyste získali neoprávněný přístup k citlivým údajům (tj. osobním údajům a ověřovacím údajům). Pokyny k implementaci Vývojáři by měli implementovat autorizaci na straně serveru po úspěšné autentizaci, před udělením přístupových oprávnění. Vývojáři by měli zajistit, aby uživatelům byl udělen přístup na základě následujícího:
· Přiřazená role s oprávněními: Zajistěte, aby uživatelé mohli provádět pouze úkoly související s jejich odpovědností.
· Kontextové faktory: Scénáře dynamického přístupu, jako je čas přístupu a analýza chování.
Důležité poznámky Na tento ovládací prvek zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 50-55, 58. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), pg. 10. · ENISA Smartphone Secure Development Guidelines (2016), str. 10-11.
25
AUTOR-BP02
Řízení Aplikace implementuje autorizaci na straně klienta prostřednictvím vazby zařízení.
Popis
Autorizace na straně klienta je proces správy přístupových oprávnění v rámci mobilní aplikace. To je riskantní, protože spoléhání se na stranu klienta může vystavit aplikace zranitelnostem, jako je neoprávněný přístup a potenciální podvod.
Pokud obchodní funkce aplikace (např. vytváření instancí softwarových tokenů) vyžadují autorizace na straně klienta, doporučuje se vazba zařízení (bezpečnostní postup, který přiřazuje oprávnění k přístupovým oprávněním na konkrétním zařízení). Implementací vazby zařízení mohou aplikace ověřit identitu zařízení a vytvořit důvěru. To snižuje rizika spojená s neoprávněným přístupem a udržuje bezpečnou a důvěryhodnou cestu mezi zařízeními, aplikacemi a servery.
Návod k implementaci
Vývojáři by měli vytvořit vazbu mezi aplikacemi a zařízením, když je identita uživatele použita poprvé na neregistrovaném mobilním zařízení.
Vývojáři by také měli ověřit, že aplikace:
· Zkontrolujte, zda nedošlo k úpravám zařízení od posledního běhu. · Zkontrolujte, zda nedošlo k úpravám identifikačních značek zařízení. · Zkontrolujte, zda je zařízení s aplikací v zabezpečeném stavu (např. bez útěku z vězení nebo rootování). Výše uvedené jsou jen některé examposvědčených postupů používaných v tomto odvětví. Jak se ekosystém mobilních zařízení vyvíjí, tyto techniky mohou být zastaralé. Vývojáři by proto měli držet krok s nejnovějšími osvědčenými postupy pro ověřování vazeb zařízení. Věci k poznámce
K ověření zařízení na zařízeních Android mohou vývojáři:
· Získejte jedinečné identifikátory, jako je IMEI nebo Android ID. · Načíst informace o sestavení. · Využijte nativní funkce rozhraní API operačního systému, jako je SafetyNet společnosti Google.
K ověření zařízení na zařízeních iOS mohou vývojáři:
· Využijte nativní služby operačního systému, jako je ID zařízení Apple prostřednictvím UIDevice.
Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 316-317, 516. · Směrnice řízení rizik technologie MAS (2021), str. 51, 56.
26
AUTOR-BP03
Ovládání Aplikace upozorní uživatele na všechna požadovaná oprávnění, než začnou aplikaci používat. Popis Požadovaná oprávnění jsou specifická práva a schopnosti, které aplikace vyžaduje od mobilního zařízení. Tato oprávnění definují, ke kterým zdrojům nebo funkcím má aplikace přístup na zařízeních uživatelů. Někteří exampMezi tyto soubory patří mimo jiné kamera, mikrofon, poloha atd. Implementací správných upozornění, která informují uživatele o tom, jaká oprávnění jsou požadována, mohou vývojáři zabránit uživatelům v nevědomém udělování nadměrných oprávnění, což může umožnit zlomyslným aktérům zneužít zranitelná místa. a odcizit citlivá data (tj. PII a Authentication Data). Taková upozornění také umožní uživatelům činit informovaná rozhodnutí o aplikacích, které instalují. Pokyny k implementaci Vývojáři by měli používat upozornění v aplikaci (v aplikaci), aby mohli požádat uživatele o povolení přístupu. Vývojáři by také měli zajistit, aby oznámení/výstrahy nezobrazovaly citlivá data. Důležité informace Vývojáři by měli vyžadovat pouze nezbytná oprávnění pro funkce aplikace. Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 56, 58. · ENISA Smartphone Secure Development Guidelines (2016), str. 8, 18, 28. · Apple Developer Guide on Privacy, https://developer.apple.com/design/human-interface-
pokyny/ochrana soukromí (leden 2024). · Průvodce pro vývojáře Android o ochraně osobních údajů, https://developer.android.com/quality/privacy-and-
bezpečnost (leden 2024).
27
AUTOR-BP04
Kontrola Aplikace upozorní uživatele na všechny vysoce rizikové transakce, které byly autorizovány a dokončeny.
Popis Pokud má aplikace vysoce rizikové transakční funkce, uživatelé by měli být okamžitě informováni, když byla transakce autorizována a dokončena. Implementací této kontroly mohou vývojáři zajistit, že uživatelé budou okamžitě informováni o autorizaci a dokončení vysoce rizikových transakcí, aby mohli co nejdříve identifikovat potenciální podvodné transakce.
Pokyny k implementaci Vývojáři by měli přijmout následující způsoby upozornění uživatele:
· Upozornění v aplikaci (v aplikaci). · E-mailová upozornění. · Upozornění na službu krátkých textových zpráv (SMS). Vývojáři by také měli zajistit, aby oznámení/výstrahy nezobrazovaly citlivá data.
Výše uvedené jsou jen některé exampinformace o osvědčených postupech oznamovacích technik používaných v tomto odvětví. Jak se ekosystém mobilních zařízení vyvíjí, tyto techniky mohou být zastaralé. Vývojáři by proto měli držet krok s nejnovějšími osvědčenými postupy v oboru, aby upozornili uživatele na autorizované a dokončené vysoce rizikové transakce.
Důležité informace Vývojáři by měli vyžadovat pouze nezbytná oprávnění pro funkce aplikace.
Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· Pokyny pro řízení technologických rizik MAS (2021), str. 52. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), str. 10. 2016. · ENISA Smartphone Secure Development Guidelines (8), str. XNUMX. · Apple Developer Guide on Privacy, https://developer.apple.com/design/human-interface-
pokyny/ochrana soukromí (leden 2024). · Průvodce pro vývojáře Android o ochraně osobních údajů, https://developer.android.com/quality/privacy-and-
bezpečnost (leden 2024).
28
29
3. Ukládání dat (Data-at-Rest)
Zavedení
Zabezpečení datového úložiště pro data v klidu se týká ochrany integrity a důvěrnosti citlivých dat (tj. PII a Authentication data) uložených lokálně na zařízení na straně klienta a na straně serveru aplikace, když nejsou aktivně používána nebo přenášena. To zahrnuje osvědčené postupy, ochranná opatření a šifrovací techniky používané k zabezpečení dat uložených v databázích, files, mezipaměti, paměť a Trusted Execution Environment (TEE) na mobilních zařízeních a podobných oblastech na aplikačních serverech.
Vývojáři mohou zajistit, že uživatelská data budou zachována a chráněna implementací přísných bezpečnostních kontrol pro ukládání dat v klidu. Správné kontroly stavu dat také zajišťují, že aplikace může zmírnit rizika neoprávněného přístupu, kompromitace zařízení, potenciálního narušení dat a úniků dat a posílit obranu aplikace.
Následující ovládací prvky zajišťují, že všechna citlivá data, která aplikace záměrně ukládá, jsou přiměřeně chráněna bez ohledu na cílové umístění. Zahrnuje také neúmyslné úniky způsobené nesprávným použitím rozhraní API nebo funkcí systému.
bezpečnostní kontroly
ID
Řízení
STORAGE-BP01 Uchovávejte citlivá data, která jsou nezbytná pouze pro transakce.
STORAGE-BP02 Implementujte bezpečné ukládání citlivých dat.
STORAGE-BP02a Uchovávejte citlivá data bezpečně na straně serveru.
SKLADOVÁNÍ-BP02b
Uchovávejte citlivá data bezpečně na straně klienta v prostředí Trusted Execution Environment (TEE).
STORAGE-BP03 Vymažte citlivá data, když již nejsou nutná.
30
SKLADOVÁNÍ-BP01
Kontrola Aplikace ukládá citlivá data, která jsou nezbytná pouze pro transakce. Popis Citlivá data jsou definována jako uživatelská data (PII) a ověřovací data (např. přihlašovací údaje, šifrovací klíče atd.). Vývojáři by měli ukládat pouze citlivá data, která jsou nezbytná pro obchodní funkce aplikací. Hromadění nepotřebných informací zvyšuje dopad potenciálních narušení bezpečnosti, díky čemuž je aplikace atraktivním cílem pro zlomyslné aktéry. Implementací této bezpečnostní kontroly mohou vývojáři zajistit, že vystavení je omezeno na data požadovaná pro konkrétní obchodní funkce, čímž se minimalizuje dopad v případě neoprávněného přístupu nebo narušení dat. Pokyny k implementaci Vývojáři by měli klasifikovat data používaná aplikací na základě úrovní citlivosti organizace a na základě požadavků právních předpisů. Vývojáři by měli přijmout následující pokyny k zabezpečení dat, která jsou klasifikována jako citlivá:
1. Implementujte řešení bezpečného úložiště založené na jeho citlivosti na straně klienta/serveru. 2. Aplikujte opatření na ochranu dat (např. tokenizace, hašování solí, šifrování). 3. Odstraňte citlivá data, když již nejsou nutná. Důležité poznámky Na tento ovládací prvek zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 190, 398. · Směrnice MAS Technology Risk Management Guidelines (2021), str. 9-10, 36, 38. · ENISA Smartphone Secure Development Guidelines (2016), str. 6.
31
SKLADOVÁNÍ-BP02
Ovládání Aplikace implementuje bezpečné ukládání citlivých dat. Popis Zabezpečené úložiště pro mobilní aplikace se týká implementace technik a postupů k ochraně citlivých dat uložených na mobilních zařízeních a aplikačních serverech před neoprávněným přístupem, krádeží apod.ampering. To zahrnuje osvědčené postupy, jako je šifrování, hašování, tokenizace a správné řízení přístupu. Implementací zabezpečeného úložiště mohou vývojáři zabránit neoprávněnému přístupu, kompromitaci zařízení, potenciálním únikům dat a únikům dat. Pokyny k implementaci Vývojáři by měli implementovat řešení bezpečného úložiště, které odpovídá citlivosti dat. Vývojáři by také měli upřednostnit následující pořadí řešení bezpečného úložiště (od nejcitlivějších dat po nejméně citlivá data):
1. Na straně serveru (všechna citlivá data by měla být uložena na straně serveru). 2. Na straně klienta v prostředí Trusted Execution Environment (v případě, že není na straně serveru
pokud je to možné, uložte všechna citlivá data do TEE na straně klienta). Důležité poznámky Na tento ovládací prvek zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 17-18. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 190-203, 398-
406. · ENISA Smartphone Secure Development Guidelines (2016), str. 06. 07-XNUMX.
32
SKLADOVÁNÍ-BP02a
Řízení
Aplikace bezpečně ukládá citlivá data na straně serveru.
Popis
Ukládání citlivých dat na straně serveru se týká ukládání dat na serverech vzdálených aplikací nebo databázích. Takový přístup vytváří lepší prostředí pro ochranu dat před neoprávněným přístupem nebo narušením, umožňuje bezpečnější řízení přístupu, možnosti implementace lepších bezpečnostních opatření, jako jsou složitější šifrování a poskytování rychlejších aktualizací zabezpečení.
Implementací úložiště citlivých dat na straně serveru mohou vývojáři zmírnit rizika spojená s ukládáním dat na straně klienta, protože úložiště na straně klienta je ze své podstaty náchylnější k technikám využívání úložiště dat, které běžně používají zákeřní aktéři v mobilních podvodech.
Návod k implementaci
Vývojáři by měli uplatnit alespoň jedno z následujících opatření na ochranu údajů:
1. Pouze pro hesla mohou vývojáři použít hash pomocí salt6. Namísto ukládání skutečných hesel se generují jedinečné soli a kombinují se s hesly, čímž se vytvářejí solené hashe.
2. Vývojáři mohou šifrovat7 citlivá data pomocí šifrovacích standardů, jako je AES-128. 3. Vývojáři mohou implementovat tokenizaci8 pomocí samořízené tokenizace nebo tokenizace
služby, kde je to možné, nahrazovat citlivá data tokeny. Kromě toho by vývojáři měli zajistit, aby tokenizace byla dostatečně dlouhá a složitá (podporovaná zabezpečenou kryptografií) na základě citlivosti dat a obchodních potřeb.
Výše uvedené jsou jen některé examposvědčených postupů používaných v tomto odvětví. S tím, jak se vyvíjí ekosystém mobilních zařízení, mohou tyto osvědčené postupy přestat platit. Vývojáři by proto měli držet krok s nejnovějšími osvědčenými postupy pro bezpečné ukládání citlivých dat na straně serveru.
Věci k poznámce
Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 19-20. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 71-77, 219-227,
416-421. · Pokyny pro řízení technologických rizik MAS (2021), str. 30, 36-37, 39. · Bezpečnostní pokyny pro přijímání mobilních plateb PCI v2.0.0 (2017), str. 9. · Směrnice ENISA pro bezpečný vývoj smartphonů (2016), str. 6-9.
6 Hašování solí se používá k přidání další vrstvy zabezpečení tím, že je pro útočníky výpočetně náročné dešifrovat původní citlivá data. V kontextu ukládání hesel nebo odvozování klíčů by vývojáři měli využívat jednosměrné funkce odvozování klíčů nebo pomalé hashovací algoritmy, jako je PBKDF2, bcrypt nebo scrypt. 7 Šifrování se používá k transformaci dat do nečitelného formátu, což zajišťuje, že i v případě neoprávněného přístupu zůstanou citlivá data důvěrná. 8 Tokenizace se používá k nahrazení citlivých dat tokeny, aby se minimalizovalo riziko vystavení citlivým datům.
33
SKLADOVÁNÍ-BP02b
Řízení
Aplikace bezpečně ukládá citlivá data na straně klienta v prostředí Trusted Execution Environment (TEE).
Popis
Trusted Execution Environment (TEE) je izolovaná oblast v rámci architektury hardwaru nebo procesoru mobilního zařízení, která poskytuje vysoce bezpečné prostředí pro ukládání citlivých dat a provádění citlivých nebo kritických operací. Je navržen tak, aby chránil citlivá data, kryptografické klíče a kritické procesy před neoprávněným přístupem nebo tampering. Pokud obchodní funkce aplikace vyžadují ukládání citlivých dat na straně klienta, doporučujeme je uložit do TEE zařízení.
Implementací správného ukládání citlivých dat do TEE na straně klienta mohou vývojáři zmírnit hrozby pocházející z kompromitovaného zařízení a od externích škodlivých aktérů. Takové úložiště může také zmírnit neoprávněný přístup k citlivým datům uživatele v aplikaci a zabránit odcizení jakýchkoli šifrovacích klíčů.
Návod k implementaci
Vývojáři by měli ukládat citlivá data bezpečně na straně klienta v prostředí Trusted Execution Environment (TEE), jako je TrustZone Android ARM nebo Secure Enclave společnosti Apple.
Vývojáři by také měli v TEE ukládat minimálně následující seznam citlivých dat:
· Biometrické identifikátory. · Autentizační tokeny. · Kryptografické klíče v zabezpečeném systému správy klíčů, jako je Android Keystore, iOS
Klíčenka.
Výše uvedené jsou jen některé exampmnožství citlivých údajů, které by vývojáři měli ukládat do TEE. Vzhledem k tomu, že se ekosystém mobilních zařízení vyvíjí, měli by vývojáři využívat svobodu ukládat veškerá data, která považují za nezbytná pro uložení v TEE.
Věci k poznámce
U zařízení bez hardwarových TEE mohou vývojáři zvážit použití virtualizovaných TEE.
Případně mohou vývojáři zvážit deaktivaci aplikace nebo deaktivaci vysoce rizikových transakčních funkcí aplikace, protože aplikace je považována za nezabezpečenou pro vysoce rizikové transakce.
Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 19-20. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 75, 93, 194-200. · Pokyny pro řízení technologických rizik MAS (2021), str. 51. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), str. 07. 09-14, 2016. · ENISA Smartphone Secure Development Guidelines (10), str. XNUMX.
34
SKLADOVÁNÍ-BP03
Řízení
Aplikace maže citlivá data, když již nejsou potřeba.
Popis
Smazání citlivých dat se týká procesu trvalého odstranění nebo vymazání důvěrných, soukromých nebo citlivých dat z úložných zařízení, serverů nebo databází. Tento proces zajišťuje, že citlivá data jsou nenávratně odstraněna a nemohou být zpřístupněna, obnovena, náhodně vystavena nebo rekonstruována neoprávněnými osobami nebo prostřednictvím metod obnovy dat.
Implementací tohoto procesu mohou vývojáři minimalizovat okno, ve kterém mohou útočníci zneužít zranitelnosti ke krádeži citlivých dat.
Návod k implementaci
Vývojáři by měli používat následující techniky trvalého zabezpečení úložiště:
· Vymažte uložené soubory cookie při ukončení aplikace nebo použijte ukládání souborů cookie v paměti. · Odstraňte všechna citlivá data při odinstalaci aplikace. · Ručně odstranit veškerou databázi files, které obsahují citlivá data (např. iOS WebView mezipaměti) z
a file systému, když související obchodní funkce přestanou existovat.
Výše uvedené jsou jen některé examposvědčených postupů používaných v tomto odvětví. Jak se ekosystém mobilních zařízení vyvíjí, tyto techniky mohou být zastaralé. Vývojáři by proto měli držet krok s nejnovějšími osvědčenými postupy v oboru, jak smazat citlivá data, když již nejsou potřeba.
Věci k poznámce
Vývojáři by měli dbát na dodržování obecně uznávaných standardů a příslušných zákonů o uchovávání údajů, včetně, ale nejen:
· Zákon o ochraně osobních údajů (PDPA) · Obecné nařízení o ochraně osobních údajů (GDPR) · Standard zabezpečení dat v odvětví platebních karet (PCI DSS)
Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 199, 206-214, 403-414.
· Pokyny pro řízení technologických rizik MAS (2021), str. 39. · ENISA Smartphone Secure Development Guidelines (2016), str. 07. 09, 10-XNUMX.
35
36
4. Anti-Tampering & Anti-Reverse
Zavedení
Anti-Tampering a Anti-Reversing bezpečnostní kontroly jsou další opatření, která mohou vývojáři implementovat, aby čelili útokům pokoušejícím se tampnebo aplikace zpětného inženýrství. Implementací obou funkcí přidávají vývojáři do aplikací několik vrstev obrany, což ztěžuje zlomyslným aktérům úspěšněampnebo reverzní inženýrství aplikací, což může mít za následek:
· Krádež nebo kompromitace cenných obchodních aktiv, jako jsou proprietární algoritmy, obchodní tajemství nebo citlivá data,
· Finanční ztráty uživatelů, kteří používají aplikaci pro vysoce rizikové transakce, · Finanční ztráty organizací v důsledku ztráty příjmů nebo soudních žalob, · Poškození reputace značky v důsledku negativní publicity nebo nespokojenosti zákazníků
Ovládací prvky zajišťují, že aplikace běží na důvěryhodných platformách, zabraňují tampza běhu a zajistit integritu funkcí aplikací. Kromě toho ovládací prvky brání porozumění tím, že útočníkům ztěžují zjistit, jak aplikace fungují.
bezpečnostní kontroly
ID
Řízení
RESILIENCE-BP01 Podepisujte se pomocí certifikátů z oficiálních obchodů s aplikacemi.
RESILIENCE-BP02 Implementujte jailbreak/detekci kořenů. RESILIENCE-BP03 Implementujte detekci emulátoru.
RESILIENCE-BP04 Implementace detekce malwaru.
RESILIENCE-BP05 Implementujte mechanismy proti zaháknutí.
RESILIENCE-BP06 Překryvný nástroj, vzdálený viewing a screenshot protiopatření.
ODOLNOST-BP07
Implementujte anti-keystroke capture nebo anti-keylogger proti virtuálním klávesnicím třetích stran.
37
ODOLNOST-BP01
Řízení
Aplikace je kód podepsaný certifikáty z oficiálních obchodů s aplikacemi.
Popis
Aplikace jsou často podvrženy zlomyslnými aktéry a distribuovány prostřednictvím méně přísně regulovaných kanálů. Podepsání aplikace pomocí certifikátů poskytnutých oficiálními obchody s aplikacemi zajistí mobilnímu OS a uživatelům, že mobilní aplikace pochází z ověřeného zdroje.
Implementace podepisování kódu pomáhá operačním systémům určit, zda povolit spuštění nebo instalaci softwaru na základě podpisů nebo certifikátů použitých k podepsání kódu. To pomáhá zabránit instalaci a spouštění potenciálně škodlivých aplikací. Kromě toho podepisování kódu také pomáhá s ověřováním integrity, protože podpisy se změní, pokud byla aplikace tampered s.
Návod k implementaci
Vývojáři by měli své aplikace podepisovat kódem pomocí certifikátů. Tato část poskytuje napřampinformace o tom, jak to udělat prostřednictvím dvou nejoblíbenějších platforem iOS a Android.
Pro Apple App Store to lze provést registrací do Apple Developer Program a vytvořením žádosti o podpis certifikátu na vývojářském portálu. Vývojáři se mohou zaregistrovat do programu Apple Developer Program a mohou se odkazovat na následující vývojářskou příručku pro podepisování kódu pod věcmi, které je třeba si uvědomit.
Pro Android existuje celá řada obchodů s aplikacemi. Pro Obchod Google Play to lze provést konfigurací podepisování aplikací Play, což je požadavek pro distribuci prostřednictvím Obchodu Google Play. Další informace o tom, jak to udělat, mohou vývojáři navštívit v příručce pro vývojáře systému Android v části Poznámky.
V případě jiných oficiálních obchodů si přečtěte příslušné pokyny pro vývojáře týkající se podepisování zdrojového kódu aplikace. Důležité informace Tato kontrola zabezpečení je také požadavkem pro publikování aplikací v oficiálních obchodech s aplikacemi, proto se doporučuje, aby vaše aplikace byla podepsána kódem s certifikáty z oficiálních obchodů s aplikacemi. Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· Apple Developer Program Guide pro podepisování kódu, https://developer.apple.com/support/code-signing (leden 2024).
· Příručka ochrany osobních údajů pro vývojáře pro Android, https://developer.android.com/quality/privacy-andsecurity (leden 2024).
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 325-326, 522523.
· ENISA Smartphone Secure Development Guidelines (2016), str. 21.
38
ODOLNOST-BP02
Řízení
Aplikace implementuje útěk z vězení nebo detekci kořenů.
Popis
Zakořeněná a jailbreaknutá zařízení jsou obecně považována za nezabezpečená. Rootovaná nebo jailbreaknutá zařízení umožňují uživatelům získat zvýšená oprávnění, což umožňuje snazší obcházení bezpečnostních a operačních omezení. Taková zvýšená oprávnění mohou být pro aplikace nebezpečná, protože tato oprávnění umožňují zlomyslným aktérům potenciálně zneužít zranitelnosti, krást přihlašovací údaje, přebírat uživatelská zařízení a provádět podvodné transakce aplikací.
Implementací jailbreaku nebo detekce root mohou vývojáři zabránit výše uvedeným exploitům, chránit duševní vlastnictví aplikací, zajistit stabilitu aplikací a zabránit obcházení systémů v aplikaci.
Návod k implementaci
Vývojáři by měli implementovat útěk z vězení nebo detekci rootu implementací následujících kontrol ve své aplikaci pro zařízení Android:
1. Zkontrolujte binární superuser nebo SU. 2. Zjistit kořen file systémové změny. 3. Hledejte zakořeněné aplikace. 4. Zkontrolujte vlastní obnovu. 5. Zkontrolujte, zda není použití API nebezpečné.
Vývojáři by měli implementovat útěk z vězení nebo detekci kořenů implementací následujících kontrol ve své aplikaci pro zařízení iOS:
1. Zjistěte použití omezených rozhraní API. 2. Hledejte vylepšení pro útěk z vězení, jako jsou mody. 3. Hledejte neoficiální obchody s aplikacemi, např. zkontrolujte podpis Cydia App Store. 4. Hledejte modifikace jádra. 5. Zkontrolujte integritu kritického bodu file systémy. 6. Použijte knihovny třetích stran určené k detekci zařízeníampering.
Výše uvedené jsou jen některé examposvědčených postupů používaných v tomto odvětví. S tím, jak se vyvíjí ekosystém mobilních zařízení, mohou být tyto kontroly zastaralé. Vývojáři by proto měli při implementaci útěku z vězení nebo detekci kořenů dodržovat nejnovější osvědčené postupy v oboru.
39
Důležité poznámky Na tento ovládací prvek zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 319-320, 5069,
518-519. · Pokyny pro řízení technologických rizik MAS (2021), str. 50. · ENISA Smartphone Secure Development Guidelines (2016), str. 11. 23, XNUMX.
9 https://github.com/crazykid95/Backup-Mobile-Security-Report/blob/master/Jailbreak-Root-DetectionEvasion-Study-on-iOS-and-Android.pdf
40
ODOLNOST-BP03
Řízení
Aplikace implementuje detekci emulátoru.
Popis
Emulátory jsou software používaný k testování mobilních aplikací tím, že umožňují uživateli testovat mobilní aplikaci na různých napodobených mobilních verzích a zařízeních. Přestože jsou aplikace užitečné pro testování, neměly by dovolit, aby byly připojeny k emulátorům mimo vývojové prostředí.
Implementací detekce emulace mohou vývojáři zabránit škodlivým aktérům ve spouštění dynamické analýzy, rootování, ladění, instrumentace, hákování a fuzz testování na emulovaném zařízení, které mohou ovládat. Vývojáři tak mohou zabránit zlomyslným aktérům v odhalení zranitelností v rámci aplikace pro zneužití.
Návod k implementaci
Vývojáři by měli implementovat následující detekční strategii k identifikaci funkcí pro běžně používaná emulační řešení. Některá doporučení věcí, které je třeba zkontrolovat, jsou:
· Zkontrolujte využití baterie. · Zkontrolujte časamps a hodiny. · Zkontrolujte vícedotykové chování. · Zkontrolujte paměť a analýzu výkonu. · Proveďte kontroly sítě. · Zkontrolujte, zda je založen na hardwaru. · Zkontrolujte, na čem je operační systém založen. · Zkontrolujte otisky prstů zařízení. · Zkontrolujte konfiguraci sestavení. · Zkontrolujte služby a aplikace emulátoru.
Výše uvedené jsou jen některé examposvědčených postupů používaných v tomto odvětví. S tím, jak se vyvíjí ekosystém mobilních zařízení, mohou být tyto kontroly zastaralé. Vývojáři by proto měli při implementaci detekce emulátoru dodržovat nejnovější osvědčené postupy v oboru. Důležité poznámky Na tento ovládací prvek zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 31-32. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 325, 521.
41
ODOLNOST-BP04
Řízení
Aplikace implementuje detekci malwaru.
Popis
Malwarové aplikace jsou stále více využívány zlomyslnými aktéry jako vektor ke kompromitaci mobilních zařízení uživatelů, protože taková zařízení uživatelům poskytují pohodlí potřebné k provádění každodenních transakcí. Malwarové aplikace primárně využívají funkce sideloading jako kanál, který uživatelům umožňuje nainstalovat malware na jejich zařízení.
Implementací funkcí detekce malwaru v aplikaci za běhu mohou vývojáři zabránit zneužívání uživatelů prostřednictvím malwaru využívajícího zranitelnosti aplikací a zranitelnosti OS, krádeže přihlašovacích údajů, převzetí zařízení a provádění podvodných transakcí.
Návod k implementaci
Vývojáři by měli do svých aplikací implementovat funkce detekce malwaru. To lze provést různými způsoby, ale nejsou omezeny na:
· Začlenit do svých aplikací sadu Runtime-Application-Self-Protection (RASP) Software Development Kit (SDK).
· Používejte sady RASP SDK ke kontrole a detekci malwarových aplikací za běhu. · Zkontrolujte a zabraňte překryvům. · Zabránit clickjackingu. · Zabránit zavěšení paměti aplikace.
Výše uvedené jsou jen některé examposvědčených postupů používaných v tomto odvětví. S tím, jak se vyvíjí ekosystém mobilních zařízení, mohou být tyto kontroly zastaralé. Vývojáři by proto měli při implementaci detekce malwaru držet krok s nejnovějšími osvědčenými postupy v oboru.
Věci k poznámce
Pokud je zjištěna jakákoli forma škodlivosti, vývojáři by měli aplikaci deaktivovat a poskytnout uživateli potřebné informace o tom, proč byla aplikace deaktivována, a vyzvat uživatele, aby odinstaloval škodlivé aplikace ze svého zařízení.
Případně by vývojáři měli varovat uživatele a deaktivovat vysoce rizikové funkce v aplikaci, dokud uživatel škodlivé aplikace neodstraní. Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 31. · Pokyny pro řízení rizik technologie MAS (2021), str. 40. 49, 2016. · ENISA Smartphone Secure Development Guidelines (23), str. XNUMX.
42
ODOLNOST-BP05
Řízení
Aplikace implementuje mechanismy proti zaháknutí.
Popis
Hooking označuje techniku, kterou útočníci používají k zachycení nebo úpravě chování mobilní aplikace za běhu. To zahrnuje vložení nebo zapojení do spouštěcího toku aplikace, aby bylo možné monitorovat její aktivity, měnit její chování, vkládat škodlivý kód nebo upravovat stávající funkce kódu za účelem zneužití zranitelností.
Implementací mechanismů proti hákování do aplikací mohou vývojáři zabránit výše uvedeným útokům a zabránit neoprávněnému přístupu, chránit vysoce rizikové transakční operace, detekovat a předcházetamppokusy o úpravy a úpravy, zachování duševního vlastnictví a zachování spolehlivosti aplikace.
Návod k implementaci
Vývojáři by měli implementovat následující napřampMechanismy pro zmírnění útoků typu hákování:
· Implementujte ochranu pro blokování vkládání kódu. · Implementujte ochranu, která zabrání hákování metody tím, že zabrání úpravám aplikace
zdrojový kód (jak na klientovi, tak na serveru). · Implementujte ochranu, která zabrání spouštění upravených kódů ve vaší aplikaci. · Implementujte ochranu, která zabrání přístupu do paměti a manipulaci s pamětí pro vaši aplikaci. · Realizovat tamper rezistentní algoritmy nebo anti-tampering SDK (běžně známé jako
Runtime-Application-Self-Protection SDK). · Zkontrolujte nebezpečné parametry, jako jsou zastaralá rozhraní API a parametry.
Výše uvedené jsou jen některé examposvědčených postupů používaných v tomto odvětví. S tím, jak se vyvíjí ekosystém mobilních zařízení, mohou být tyto kontroly zastaralé. Jako takoví by vývojáři měli při implementaci mechanismů proti hákování držet krok s nejnovějšími osvědčenými postupy v oboru. Důležité poznámky Na tento ovládací prvek zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 135-140, 189,
318-319, 339-340, 390, 520. · Směrnice MAS Technology Risk Management Guidelines (2021), str. 56. · ENISA Smartphone Secure Development Guidelines (2016), str. 23. 26, XNUMX.
43
ODOLNOST-BP06
Řízení
Aplikace implementuje překryvné, vzdálené viewing a screenshot protiopatření.
Popis
Citlivé informace lze zachytit nebo zaznamenat bez výslovného souhlasu uživatele, pokud má aplikace funkce nahrávání obrazovky, snímku obrazovky nebo překryvné vrstvy. Napřampten:
· Překryvné útoky klamou uživatele vytvořením falešné vrstvy napodobující důvěryhodné aplikace s cílem ukrást citlivá data.
· Dálkový viewÚtoky zahrnují neoprávněný přístup k obrazovce zařízení, což útočníkům umožňuje sbírat citlivá data na dálku.
· K útokům na snímky obrazovky dochází, když útočníci zachytí obrazovku zařízení bez souhlasu uživatele a získají citlivá data.
Implementace overlay, vzdálená viewProtiopatření a protiopatření snímků obrazovky mohou zajistit, že citlivé informace zůstanou v bezpečí, bude zachováno soukromí uživatelů a citlivá data budou chráněna proti neúmyslné ztrátě nebo zneužití.
Návod k implementaci
Vývojáři by měli implementovat anti-tamperační a antimalwarové kontroly prostřednictvím RASP SDK, aby se zabránilo škodlivým aplikacím ve využívání překryvných vrstev a vzdálených viewing exploity.
Pro snímky obrazovky mohou vývojáři použít příznak FLAG_SECURE pro aplikace pro Android a podobné příznaky pro iOS, aby při používání aplikace zablokovali všechny možnosti snímání obrazovky. Předpokládejme však, že obchodní funkce vyžadují možnosti snímání obrazovky (např. pořízení snímku obrazovky dokončené transakce PayNow). V takovém případě se doporučuje deaktivovat možnosti snímání obrazovky pro obrazovky nebo stránky, které obsahují citlivá data (PII a Authentication Data).
Vývojáři mohou také zvážit maskování vstupu pomocí citlivých dat a obrazovek senzorů, když je aplikace na pozadí.
Věci k poznámce
Někteří exampMezi informace o tom, kde lze tyto funkce snímků obrazovky deaktivovat, patří mimo jiné: přihlašovací stránky, stránky vícefaktorové autentizace, bezpečnostní pověření a stránky pro změnu PII atd.
Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 166-168, 257,
259, 265-267, 366, 480-481. · Pokyny pro řízení technologických rizik MAS (2021), str. 56. · ENISA Smartphone Secure Development Guidelines (2016), str. 8. XNUMX.
44
ODOLNOST-BP07
Řízení
Aplikace implementuje zachycení úhozů nebo anti-keylogger proti virtuálním klávesnicím třetích stran.
Popis
Zachycování úhozů a keylogging jsou metody, které útočníci využívají ke sledování, protokolování a zaznamenávání kláves stisknutých na klávesnici bez vědomí a souhlasu uživatele. To umožňuje protokolování a zachycování potenciálně citlivých dat (tj. PII a autentizační údaje).
Implementací protiopatření proti stisku kláves a keylogging mohou vývojáři zabránit zbytečné ztrátě citlivých dat. Přesněji řečeno, tento ovládací prvek cílí na zařízení Android, protože nativní klávesnici zařízení Android lze změnit. Takové změny mohou vystavit aplikace bezpečnostním chybám, protože důvěryhodná cesta mezi vstupy z klávesnice a aplikacemi má mezi sebou nedůvěryhodné strany.
Návod k implementaci
Vývojáři by neměli dovolit použití nezabezpečených virtuálních klávesnic třetích stran pro vstupy, které mohou obsahovat citlivá data. Pro takové vstupy je preferována zabezpečená vlastní klávesnice v aplikaci.
Implementací klávesnice v aplikaci mohou vývojáři ovládat, kam jdou data protokolování, a zmírnit tak riziko nezabezpečených virtuálních klávesnic třetích stran, které budou fungovat jako keyloggery pro zachycení úhozů.
Spolu s používáním klávesnic v aplikaci by vývojáři měli implementovat následující návrhy pro vstupy, které vyžadují citlivá data (např. PII a Authentication Data): Zakázat automatické opravy, automatické vyplňování, automatické návrhy, vyjímání, kopírování a vkládání pro funkce/nebo aplikace, které obsahují citlivá data. .
Zajímavosti Některé exampMezi funkce, které by měly využívat klávesnice v aplikaci, patří mimo jiné přihlášení, zadání OTP nebo jiné ověřovací faktory atd.
Tato kontrola zabezpečení a doporučený postup se primárně zaměřují na zařízení Android. Hlavním cílem je zajistit bezpečnost důvěryhodné cesty. Vzhledem k tomu, že Android neposkytuje metodu, jak vynutit používání nativních/důvěryhodných klávesnic, vývojáři by měli implementovat klávesnici v aplikaci, aby zajistili, že nezabezpečené virtuální klávesnice třetích stran nebudou protokolovat informace.
Implementace zabezpečené klávesnice v aplikaci nesnižuje rizika spojená s napadeným zařízením.
Na tuto kontrolu zabezpečení se odkazuje v jiných normách. Prostudujte si prosím dokumentaci poskytnutou v:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), str. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), str. 203, 214-215,
257, 259, 400, 414-415. · Pokyny pro řízení technologických rizik MAS (2021), str. 56. · ENISA Smartphone Secure Development Guidelines (2016), str. 08. 23, XNUMX.
45
Reference
S/N 1
2
3
4
5
6
Dokument OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 Pokyny pro řízení rizik technologie MAS, PCI Mobile Payment Acceptance Security Guidelines v2.0.0 ENISA Pokyny pro bezpečný vývoj pro chytré telefony Android Vývojáři Apple Developer Documentation
Zdroj OWASP
OWASP
MAS
PCI-DSS
ENISA
Android Apple
Datum 2023
2023
2021
2017
2016
2024
46
Dokumenty / zdroje
 |
Aplikace CSA Safe Standard [pdfUživatelská příručka Bezpečná standardní aplikace, bezpečná standardní aplikace, aplikace |
