Упатство за употреба на стандардна безбедносна апликација CSA

Стандардот за безбедна апликација на CSA е збир на упатства и најдобри
практики за имплементација на безбедносни контроли за автентикација во
мобилни апликации. Таа има за цел да обезбеди сигурна автентикација
механизми и заштита на чувствителните податоци од неовластен пристап. На
стандард е развиен во консултација со различни организации
и експерти од областа на сајбер безбедноста.

Цел, опсег и наменета публика

Целта на Стандардот за безбедна апликација на CSA е да обезбеди
програмери со препораки и најдобри практики за имплементација
безбедни контроли за автентикација во мобилните апликации. Стандардот
се применува за програмери и организации вклучени во
развој на мобилни апликации кои бараат автентикација. Тоа
е дизајниран да ја подобри севкупната безбедност на автентикацијата
процесуирајте и заштитете ја приватноста на корисниците.

Известување и упатства за програмери

Стандардот за безбедна апликација на CSA обезбедува насоки за програмерите
спроведување на безбедносни контроли за автентикација. Тоа го нагласува
важноста од следење на најдобрите практики во индустријата и обезбедување на
безбедно спроведување на механизмите за автентикација. Програмери
треба да се однесува на стандардот за детално упатство за спроведување
препорачаните безбедносни контроли.

Дефиниции на документи и нормативни референци

Стандардот за безбедна апликација на CSA вклучува дефиниции за документи и
нормативни референци кои обезбедуваат јасност на употребената терминологија
и упатете се на други релевантни индустриски стандарди и упатства.
Програмерите треба да се повикаат на овие дефиниции и референци за a
подобро разбирање на стандардот.

Упатство за употреба на производот

Автентикација

Автентикацијата е суштинска компонента на повеќето мобилни телефони
апликации. Го потврдува идентитетот на корисниците, клиентите,
апликации и уреди пред да се одобри пристап до одредени
ресурси или дозволување на одредени дејствија. Стандард за безбедна апликација на CSA
дава препораки и најдобри практики за имплементација на безбедна
контроли за автентикација.

Безбедносни контроли

Стандардот за безбедна апликација на CSA го вклучува следново
безбедносни контроли за автентикација:

ID	Контрола
АУТН-БП01	Апликацијата користи мулти-факторска автентикација (MFA) за автентикација трансакции со висок ризик.
АУТН-БП02	Контролен опис
АУТН-БП03	Контролен опис
АУТН-БП04	Контролен опис
АУТН-БП05	Контролен опис
АУТН-БП06	Контролен опис

AUTHN-BP01 – Повеќефакторска автентикација (MFA)

Во традиционалниот систем за автентикација со еден фактор, корисниците
обично треба само да внесете нешто што знаете (како што се кориснички имиња
и лозинки). Сепак, МНР додава слоеви на проверка на идентитетот
со барање дополнителни фактори како нешто-ти-имаш и
Нешто-ти-си. Ова го прави поголем предизвик за злонамерните
актери да ги компромитира сметките и ја подобрува целокупната безбедност на
процесот на автентикација.

Упатство за имплементација

Програмерите треба да го имплементираат Step-up MFA, за што е потребно
дополнително ниво на автентикација за трансакции со поголем ризик. На
Стандардот за безбедна апликација на CSA му дава приоритет на следново МНР
комбинации:

Нешто-ти-знаеш
Нешто-ти-имаш

Нешто-ти-си

Најчесто поставувани прашања (ЧПП)

П: Која е целта на Стандардот за безбедна апликација на CSA?

О: Целта на Стандардот за безбедна апликација на CSA е да обезбеди
програмери со препораки и најдобри практики за имплементација
безбедни контроли за автентикација во мобилните апликации.

П: Која е наменетата публика за безбедната апликација на CSA
Стандардна?

О: Стандардот за безбедна апликација на CSA е наменет за програмери и
организации вклучени во развојот на мобилни апликации
кои бараат автентикација.

П: Кои се придобивките од спроведувањето на Мулти-фактор
Автентикација (MFA)?

О: Спроведувањето на МНР додава слоеви на проверка на идентитетот, правејќи
е поголем предизвик за злонамерните актери да ги компромитираат сметките и
подобрување на севкупната безбедност на процесот на автентикација.

View Fullscreen

Стандардна верзија 1.0 на безбедна апликација на CSA објавена на 10 јануари 2024 година
2

Во консултација со:
Здружението на банки Сингапур, Постојаниот комитет за сајбер комитет Делоит Југоисточна Азија за ризичен совет Ernst & Young Advisory Pte. Ltd. KPMG во Сингапур Lazada Microsoft Singapore PricewaterhouseCoopers Risk Services Pte. Ltd.
Одрекување:
Овие организации беа консултирани за Стандардот за повратни информации и коментари за безбедносната контрола, описот на безбедносната контрола и техничките упатства за имплементација. До максималниот степен дозволен според законот, АДС и надворешните консултанти нема да бидат одговорни за какви било неточности, грешки и/или пропусти содржани овде, ниту за какви било загуби или штети од кој било вид (вклучувајќи каква било загуба на добивка, бизнис, добра волја или углед , и/или какви било посебни, случајни или последователни штети) во врска со каква било употреба или потпирање на овој стандард. Организациите кои развиваат мобилни апликации, давателите на услуги и програмерите се советуваат да размислат како Стандардот може да се примени во нивните специфични околности да добијат свој правен и/или технички совет во врска со содржината и/или имплементацијата на препораките во стандардните организации кои развиваат мобилни апликациите, давателите на услуги и програмерите треба да имаат професионално расудување доколку и кога ги спроведуваат препораките во Стандардот, а исто така треба да размислат дали се неопходни дополнителни мерки во однос на нивните специфични околности.
3

Содржини
Во консултација со: ………………………………………………………………………………………………………………………… 3 Одрекување: … ……………………………………………………………………………………………………………………………………. 3 За стандардот…………………………………………………………………………………………………………………… 6 Цел, Опсег и наменета публика ……………………………………………………………………………………… 6 Известување и упатства за програмери ………………………… ……………………………………………………………………………. 7 Дефиниции на документи и нормативни референци ………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………… ………………………………………………………………………………… 8
AUTHN-BP01 ………………………………………………………………………………………………………………………… 11 AUTHN-BP01a …………………………………………………………………………………………………………………… 13 AUTHN-BP01b …………………………………………………………………………………………………………………… 14 AUTHN-BP01c……………………………………………………………………………………………………………….. 15
AUTHN-BP02 …………………………………………………………………………………………………………………………… 16 AUTHN-BP03 ………………………………………………………………………………………………………………………… 17
AUTHN-BP03a ……………………………………………………………………………………………………………………………………………………………………………………………. 18 AUTHN-BP03b ……………………………………………………………………………………………………………………… 19 АУТН-БП04 ……………………………………………………………………………………………………………………… 20 AUTHN-BP05 ………………………………………………………………………………………………………………………………… 21 AUTHN-BP06 ……………………………………………………………………………………………………………………… 22 ……………………………………………………………………………………………………………………………………… ……….. 23 2. Овластување ………………………………………………………………………………………………………………………… ….. 24 АВТОР-БП01 ………………………………………………………………………………………………………………………… .. 25 АВТОР-БП02 ……………………………………………………………………………………………………………………………. 26 АВТОР-БП03 ……………………………………………………………………………………….. 27 АВТОР-БП04 ………………………………………………………………………………………………………………….. 28 ……………………………………………………………………………………………………………………………………………… …….. 29 3. Складирање податоци (податоци во мирување) ………………………………………………………………………………………………… …. 30 СКЛАДИРАЊЕ-BP01 ………………………………………………………………………………………………………………………………………………………………………………………………………. 31 СКЛАДИРАЊЕ-BP02 ………………………………………………………………………………………………………………………………………………………………………………………………………. 32 СКЛАДИРАЊЕ-BP02a …………………………………………………………………………………………………………………………………………………………………………………………………. 33 СКЛАДИРАЊЕ-BP02b …………………………………………………………………………………………………………………………………………………………………………………………………. 34 СКЛАДИРАЊЕ-BP03 ……………………………………………………………………………………………………………………………………………………………………………………………………. 35 …………………………………………………………………………………………………………………………………… ……….. 36 4. Анти-Тampеринг и анти-превртување…………………………………………………………………………………..37 РЕСИЛИЕНЦИЈА-BP01 …………………… …………………………………………………………………………………………………. 38 ОТПОЛНОСТ-BP02 ……………………………………………………………………………………………………………………… 39
4

ОТПОЛНОСТ-BP03 …………………………………………………………………………………………………………………………………………………………………………………………………………. 41 ОТПОЛНОСТ-BP04 ……………………………………………………………………………………………………………………… 42 ОТПОЛНОСТ-BP05 ……………………………………………………………………………………………………………………… 43 ОТПОЛНОСТ-BP06 …………………………………………………………………………………………………………………… 44 ОТПОЛНОСТ-BP07 ……………………………………………………………………………………………………………………… 45 Користена литература………………………………………………………………………………………………………………………… 46
5

За Стандардот
Вовед Стандардот за безбедна апликација е препорачан стандард за мобилни апликации (апликации), развиен од Агенцијата за кибер безбедност на Сингапур (CSA), во консултација со индустриските партнери од финансиски институции, технолошки организации, консултантски фирми и владини агенции. Во текот наview Целта на Стандардот е да се изнесе препорачана основна линија на безбедносни контроли за развивачите и провајдерите на мобилни апликации. Ова ќе осигури дека сите локални апликации се придржуваат до сличен сет на безбедносни контроли за мобилните апликации, со што ќе се подигнат безбедносните нивоа на апликациите хостирани и креирани во Сингапур.
Цел, опсег и наменета публика
Овој документ е развиен за да обезбеди препораки и предлози на програмерите за да им помогнат во имплементирањето на безбедносните функции во нивните апликации. Таквите препораки и предлози имаат за цел да им помогнат на програмерите во ублажувањето на широк спектар на закани за сајбер-безбедноста и во заштитата на нивните апликации од најновите мобилни измами и експлоатирања на малициозен софтвер за мобилни телефони. Содржините овде се необврзувачки, обезбедени на основа без потпирање и наменети да бидат информативни по природа и не се наменети за исцрпно да ги идентификуваат потенцијалните закани за сајбер-безбедноста, ниту исцрпно да ги специфицираат процесите или системите што програмерите треба да ги воспостават за да се справат или да ги спречат таквите закани. Верзијата 1 на упатствата и безбедносните контроли на Safe App Standard ќе се фокусираат првенствено на обезбедување безбедносни упатства за развивачите на апликации со висок ризик за да се спротивстават на најновиот мобилен малициозен софтвер и експлоатирања на измами забележани во пејзажот на закани во Сингапур. Сепак, овие безбедносни контроли можат да имаат корист и да се имплементираат од други апликации. Се препорачува сите програмери да се стремат да ги имплементираат овие мерки за подобрена безбедност на мобилните апликации. Иако овој стандард има примарна област на фокусирање, идните повторувања ќе се прошират за да ги опфатат најдобрите безбедносни практики и упатства за целиот куп на мобилни апликации.
6

Известување и упатства за програмери
Ова е жив документ кој ќе биде подложен на реview и периодично да се ревидира. Како и многу други воспоставени стандарди, Стандардот за безбедна апликација е жив документ кој редовно ќе се ажурира за да одговара на тековниот и еволуирачкиот пејзаж на закани и новите вектори на напади. Ве молиме погледнете ги CSA's webстраницата да остане ажурирана со најновата верзија на Стандардот за безбедна апликација и соодветно да ги приспособи безбедносните мерки и контроли. Овој стандард треба да се чита во врска со и не ги заменува, менува или заменува какви било законски, регулаторни или други обврски и должности на развивачите и давателите на апликации, вклучително и оние според Законот за сајбер-безбедност од 2018 година, и секое дополнително законодавство, кодекси на практика, стандарди за изведба или писмени упатства издадени според нив. Употребата на овој документ и имплементацијата на препораките овде, исто така, не го ослободува или автоматски го ослободува развивачот и давателот на апликацијата од такви обврски или должности. Содржината на овој документ не е наменета да биде авторитативна изјава на законот или замена за правен или друг професионален совет. Упатство за програмери за безбедносна рамка за стандардна безбедна апликација За полесно користење, програмерите треба да имаат предвид дека верзијата 1 на Стандардот за безбедна апликација ги таргетира следните критични области, а самиот документ може да се подели на следните подсекции:
· Автентикација · Овластување · Складирање на податоци (Data-at-Rest) · Анти-Tamper & Anti-Reversing Овие критични области се вклучени за да се обезбеди стандардизација на безбедноста на мобилните апликации против најчестите вектори на напади што ги користат малициозните актери во нашиот локален екосистем. Стандардот за безбедна апликација обезбедува јасен и концизен сет на безбедносни контроли, упатства и најдобри практики за подобрување на безбедноста на мобилните апликации кои обезбедуваат или овозможуваат трансакции со висок ризик.
7

Дефиниции на документи и нормативни референци
Дефиниции на документи Следниве се некои дефиниции што програмерите и читателите треба да ги имаат на ум додека го користат овој документ: Чувствителни податоци Кориснички податоци како што се лични информации за идентификација (PII) и податоци за автентикација како ингеренции, клучеви за шифрирање, еднократни лозинки, биометриски податоци , безбедносни токени, сертификати итн. Трансакции со висок ризик се оние кои вклучуваат:
· Промени на финансиските функции некои прampтие вклучуваат, но не се ограничени на регистрација на детали за примачот на трета страна, зголемување на лимитот за трансфер на средства, итн.
· Иницирање на финансиски трансакции некои прampТие вклучуваат, но не се ограничени на трансакции со средства со висока вредност, трансфери на средства со висока вредност, трансакции со онлајн картички, пристап до директно задолжување, функции за складирање пари и дополнувања итн.
· Промени во безбедносните конфигурации на апликацијата некои прampДеловите од ова вклучуваат, но не се ограничени на оневозможување на методите за автентикација, ажурирање на дигитални токени или ингеренции, итн.
Безбедносни контроли Оперативни или технички мерки препорачани во овој документ што треба да се применат за управување, следење и ублажување на потенцијалните безбедносни пропусти или инциденти. Овие безбедносни контроли ги имаат прикачени следните ID, на пр., AUTHN-BP01, AUTHOR-BP01, STORAGE-BP01, RESILIENCE-BP01. Нормативни референци Стандардот за безбедна апликација упатува на индустриски стандарди од Open Web Проект за безбедност на апликации (OWASP), Агенцијата на Европската унија за мрежна и информациска безбедност (ENISA) и Стандардот за безбедност на податоци за индустријата за платежни картички (PCI DSS). Списокот на референци е како што следува:
· MASVS на OWASP (Стандард за верификација за безбедност на мобилни апликации) · MASTG на OWASP (Водич за тестирање на безбедноста на апликациите) · Упатства за безбеден развој на ENISA (SSDG) · Безбедносни упатства за прифаќање плаќања на PCI DSS за програмери
8

1. Автентикација

Вовед
Автентикацијата е суштинска компонента на повеќето мобилни апликации. Овие апликации вообичаено користат различни форми на автентикација, вклучувајќи биометриски, PIN-кодови или генератори на кодови за повеќефакторска автентикација. Осигурувањето дека механизмот за автентикација е безбеден и имплементиран според најдобрите практики во индустријата е од клучно значење за да се потврди идентитетот на корисникот.
Со имплементирање на силни безбедносни контроли за автентикација, програмерите можат да обезбедат дека само автентицираните корисници, клиенти, апликации и уреди можат да пристапат до одредени ресурси или да вршат одредени дејства. Преку безбедни контроли за автентикација, програмерите исто така можат да го намалат ризикот од неовластен пристап до податоците, да го задржат интегритетот на чувствителните податоци, да ја зачуваат приватноста на корисникот и да го заштитат интегритетот на функционалностите на трансакциите со висок ризик.
Контролите во оваа категорија имаат за цел да препорачаат безбедносни контроли за автентикација што апликацијата треба да ги спроведе за да ги заштити чувствителните податоци и да спречи неовластен пристап. Исто така, им дава на програмерите релевантни најдобри практики за спроведување на овие безбедносни контроли.
безбедносни контроли

Контрола

AUTHN-BP01 AUTHN-BP01a AUTHN-BP01b AUTHN-BP01c AUTHN-BP02 AUTHN-BP03 AUTHN-BP03a AUTHN-BP03b AUTHN-BP04 AUTHN-BP05

Користете мулти-факторска автентикација за автентичност на трансакциите со висок ризик. Спроведување на автентикација на нешто што знаете како еден од факторите на МНР. Спроведување на автентикација на нешто што имаш како еден од факторите на МНР. Имплементирајте ја автентикацијата на Something-You-Are како еден од факторите на МНР. Користете фактори засновани на контекст за автентикација. Спроведување на безбедна автентикација на сесијата. Спроведување на безбедна автентикација со статус. Спроведување на безбедна автентикација без државјанство. Спроведување на безбедно завршување на сесијата за време на одјавување, неактивност или затворање на апликацијата. Спроведување на заштита од брутална сила за автентикација. Спроведување на механизам за проверка на интегритетот на трансакцијата.

АУТН-БП01
Контрола
Апликацијата користи мулти-факторска автентикација (MFA) за автентичност на трансакциите со висок ризик.
Опис
Во традиционалниот систем за автентикација со еден фактор, корисниците обично треба само да внесат нешто што знаеш1 како што се кориснички имиња и лозинки. Меѓутоа, ако овој единствен фактор не успее или е компромитиран, целиот процес на автентикација е ранлив на закани.
MFA е процедура за автентикација која додава слоеви на проверка на идентитетот, барајќи не само нешто-ти-знаеш, туку и нешто-ти-имаш2 и нешто-си-3. Спроведувањето на MFA го прави поголем предизвик за злонамерните актери да ги компромитираат сметките и да ја подобрат севкупната безбедност на процесот на автентикација.
Упатство за имплементација
Програмерите треба да користат Step-up MFA. Тоа е специфичен тип на MFA каде што апликацијата вклучува стратегија за автентикација која бара дополнително ниво на автентикација, особено кога се обидувате трансакции со поголем ризик.
Програмерите треба да им дадат приоритет на следните комбинации на МНР во редот од 1, 2, 3 и 4, со опција 1 како најсигурен избор.

Фактори / Опција нешто-ти-знаеш нешто-имаш
· Софтверски токен · Хардверски токен · SMS OTP Something-You-Are

1 Нешто што знаете се однесува на информации што корисникот ги знае, како што се ПИН (Личен идентификациски број), лозинка или шема, итн. 2 Нешто што имате се однесува на поседување на физички уред, апликација или токен што генерира акредитации за автентикација, кои може да вклучуваат еднократни лозинки (OTP) базирани на време. ПрampДел од таквите токени вклучуваат софтверски токени, хардверски токени и SMS OTP. 3 Something-You-Are се однесува на биометриски идентификатори, каде што уникатните физички карактеристики на корисникот се користат за верификација, како што се отпечатоци од прсти, скенирање на мрежницата, препознавање лице или препознавање глас.
11

На програмерите им се препорачува да не се потпираат на SMS и е-пошта OTP како канал за автентикација за трансакции со висок ризик. Ако не можете, од клучно значење е да се имплементира биометриски фактор или дополнителен фактор за автентикација во врска со SMS OTP и е-пошта OTP. Работи кои треба да се забележат
· Силно се препорачува да се изберат решенија кои не се достапни кога е можно. · Програмерите треба да осигураат дека барем еден фактор на МНР е потврден на страната на клиентот, со сите
други потврдени на страната на серверот. Во случаи кога автентикацијата е потврдена на страната на клиентот, особено за Android, наметнете го кодот базиран на доверливо опкружување за извршување (TEE). · Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
o OWASP Стандард за верификација за безбедност на мобилни апликации (MASVS) v2.0.0 (2023), стр. 21.
o Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 51, 56. o Упатства за управување со технолошки ризик на MAS (2021), стр. 34, 50. o Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 11.
12

Контрола на AUTHN-BP01a Апликацијата имплементира автентикација на нешто што знаете како еден од факторите на МНР. Опис „Нешто знаеш“ претставува основен слој на проверка на идентитетот што вклучува информации што му се познати само на корисникот, како што е ПИН (Личен идентификациски број), лозинка, шема, итн. Спроведувањето на „Нешто што знаеш“ како еден од факторите на МНР обезбедува основно ниво на проверка на идентитетот со барање од корисниците да обезбедат единствени информации поврзани со нивните сметки. Тоа е клучен фактор во принципот „Нешто-ти-знаеш, нешто-имаш и нешто-ти-си“, што придонесува за сеопфатна и ефективна повеќеслојна безбедносна стратегија. Упатство за имплементација Програмерите треба да ги усвојат следните упатства за создавање силни и безбедни лозинки:
· Обезбедете минимална должина на лозинка од 12 знаци или повеќе. · Вклучете мешавина од големи и мали букви, броеви и специјални знаци ограничени на
~`! @#$%^&*()_-+=:;,.? Програмерите исто така треба да ги препознаат и избегнат вообичаените стапици при креирањето лозинка:
· Избегнувајте да користите погодни зборови, фрази или комбинации. · Воздржете се од внесување лични податоци. · Ослободете се од последователни знаци (на пр., „123456“) или повторени знаци (на пример, „aaaaa“). Работи што треба да се забележат · Програмерите треба да спроведат ротација на акредитиви само на организациски средства или ако нема
Имплементација на МНР на корисникот, на пр. се менува годишно или според соодветна временска рамка. · Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите)
дадено во: o Насоки за управување со технолошки ризик на MAS (2021), стр. 34. o Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 10.
13

Контрола на AUTHN-BP01b Апликацијата имплементира автентикација на нешто што имаш како еден од факторите на МНР. Опис Something-You-Have бара од корисниците да се автентицираат со физички уред, апликација или токен што генерира акредитиви за автентикација, кои може да вклучуваат еднократни лозинки (OTP) базирани на време. ПрampДел од таквите токени вклучуваат софтверски токени, хардверски токени и SMS OTP. Спроведувањето на нешто што имаш како еден од факторите на МНР додава сложеност на процесот на автентикација со тоа што бара поседување на опиплив елемент, значително намалувајќи ја веројатноста за неовластен пристап. Тоа е клучен фактор во принципот „Нешто-ти-знаеш, нешто-имаш и нешто-ти-си“, што придонесува за сеопфатна и ефективна повеќеслојна безбедносна стратегија. Упатство за имплементација Програмерите треба да користат OTP базиран на време за софтверски токени, хардверски токени и SMS OTP. Треба да се следат следните упатства:
· ОТП треба да важи само не повеќе од 30-ти. · ОТП што е погрешно внесен по 3 обиди треба да се поништи, а сесијата на корисникот
треба да се отповика или отфрли. Работи кои треба да се забележат
· Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во: o Водич за тестирање за безбедност на мобилни апликации на OWASP (MASTG) v1.7.0 (2023), стр. 56-57. o Насоки за управување со технолошки ризик на MAS (2021), стр. 50, 51. o Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 10.
14

AUTHN-BP01c
Контрола Апликацијата ја имплементира автентикацијата на Something-You-Are како еден од факторите на МНР.
Описот Something-You-Are бара од корисниците да се автентицираат со биометриски идентификатори како што се отпечатоци од прсти, скенирање на мрежницата или препознавање на лицето. Спроведувањето на Something-You-Are како еден од факторите на МНР додава високо персонализиран и тешко реплицирачки фактор за автентикација. Обезбедува посилно средство за потврдување на идентитетот на корисникот од факторите Нешто-ти-знаеш и нешто-ти-имаш, намалувајќи го ризикот од неовластен пристап. Тоа е клучен фактор во принципот „Нешто-ти-знаеш, нешто-ти-имаш и нешто-ти-си“, придонесувајќи за сеопфатна и ефективна повеќеслојна безбедносна стратегија. Упатство за имплементација Програмерите треба да имплементираат биометриска автентикација од страна на серверот користејќи доверлива платформа за биометриска идентификација како Singpass. Меѓутоа, ако тоа не е изводливо, програмерите треба да имплементираат биометриска автентикација од страна на клиентот преку механизмите за доверливи средини за извршување (TEE) на уредот, како што се CryptoObject и Android Protected Confirmation за Android или услугите на Keychain за iOS. Работи кои треба да се забележат
· Програмерите треба да ги ограничат функционалностите на апликациите на уреди на кои им недостига хардверско доверливо извршено опкружување (TEE) или биометрика. За прampТака, уредите со Android на кои им недостига TEE може да се откријат со помош на API за Android „isInsideSecureHardware“.
· Програмерите треба да ја поништат биометриската автентикација доколку се случат промени во биометрискиот механизам, како што е запишување нов отпечаток од прст на уредот. И iOS и Android платформите поддржуваат поставување на крипто-клуч за апликација да истекува како одговор на таквите промени.
· Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во: o Водич за тестирање за безбедност на мобилни апликации на OWASP (MASTG) v1.7.0 (2023), стр. 227233, 422-426. o Насоки за управување со технолошки ризик на MAS (2021), стр. 51. o Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 11, 26.
15

АУТН-БП02
Контрола Апликацијата користи фактори засновани на контекст за автентикација. Опис Факторите засновани на контекст воведуваат динамични елементи како што се локацијата на корисникот и атрибутите на уредот. Додека MFA обезбедува робустен слој на безбедност барајќи повеќе фактори за автентикација, инкорпорирањето на фактори засновани на контекст создава посеопфатен и адаптивен процес на автентикација што може да понуди дополнителни придобивки во справувањето со ризиците кои се развиваат од неовластен пристап. Спроведувањето на фактори засновани на контекст го минимизира потпирањето на статични акредитиви, што го прави поголем предизвик за злонамерните актери да се обидат со неовластен пристап. Упатство за имплементација Програмерите треба да ги земат предвид следните контекстуални фактори за да го потврдат идентитетот на корисникот:
· Геолокација: Дозволете пристап врз основа на реалната локација на уредот што користи GPS, Wi-Fi или геолокација на IP адреса.
· Тип на уред: Дозволете пристап врз основа на карактеристиките на уредот. на пр., големината на екранот може да определи дали уредот е паметен телефон или таблет.
Работи што треба да се забележат Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 56, 58. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 11.
16

АУТН-БП03
Контрола Апликацијата спроведува безбедна автентикација на сесијата. Опис Безбедната автентикација на сесијата обезбедува стабилно управување со сесиите и за автентикација со статус и за без државјанство. Лошо управуваните сесии, без оглед на тоа дали апликацијата ги следи методите за автентикација со статус4 или без државјанство5, може да доведат до безбедносни закани како што се неовластен пристап, киднапирање на сесии или прекршување на податоците. Спроведувањето на безбедна автентикација на сесии за државни сесии користи безбедни идентификатори на сесии, шифрирана комуникација и соодветни временски прекини за да се спречи неовластен пристап. За автентикација без државјанство, осигурува дека токените се тampотпорен на er-и, одржувајќи го интегритетот на автентикацијата без да се потпирате на складирање од страна на серверот. Упатство за имплементација Програмерите треба да имплементираат безбедна автентикација на сесии со усвојување на следните најдобри практики за методите за автентикација со статус (AUTHN-BP03a) и без државјанство (AUTHN-BP03b) за сесии. Работи што треба да се забележат Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 51-55. · Упатства за управување со технолошки ризик на MAS (2021), стр. 51. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 10.
4 Автентикацијата со статус се однесува на управувањето со состојбите на сесијата на страната на серверот, што обично бара употреба на идентификатори на сесии. 5 Автентикацијата без државјанство се однесува на управување со сесии без складирање на информации поврзани со корисникот на страната на серверот.
17

Контрола AUTHN-BP03a Апликацијата имплементира сигурна автентикација со статус. Опис Безбедна автентикација со статус вклучува заштита и одржување на постојани сесии. Додека автентичноста со статус обезбедува беспрекорно корисничко искуство преку постојани кориснички сесии, таа може да биде ранлива на различни безбедносни закани, како што се злонамерните актери кои се обидуваат да украдат идентификатори на сесии. Спроведувањето на безбедна автентикација со статус ги штити корисничките сметки од неовластен пристап и потенцијални пропусти поврзани со управувањето со сесиите без да се загрози рамнотежата помеѓу употребливоста и безбедноста. Упатство за имплементација Програмерите треба да идентификуваат крајни точки од страната на серверот што изложуваат чувствителни информации или критични функционалности. Програмерите, исто така, треба да ги усвојат следните најдобри практики за автентикација на државни сесии:
· Одбијте барања со ИД или токени за сесии кои недостасуваат или не се валидни. · Создавајте идентификатори на сесии по случаен избор на страната на серверот без нивно додавање URLс. · Подобрете ја безбедноста на ИД на сесија со соодветна должина и ентропија, што го отежнува погодувањето. · Размена на ИД на сесии само преку безбедни HTTPS конекции. · Избегнувајте складирање на ID на сесии во постојано складирање. · Потврдете ги идентификаторите на сесиите за кориснички пристап до привилегираните елементи на апликацијата. · Прекинете ги сесиите на страната на серверот, бришејќи ги информациите за сесијата по истекот на времето или одјавувањето. Работи што треба да се забележат Ако се сомневате, размислете за користење на доверливи платформи и протоколи за автентикација. Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во: · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 52.
18

Контрола AUTHN-BP03b Апликацијата имплементира сигурна автентикација без државјанство. Опис Безбедната автентикација без државјанство вклучува безбедни практики за токени за ефективна и скалабилна автентикација. Додека автентикацијата без државјанство обезбедува придобивки, таа може да биде поранлива на безбедносни закани, како што е имитирање на корисникот, доколку токените не се безбедно генерирани, пренесени и складирани. Спроведувањето на безбедна автентикација без државјанство обезбедува безбедно ракување со секој токен за автентикација, притоа искористувајќи ги придобивките од ефикасноста и приспособливоста, намалувајќи го ризикот од неовластен пристап. Упатство за имплементација Програмерите треба да ги усвојат следните најдобри практики за автентикација на сесии без државјанство:
· Генерирајте токени на страната на серверот без да ги додавате URLс. · Подобрете ја безбедноста на токените со соодветна должина и ентропија, што го отежнува погодувањето. · Разменувајте токени само преку безбедни HTTPS конекции. · Потврдете дека нема чувствителни податоци, како што е PII, не се вградени во токени. · Избегнувајте складирање на токени во постојано складирање. · Потврдете ги токените за кориснички пристап до привилегираните елементи на апликацијата. · Прекинете ги токените на страната на серверот, бришејќи ги информациите за токените по истекот на времето или одјавувањето. · Криптографски потпишувајте ги токените користејќи безбеден алгоритам, избегнувајќи употреба на нула алгоритми. Работи што треба да се забележат · Ако се сомневате, размислете за користење доверливи платформи и протоколи за автентикација. · Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите)
обезбедено во: o Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 52-53.
19

АУТН-БП04
Контрола Апликацијата спроведува безбедно завршување на сесијата при одјавување, неактивност или затворање на апликацијата. Опис Безбедното завршување на сесијата обезбедува ефективно затворање на сесиите на корисникот. Во сценарија како што се сценарија за одјавување, неактивност или затворање апликации, постои потенцијал за злонамерни актери да ги искористат сите долготрајни пристапни точки доколку сесиите не се управуваат соодветно. Спроведувањето на безбедно завршување на сесијата за време на одјавување, неактивност или затворање на апликацијата може значително да го намали ризикот од неовластен пристап со автоматско прекинување на сесиите на корисниците и заштита на информациите за корисникот од пристап од неовластени страни. Упатство за имплементација Програмерите треба повторно да ги автентицираат корисниците по одјавување, неактивност на апликацијата, безделничење, позадина, апсолутен истек на сесијата или нагло/присилно затворање. Програмерите исто така треба да генерираат нови идентификатори на сесии на серверот секогаш кога корисниците се движат на ново ниво за автентикација за да спречат фиксирање на сесиите. Работи кои треба да се забележат
· Програмерите треба да се погрижат завршувањето на сесијата да вклучува чистење или деовластување на сите локално складирани токени или идентификатори на сесии.
· Програмерите треба да ја одредат вредноста на истекот на мирување врз основа на ризикот и природата на финансиските услуги.
· Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во: o Водич за тестирање за безбедност на мобилни апликации на OWASP (MASTG) v1.7.0 (2023), стр. 55-56, 58. o Насоки за управување со технолошки ризик на MAS (2021), стр. 51. o Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 11.
20

АУТН-БП05
Контрола Апликацијата имплементира заштита од брутална сила за автентикација. Опис Нападите со брутална сила вклучуваат автоматизирани и систематски обиди да се погодат корисничките акредитиви, на пр.ample, со обиди за различни комбинации на кориснички имиња и лозинки за да се добие неовластен пристап. Заштитата со брутална сила го ограничува бројот на обиди за најавување во одреден период. Спроведувањето на заштита од брутална сила за автентикација може значително да го ублажи ризикот од неовластен пристап, да ги заштити корисничките сметки и да го одржи интегритетот на процесот на автентикација. Упатство за имплементација Програмерите треба да имплементираат механизми за брутална сила преку следните најдобри практики:
· Спроведување на проверки против автоматизација. · Примени ограничување на стапката за обиди за најавување. · Вклучете прогресивни дополнителни временски одложувања (на пр. 30 секунди, 1 минута, 2 минути, 5
минути) за обиди за најава. · Спроведување на заклучување на сметката. Работи што треба да се забележат · Програмерите треба да забележат дека сите механизми на МНР се ранливи на брутална сила. · Програмерите треба да ги пренесат причините за заклучувањето на сметката и да обезбедат достапни средства
за корисниците да се автентицираат и да го отстранат заклучувањето. ПрampТие вклучуваат повикување телефонска линија за помош или користење биометриска верификација. · Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
o Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 10, 16.
21

АУТН-БП06
Контрола Апликацијата имплементира механизам за проверка на интегритетот на трансакцијата. Опис Иако автентикацијата го обезбедува идентитетот на корисникот, таа не ја елиминира можноста за лажни активности за време на процесот на трансакција. Механизмите за проверка на интегритетот на трансакциите се помошни безбедносни функции кои им даваат на корисниците време и алатки да реагираат на потенцијални измами. Спроведувањето на механизам за проверка на интегритетот на трансакцијата гарантира дека секоја трансакција е подложена на темелна проверка за да се потврди нејзината точност и автентичност. Упатство за имплементација Програмерите може да ги имплементираат следните предложени најдобри практики:
· Започнете повик за верификација/потврда на трансакцијата. · Обезбедете историја на трансакции во реално време. · Спроведување на период на ладење од 12 часа до 24 часа. · Стандардно оневозможи трансакции во странство; овозможи само преку МНР. Работи што треба да се забележат Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во: · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 57-58.
22

2. Овластување

Вовед
Безбедноста на овластувањето работи заедно со безбедноста за автентикација. Безбедноста на овластувањата во мобилните апликации е клучна линија на одбрана бидејќи одредува кој може да пристапи до кои ресурси во апликацијата. Создава систематски контроли и ги потврдува правата за пристап на корисниците во апликацијата.
Програмерите можат да се погрижат само овластените корисници, клиенти, апликации и уреди да можат да пристапат до одредени ресурси или да вршат одредени дејства со имплементирање на силни контроли за овластување и поставки за овластување. Преку контролите за овластување, програмерите исто така можат да го намалат ризикот од неовластен пристап до податоци, да го задржат интегритетот на чувствителните податоци, да ја зачуваат приватноста на корисниците и да го заштитат интегритетот на функционалностите на трансакциите со висок ризик. Иако спроведувањето на овие механизми мора да биде на далечинската крајна точка, подеднакво е важно апликацијата од страна на клиентот да ги следи релевантните најдобри практики за да обезбеди сигурна употреба на вклучените протоколи за овластување.
Контролите во оваа категорија обезбедуваат безбедносни контроли за овластување што апликацијата треба да ги спроведе за да ги заштити чувствителните податоци и да спречи неовластен пристап. Исто така, им дава на програмерите релевантни најдобри практики за тоа како да ги имплементираат овие безбедносни контроли.
безбедносни контроли

Контрола

AUTHOR-BP01 Спроведување на овластување од страна на серверот.

AUTHOR-BP02 Спроведување на овластување од страна на клиентот преку врзување на уредот.

AUTHOR-BP03 Известете ги корисниците за сите потребни дозволи пред да почнат да ја користат апликацијата.

АВТОР-БП04

Известете ги корисниците за сите овластени и завршени трансакции со висок ризик.

АВТОР-БП01
Контрола Апликацијата имплементира овластување од страна на серверот. Опис Овластувањето од страна на серверот се однесува на потврдување и доделување дозволи за пристап на корисници или апликации од сервер или сервер за авторизација. Ова осигурува дека одлуките и дозволите за контрола на пристап се управуваат и спроведуваат на страната на серверот, а не на клиентот. Со имплементирање на овластување од страна на серверот, програмерите ги намалуваат можностите за малициозни напаѓачи на тampили заобиколете безбедносни мерки на апликацијата за да стекнете неовластен пристап до чувствителни податоци (т.е. PII и податоци за автентикација). Упатство за имплементација Програмерите треба да имплементираат овластување од страна на серверот по успешната автентикација, пред да дадат дозволи за пристап. Програмерите треба да се погрижат на корисниците да им биде одобрен пристап врз основа на следново:
· Доделена улога со дозволи: Обезбедете дека корисниците можат да извршуваат само задачи релевантни за нивните одговорности.
· Контекстуални фактори: Динамични сценарија за пристап како што се Време на пристап и Анализа на однесување.
Работи што треба да се забележат Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 50-55, 58. · Упатства за безбедност за прифаќање плаќања од мобилни телефони PCI v2.0.0 (2017), стр. 10. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 10-11.
25

АВТОР-БП02
Контрола Апликацијата имплементира овластување од страна на клиентот преку врзување на уредот.
Опис
Овластувањето од страна на клиентот е процес на управување со дозволите за пристап во рамките на мобилната апликација. Ова е ризично бидејќи потпирањето на клиентската страна може да ги изложи апликациите на пропусти како што се неовластен пристап и потенцијална измама.
Ако деловните функции на апликацијата (на пр., инстантирање на софтверски токени) бараат овластувања од страна на клиентот, се препорачува врзување на уредот (безбедносна практика која ги поврзува овластувањата за пристап до привилегии на одреден уред). Со имплементирање на врзување уред, апликациите може да го потврдат идентитетот на уредот и да воспостават доверба. Ова ги намалува ризиците поврзани со неовластен пристап и одржува безбедна, доверлива патека помеѓу уредите, апликациите и серверите.
Упатство за имплементација
Програмерите треба да воспостават врска помеѓу апликациите и уредот кога идентитетот на корисникот се користи за прв пат на нерегистриран мобилен уред.
Програмерите исто така треба да потврдат дека апликациите:
· Проверете дали има измени на уредот од последното време на работа. · Проверете дали има измени на маркерите за идентитет на уредот. · Проверете дали уредот што ја извршува апликацијата е во безбедна состојба (на пр. нема џеилбрејк или рутирање). Горенаведените се само некои ексampлес на техники за најдобра практика што ги користи индустријата. Како што се развива екосистемот на мобилните уреди, овие техники може да станат застарени. Како такви, програмерите треба да бидат во тек со најновите најдобри практики во индустријата за да ги потврдат врските на уредите. Работи што треба да се забележат
За да го потврдат уредот на уредите со Android, програмерите можат:
· Добијте уникатни идентификатори како IMEI или Android ID. · Враќање информации за изградбата. · Искористете ги природните карактеристики на OS API, како што е SafetyNet на Google.
За да го потврдат уредот на уредите со iOS, програмерите можат:
· Искористете ги домашните оперативни услуги, како што е ID на уредот на Apple преку UIdevice.
Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 316-317, 516. · Упатства за управување со технолошки ризик на MAS (2021), стр. 51, 56.
26

АВТОР-БП03
Контрола Апликацијата ги известува корисниците за сите потребни дозволи пред да почнат да ја користат апликацијата. Опис Потребните дозволи се специфични права и способности што апликацијата ги бара од мобилниот уред. Овие дозволи дефинираат до кои ресурси или функционалности може да пристапи апликацијата на уредите на корисниците. Некои бившиampТие вклучуваат, но не се ограничени на, камера, микрофон, локација итн. Со имплементирање на соодветни известувања кои ги информираат корисниците за какви дозволи се барани, програмерите можат да ги спречат корисниците несвесно да даваат прекумерни дозволи, што може да им овозможи на злонамерните актери да ги искористат пропустите и крадат чувствителни податоци (т.е. PII и податоци за автентикација). Ваквите известувања ќе им овозможат на корисниците да донесуваат информирани одлуки за апликациите што ги инсталираат. Упатство за имплементација Програмерите треба да користат предупредувања во апликација (во апликација) за да бараат од корисниците дозвола за пристап. Програмерите исто така треба да се погрижат Известувањата/Предупредувањата да не прикажуваат чувствителни податоци. Работи што треба да се забележат Програмерите треба да бараат само суштински дозволи за функционалноста на апликацијата. Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 56, 58. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 8, 18, 28. · Водич за програмери на Apple за приватност, https://developer.apple.com/design/human-interface-
упатства/приватност (јануари 2024). · Водич за програмери на Android за приватност, https://developer.android.com/quality/privacy-and-
безбедност (јан 2024).
27

АВТОР-БП04
Контрола Апликацијата ги известува корисниците за сите овластени и завршени трансакции со висок ризик.
Опис Ако апликацијата има функционалности за трансакција со висок ризик, корисниците треба веднаш да бидат известени кога трансакцијата е овластена и завршена. Со имплементирање на оваа контрола, програмерите можат да се погрижат корисниците веднаш да бидат свесни кога се овластени и завршени високоризичните трансакции за да можат да ги идентификуваат потенцијалните лажни трансакции што е можно поскоро.
Упатство за имплементација Програмерите треба да ги прифатат следниве методи за да го предупредат корисникот:
· Предупредувања во апликација (во апликација). · Известувања по е-пошта. · Известувања за услугата за кратки пораки (SMS). Програмерите исто така треба да се погрижат Известувањата/Предупредувањата да не прикажуваат чувствителни податоци.
Горенаведените се само некои ексampТехники за известување за најдобри практики што ги користи индустријата. Како што се развива екосистемот на мобилните уреди, овие техники може да станат застарени. Како такви, програмерите треба да бидат во тек со најновите најдобри практики во индустријата за да ги известат корисниците за овластени и завршени трансакции со висок ризик.
Работи што треба да се забележат Програмерите треба да бараат само основни дозволи за функционалноста на апликацијата.
Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Упатства за управување со технолошки ризик на MAS (2021), стр. 52. · Безбедносни упатства за прифаќање плаќања на PCI v2.0.0 (2017), стр. 10. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 8. · Водич за приватност за програмери на Apple, https://developer.apple.com/design/human-interface-
упатства/приватност (јануари 2024). · Водич за програмери на Android за приватност, https://developer.android.com/quality/privacy-and-
безбедност (јан 2024).
28

3. Складирање податоци (Податоци во мирување)

Вовед
Безбедноста на складирањето податоци за податоци во мирување се однесува на заштитата на интегритетот и доверливоста на чувствителните податоци (т.е. PII и податоци за автентикација) складирани локално на уредот од клиентот и на серверот на апликацијата кога тие активно не се користат или пренесуваат. Ова ги опфаќа најдобрите практики, заштитни мерки и техники за шифрирање кои се користат за да се обезбедат податоци складирани во бази на податоци, files, кеш, меморија и доверливо опкружување за извршување (TEE) на мобилни уреди и слични области во серверите за апликации.
Програмерите можат да обезбедат дека податоците на корисниците се зачувани и заштитени со спроведување силни безбедносни контроли за складирање на податоци во мирување. Соодветните контроли на податоци во мирување, исто така, гарантираат дека апликацијата може да ги ублажи ризиците од неовластен пристап, компромис на уредот, потенцијални прекршувања на податоците и протекување податоци и да ја зајакне одбраната на апликацијата.
Следните контроли гарантираат дека сите чувствителни податоци намерно складирани од апликацијата се соодветно заштитени, без оглед на целната локација. Исто така, покрива ненамерно протекување поради неправилна употреба на API или системски способности.
безбедносни контроли

Контрола

STORAGE-BP01 Чувајте чувствителни податоци кои се неопходни само за трансакции.

STORAGE-BP02 Спроведување на безбедно складирање на чувствителни податоци.

STORAGE-BP02a Чувајте ги чувствителните податоци безбедно на страната на серверот.

СКЛАДИРАЊЕ-BP02b

Чувајте ги чувствителните податоци безбедно на страната на клиентот во доверливо опкружување за извршување (TEE).

STORAGE-BP03 Бришење чувствителни податоци кога повеќе не е потребно.

СКЛАДИРАЊЕ-BP01
Контрола Апликацијата складира чувствителни податоци кои се неопходни само за трансакции. Опис Чувствителните податоци се дефинираат како кориснички податоци (PII) и податоци за автентикација (на пр., акредитиви, клучеви за шифрирање итн.) Програмерите треба да складираат само чувствителни податоци што се неопходни за деловните функции на апликациите. Акумулирањето на непотребни информации го зголемува влијанието на потенцијалните безбедносни прекршувања, што ја прави апликацијата привлечна цел за злонамерните актери. Со имплементирање на оваа безбедносна контрола, програмерите можат да обезбедат дека изложеноста е ограничена на податоците потребни за одредени деловни функции, минимизирајќи го влијанието во случај на неовластен пристап или прекршување на податоците. Упатство за имплементација Програмерите треба да ги класифицираат податоците што ги користи апликацијата врз основа на нивоата на чувствителност на организацијата и врз основа на законските барања. Програмерите треба да ги усвојат следните упатства за да ги обезбедат податоците што се класифицирани како чувствителни:
1. Имплементирајте безбедно решение за складирање врз основа на неговата чувствителност на страната на клиентот/страната на серверот. 2. Применете мерки за заштита на податоците (на пр. токенизирање, хаширање со сол, шифрирање) 3. Избришете чувствителни податоци кога повеќе не се потребни. Работи што треба да се забележат Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во: · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 190, 398. · Упатства за управување со технолошки ризик на MAS (2021), стр. 9-10, 36, 38. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 6.
31

СКЛАДИРАЊЕ-BP02
Контрола Апликацијата имплементира безбедно складирање на чувствителни податоци. Опис Безбедното складирање за мобилни апликации се однесува на спроведување техники и практики за заштита на чувствителните податоци складирани на мобилни уреди и сервери на апликации од неовластен пристап, кражба или тampеринг. Ова вклучува најдобри практики како што се шифрирање, хаширање, токенизација и правилни контроли за пристап. Со имплементирање на безбедно складирање, програмерите можат да го намалат неовластен пристап, компромис на уредот, потенцијални прекршувања на податоците и протекување податоци. Упатство за имплементација Програмерите треба да имплементираат безбедно решение за складирање кое ќе одговара на чувствителноста на податоците. Програмерите, исто така, треба да му дадат приоритет на следниот редослед за безбедно решение за складирање (од најчувствителни податоци до најмалку чувствителни податоци):
1. Од страна на серверот (сите чувствителни податоци треба да се складираат на серверот). 2. Клиентска страна во рамките на доверливо опкружување за извршување (во случај кога страната на серверот не е
можно, складирајте ги сите чувствителни податоци во TEE од страна на клиентот). Работи што треба да се забележат Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Стандард за верификација на безбедност на апликации за мобилни телефони OWASP (MASVS) v2.0.0 (2023), стр. 17-18. · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 190-203, 398-
406. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 06-07.
32

СКЛАДИРАЊЕ-BP02a
Контрола
Апликацијата чува чувствителни податоци безбедно на страната на серверот.
Опис
Складирањето чувствителни податоци на страната на серверот се однесува на складирање податоци на оддалечени сервери за апликации или бази на податоци. Таквиот пристап создава подобра средина за заштита на податоците од неовластен пристап или прекршување, овозможувајќи побезбедна контрола на пристапот, опции за спроведување подобри безбедносни мерки како што се посложени шифрирања и одредби за побрзи безбедносни ажурирања.
Со имплементирање на складирање на чувствителни податоци од страна на серверот, програмерите можат да ги ублажат вродените ризици од складирањето податоци од страната на клиентот, бидејќи складирањето на страната на клиентот е инхерентно поподложно на техниките за експлоатација на складирање податоци што вообичаено ги користат злонамерните актери во мобилните измами.
Упатство за имплементација
Програмерите треба да применат најмалку 1 од следниве мерки за заштита на податоците:
1. Само за лозинки, програмерите можат да користат хаширање со salt6. Наместо да се складираат вистинските лозинки, уникатни соли се генерираат и се комбинираат со лозинки, создавајќи солени хаши.
2. Програмерите можат да шифрираат7 чувствителни податоци со стандарди за шифрирање како што е AES-128. 3. Програмерите можат да имплементираат токенизација8 со самоуправувана токенизација или токенизација
услуга, заменувајќи ги чувствителните податоци со токени каде што е можно. Дополнително, програмерите треба да обезбедат токенизацијата да биде со доволна должина и сложеност (поддржана со сигурна криптографија) врз основа на чувствителноста на податоците и деловните потреби.
Горенаведените се само некои ексampод најдобрите практики што ги користи индустријата. Како што се развива екосистемот на мобилни уреди, овие најдобри практики може да станат застарени. Како такви, програмерите треба да ги следат најновите најдобри практики во индустријата за безбедно складирање чувствителни податоци на страната на серверот.
Работи кои треба да се забележат
Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Стандард за верификација на безбедност на апликации за мобилни телефони OWASP (MASVS) v2.0.0 (2023), стр. 19-20. · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 71-77, 219-227,
416-421. · Упатства за управување со технолошки ризик на MAS (2021), стр. 30, 36-37, 39. · Упатства за безбедност за прифаќање плаќања од PCI v2.0.0 (2017), стр. 9. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 6-9.
6 Хеширањето со сол се користи за да се додаде дополнителен слој на безбедност со тоа што го прави компјутерски интензивно за напаѓачите да ги дешифрираат оригиналните чувствителни податоци. Во контекст на складирање лозинка или изведување клучеви, програмерите треба да користат еднонасочни функции за изведување клучеви или бавни алгоритми за хаш, како што се PBKDF2, bcrypt или scrypt. 7 Шифрирањето се користи за трансформирање на податоците во нечитлив формат, осигурувајќи дека дури и ако се пристапи без овластување, чувствителните податоци остануваат доверливи. 8 Токенизацијата се користи за замена на чувствителни податоци со токени за да се минимизира ризикот од изложување на чувствителни податоци.
33

СКЛАДИРАЊЕ-BP02b
Контрола
Апликацијата чува чувствителни податоци безбедно на страната на клиентот во доверливо опкружување за извршување (TEE).
Опис
Доверливото опкружување за извршување (TEE) е изолирана област во хардверската или процесорската архитектура на мобилниот уред што обезбедува високо безбедна средина за складирање чувствителни податоци и извршување чувствителни или критични операции. Тој е дизајниран да ги заштити чувствителните податоци, криптографските клучеви и критичните процеси од неовластен пристап или т.ampеринг. Ако деловните функции на апликацијата бараат складирање на чувствителни податоци на клиентската страна, се препорачува да се складираат во TEE на уредот.
Со имплементирање на соодветно складирање на чувствителни податоци во TEE од страна на клиентот, програмерите можат да ги ублажат заканите кои потекнуваат од компромитиран уред и од надворешни злонамерни актери. Таквото складирање, исто така, може да го ублажи неовластен пристап до чувствителните податоци на корисникот на апликацијата и да спречи украдени клучеви за шифрирање.
Упатство за имплементација
Програмерите треба безбедно да складираат чувствителни податоци на страната на клиентот во доверливо опкружување за извршување (TEE) како што е TrustZone на Android ARM, безбедна енклава на Apple.
Програмерите, исто така, треба минимално да ја складираат следната листа на чувствителни податоци во TEE:
· Биометриски идентификатори. · Токени за автентикација. · Криптографски клучеви во безбеден систем за управување со клучеви како Android Keystore, iOS
Приврзок за клучеви.
Горенаведените се само некои ексampза тоа што развивачите на чувствителни податоци треба да складираат во TEE. Како што се развива екосистемот на мобилни уреди, програмерите треба да ја искористат слободата да ги складираат сите податоци за кои сметаат дека се неопходни да се складираат во TEE.
Работи кои треба да се забележат
За уреди без хардверски TEE, програмерите може да размислат за употреба на виртуелизирани TEE.
Алтернативно, програмерите може да размислат за оневозможување на апликацијата или оневозможување на функциите на високоризични трансакции на апликацијата, бидејќи апликацијата се смета за небезбедна за трансакции со висок ризик.
Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Стандард за верификација на безбедност на апликации за мобилни телефони OWASP (MASVS) v2.0.0 (2023), стр. 19-20. · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 75, 93, 194-200. · Упатства за управување со технолошки ризик на MAS (2021), стр. 51. · Безбедносни упатства за прифаќање плаќања на PCI v2.0.0 (2017), стр. 07-09, 14. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 10.
34

СКЛАДИРАЊЕ-BP03
Контрола
Апликацијата брише чувствителни податоци кога повеќе не е потребно.
Опис
Бришењето чувствителни податоци се однесува на процес на трајно отстранување или бришење на доверливи, приватни или чувствителни податоци од уреди за складирање, сервери или бази на податоци. Овој процес осигурува дека чувствителните податоци се неповратно отстранети и дека не може да им се пристапи, извадат, случајно да се изложат или да се реконструираат од неовластени поединци или преку методи за враќање на податоците.
Со имплементирање на овој процес, програмерите можат да го минимизираат прозорецот во кој напаѓачите можат да ги искористат пропустите за да украдат чувствителни податоци.
Упатство за имплементација
Програмерите треба да ги користат следните упорни безбедносни техники за складирање:
· Исчистете ги зачуваните колачиња при завршувањето на апликацијата или користете складирање колачиња во меморијата. · Отстранете ги сите чувствителни податоци при деинсталирањето на апликацијата. · Рачно отстранете ја целата база на податоци fileкои содржат чувствителни податоци (на пр. iOS WebView кешови) од
на file систем кога сродните деловни функции ќе престанат да постојат.
Горенаведените се само некои ексampод најдобрите практики што ги користи индустријата. Како што се развива екосистемот на мобилните уреди, овие техники може да станат застарени. Како такви, програмерите треба да ги следат најновите најдобри практики во индустријата за да ги бришат чувствителните податоци кога повеќе не се потребни.
Работи кои треба да се забележат
Програмерите треба да внимаваат да се придржуваат до широко прифатените стандарди и релевантниот закон за задржување податоци, вклучувајќи, но не ограничувајќи се на:
· Закон за заштита на лични податоци (PDPA) · Општа регулатива за заштита на податоци (GDPR) · Стандард за безбедност на податоци за индустријата за платежни картички (PCI DSS)
Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 199, 206-214, 403-414.
· Упатства за управување со технолошки ризик на MAS (2021), стр. 39. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 07, 09-10.
35

4. Анти-Тampering & Anti-Reversing

Вовед
Анти-Тampering и Anti-Reversing безбедносните контроли се дополнителни мерки што програмерите можат да ги спроведат за да се спротивстават на нападите кои се обидуваат да гиamper или апликации за обратен инженер. Со имплементирање на двете функции, програмерите додаваат повеќе слоеви на одбрана на апликациите, што им отежнува на злонамерните актери успешно да гиamper или апликации за обратен инженер, што може да резултира со:
· Кражба или компромис на вредни деловни средства како што се сопственички алгоритми, трговски тајни или чувствителни податоци,
· Финансиски загуби на корисници кои ја користат апликацијата за трансакции со висок ризик, · Финансиски загуби на организации поради губење на приходи или правна постапка, · Оштетување на репутацијата на брендот поради негативен публицитет или незадоволство на клиентите

Контролите гарантираат дека апликациите работат на доверливи платформи, спречувајќи тampработи за време на извршувањето и обезбедува интегритет на функционалностите на апликациите. Покрај тоа, контролите го попречуваат разбирањето така што им отежнуваат на напаѓачите да сфатат како функционираат апликациите.
безбедносни контроли

Контрола

RESILIENCE-BP01 Потпишете се со сертификати од официјални продавници за апликации.

RESILIENCE-BP02 Спроведување на jailbreak/root детекција. RESILIENCE-BP03 Спроведување на откривање на емулатор.

RESILIENCE-BP04 Спроведување на откривање против малициозен софтвер.

RESILIENCE-BP05 Спроведување на механизми против закачување.

RESILIENCE-BP06 Имплементирајте преклоп, далечински viewинг и контрамерки од екранот.

РЕЗИЛИЕНЦИЈА-БП07

Спроведување на снимање против тастатура или анти-тастатура против виртуелни тастатури од трети страни.

РЕЗИЛИЕНЦИЈА-БП01
Контрола
Апликацијата е потпишана со код со сертификати од официјални продавници за апликации.
Опис
Апликациите честопати се измамени од злонамерни актери и се дистрибуираат преку помалку строго регулирани канали. Потпишувањето на апликација со сертификати обезбедени од официјални продавници за апликации ги уверува мобилниот оперативен систем и корисниците дека мобилната апликација е од проверен извор.
Спроведувањето на потпишувањето код им помага на оперативните системи да одредат дали да дозволат софтверот да работи или инсталира врз основа на потписите или сертификатите што се користат за потпишување на кодот. Ова помага да се спречи инсталацијата и извршувањето на потенцијално штетните апликации. Дополнително, потпишувањето на кодот помага и при верификацијата на интегритетот, бидејќи потписите ќе се променат ако апликацијата е тampизведен со.
Упатство за имплементација
Програмерите треба да ги потпишуваат нивните апликации со код со сертификати. Овој дел обезбедува прampКако да го направите ова преку двете најпопуларни платформи iOS и Android.
За App Store на Apple, тоа може да се направи со запишување во Програмата за програмери на Apple и создавање барање за потпишување сертификат на порталот за програмери. Програмерите можат да се регистрираат за Програмата за програмери на Apple и може да се повикаат на следниов водич за програмери за потпишување код под нештата што треба да се забележат.
За Android, постојат различни продавници за апликации. За Play Store на Google, тоа може да се направи со конфигурирање на Play App Signing што е услов за дистрибуција преку Play Store на Google. За повеќе информации за тоа како да го направат тоа, програмерите може да го посетат водичот за програмери на Android под нештата што треба да се забележат.
За други официјални продавници, погледнете ги нивните соодветни упатства за програмери за потпишување на изворниот код на апликацијата. Работи што треба да се забележат Оваа безбедносна контрола е исто така услов за објавување апликации на официјални продавници за апликации, затоа што препораката е вашата апликација да биде потпишана со код со сертификати од официјални продавници за апликации. Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Програмски водич за програмери на Apple за потпишување код, https://developer.apple.com/support/code-signing (јан 2024).
· Водич за програмери на Android за приватност, https://developer.android.com/quality/privacy-andsecurity (јан 2024).
· Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 325-326, 522523.
· Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 21.
38

РЕЗИЛИЕНЦИЈА-БП02
Контрола
Апликацијата имплементира откривање на џеилбрејк или корен.
Опис
Вкоренетите и џеилбрејкуваните уреди генерално се сметаат за небезбедни. Уредите со корен или џеилбрејк им овозможуваат на корисниците да добијат зголемени привилегии, овозможувајќи полесно заобиколување на безбедносните и ограничувањата на ОС. Ваквите зголемени привилегии може да бидат небезбедни за апликациите бидејќи овие привилегии им дозволуваат на злонамерните актери потенцијално да ги искористуваат пропустите, да крадат ингеренции, да преземаат кориснички уреди и да извршуваат лажни трансакции со апликации.
Со имплементирање на откривање џеилбрејк или root, програмерите можат да спречат да се случат горенаведените експлоатирања, да ја заштитат интелектуалната сопственост на апликациите, да обезбедат стабилност на апликациите и да спречат заобиколување на системите во апликацијата.
Упатство за имплементација
Програмерите треба да имплементираат откривање на џеилбрејк или root со спроведување на следните проверки во нивната апликација за уреди со Android:
1. Проверете дали има суперкорисник или SU бинарно. 2. Откријте корен file системски промени. 3. Побарајте вкоренети апликации. 4. Проверете дали има сопствено обновување. 5. Проверете дали има небезбедно користење на API.
Програмерите треба да имплементираат откривање џеилбрејк или root со спроведување на следните проверки во нивната апликација за уреди со iOS:
1. Откријте ја употребата на ограничени API. 2. Побарајте измени за џеилбрејк како модови. 3. Побарајте неофицијални продавници за апликации, на пр., проверете дали има потпис на Cydia App Store. 4. Побарајте модификации на кернелот. 5. Проверете дали има интегритет на критичниот file системи. 6. Користете библиотеки од трета страна дизајнирани да детектираат уред тampеренг.
Горенаведените се само некои ексampпроверки на најдобри практики што ги користи индустријата. Како што се развива екосистемот на мобилни уреди, овие проверки може да станат застарени. Како такви, програмерите треба да ги следат најновите најдобри практики во индустријата за имплементирање на џеилбрејк или откривање корен.
39

Работи што треба да се забележат Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Стандард за верификација на безбедност на апликации за мобилни телефони OWASP (MASVS) v2.0.0 (2023), стр. 31. · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 319-320, 5069,
518-519. · Упатства за управување со технолошки ризик на MAS (2021), стр. 50. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 11, 23.
9 https://github.com/crazykid95/Backup-Mobile-Security-Report/blob/master/Jailbreak-Root-DetectionEvasion-Study-on-iOS-and-Android.pdf
40

РЕЗИЛИЕНЦИЈА-БП03
Контрола
Апликацијата имплементира откривање на емулатор.
Опис
Емулаторите се софтвер кој се користи за тестирање на мобилни апликации со тоа што му дозволува на корисникот да тестира мобилна апликација на различни имитирани мобилни верзии и уреди. Иако се корисни за тестирање, апликациите не треба да си дозволат да се монтираат на емулатори надвор од околината за развој.
Со имплементирање на откривање на емулација, програмерите можат да спречат злонамерни актери да извршуваат динамичка анализа, искоренување, дебагирање, инструментација, закачување и тестирање на fuzz на емулиран уред што можат да го контролираат. Притоа, програмерите можат да спречат злонамерни актери да откријат пропусти во апликацијата за експлоатација.
Упатство за имплементација
Програмерите треба да ја спроведат следнава стратегија за откривање за да ги идентификуваат карактеристиките за најчесто користените решенија за емулација. Некои препораки за работи што треба да се проверат се:
· Проверете ја употребата на батеријата. · Проверете го временскиот периодamps и часовници. · Проверете ги однесувањата со повеќе допир. · Проверете ја меморијата и анализата на перформансите. · Извршете мрежни проверки. · Проверете дали е базиран на хардвер. · Проверете на што се базира ОС. · Проверете дали има отпечатоци од прсти на уредот. · Проверете ги конфигурациите за изградба. · Проверете дали има услуги и апликации за емулатори.
Горенаведените се само некои ексampпроверки на најдобри практики што ги користи индустријата. Како што се развива екосистемот на мобилни уреди, овие проверки може да станат застарени. Како такви, програмерите треба да ги следат најновите најдобри практики во индустријата за имплементирање на откривање емулатори. Работи што треба да се забележат Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Стандард за верификација на безбедност на апликации за мобилни телефони OWASP (MASVS) v2.0.0 (2023), стр. 31-32. · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 325, 521.
41

РЕЗИЛИЕНЦИЈА-БП04
Контрола
Апликацијата имплементира откривање против малициозен софтвер.
Опис
Апликациите за малициозен софтвер се повеќе се користат од страна на злонамерните актери како вектор за компромитирање на мобилните уреди на корисниците бидејќи таквите уреди им ја обезбедуваат на корисниците удобноста потребна за извршување на секојдневните трансакции. Апликациите за малициозен софтвер првенствено ги користат функциите за странично вчитување како канал за да ги натераат корисниците да инсталираат малициозен софтвер на нивните уреди.
Со имплементирање на способности за откривање анти-малициозен софтвер на апликација за време на извршувањето, програмерите можат да спречат корисниците да бидат експлоатирани преку малициозен софтвер кој ги искористува пропустите на апликациите и пропустите на оперативниот систем, крадење акредитиви, преземање на уредот и извршување лажни трансакции.
Упатство за имплементација
Програмерите треба да имплементираат можности за откривање на анти-малициозен софтвер во нивните апликации. Ова може да се направи на различни начини, но не се ограничени на:
· Вклучете комплет за развој на софтвер (SDK) на Runtime-Application-Self-Protection (RASP) во нивните апликации.
· Користете RASP SDK за проверка и откривање на апликации за малициозен софтвер при извршување. · Проверете и спречете ги преклопувањата. · Спречете кликнување. · Спречете закачување на меморијата на апликацијата.
Горенаведените се само некои ексampпроверки на најдобри практики што ги користи индустријата. Како што се развива екосистемот на мобилни уреди, овие проверки може да станат застарени. Како такви, програмерите треба да ги следат најновите најдобри практики во индустријата за имплементација на откривање анти-малициозен софтвер.
Работи кои треба да се забележат
Доколку се открие каква било форма на злонамерност, програмерите треба да ја оневозможат апликацијата и да му ги дадат на корисникот потребните информации за тоа зошто апликацијата е оневозможена и да го повикаат корисникот да ги деинсталира злонамерните апликации на својот уред.
Алтернативно, програмерите треба да го предупредат корисникот и да ги оневозможат функциите со висок ризик на апликацијата додека корисникот не ги поправи злонамерните апликации. Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Стандард за верификација на безбедност на апликации за мобилни телефони OWASP (MASVS) v2.0.0 (2023), стр. 31. · Упатства за управување со технолошки ризик на MAS (2021), стр. 40, 49. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 23.
42

РЕЗИЛИЕНЦИЈА-БП05
Контрола
Апликацијата имплементира механизми против закачување.
Опис
Закачувањето се однесува на техника што ја користат напаѓачите за пресретнување или менување на однесувањето на мобилната апликација при извршување. Ова вклучува вметнување или закачување во текот на извршувањето на апликацијата за да ги следи нејзините активности, да го промени нејзиното однесување, да внесе злонамерен код или да ги измени постоечките функции на кодот за да ги искористи пропустите.
Со имплементирање механизми против закачување на апликациите, програмерите можат да спречат да се случат горенаведените напади и да спречат неовластен пристап, да ги заштитат операциите на трансакциите со висок ризик, да откријат и спречат т.ampобиди за измена и модификација, зачувување на интелектуалната сопственост и одржување на доверливоста на апликацијата.
Упатство за имплементација
Програмерите треба да го имплементираат следново на прampмеханизми за ублажување на нападите со закачување:
· Спроведување заштита за блокирање на инјекции на код. · Имплементирајте заштита за да спречите закачување на методот со спречување на модификации на апликацијата
изворниот код (и на клиентот и на серверот). · Имплементирајте заштита за да спречите извршување на изменети кодови во вашата апликација. · Имплементирајте заштита за да спречите пристап до меморијата и манипулација со меморијата за вашата апликација. · Спроведување на тamper отпорни алгоритми или анти-tampшто се појавуваат SDK (попознати како
SDK-и за време на траење-апликација-самозаштита). · Проверете дали има несигурни параметри како што се застарени API и параметри.
Горенаведените се само некои ексampпроверки на најдобри практики што ги користи индустријата. Како што се развива екосистемот на мобилни уреди, овие проверки може да станат застарени. Како такви, програмерите треба да ги следат најновите најдобри практики во индустријата за да имплементираат механизми против закачување. Работи што треба да се забележат Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Стандард за верификација на безбедност на апликации за мобилни телефони OWASP (MASVS) v2.0.0 (2023), стр. 31. · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 135-140, 189,
318-319, 339-340, 390, 520. · Упатства за управување со технолошки ризик на MAS (2021), стр. 56. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 23, 26.
43

РЕЗИЛИЕНЦИЈА-БП06
Контрола
Апликацијата имплементира преклопување, далечински viewинг и контрамерки од екранот.
Опис
Чувствителните информации може да се снимаат или снимаат без експлицитна согласност на корисникот кога апликацијата има функционалности за снимање на екран, слика од екранот или преклопување. За прampле:
· Нападите со преклопување ги мамат корисниците создавајќи лажен слој кој имитира доверливи апликации, со цел да украдат чувствителни податоци.
· Далечински управувач viewНападите вклучуваат неовластен пристап до екранот на уредот, дозволувајќи им на напаѓачите да собираат чувствителни податоци од далечина.
· Нападите од екранот се случуваат кога злонамерните актери го снимаат екранот на уредот без согласност од корисникот, извлекувајќи чувствителни податоци.
Спроведување на преклопување, далечински viewКонтрамерките за внесување и скриншот може да гарантираат дека чувствителните информации остануваат безбедни, приватноста на корисникот се одржува и чувствителните податоци се заштитени од ненамерно губење или злоупотреба.
Упатство за имплементација
Програмерите треба да имплементираат анти-тampпроверки и проверки против малициозен софтвер преку RASP SDK за да се спречат злонамерните апликации да користат преклопувања и далечински viewинг експлоатира.
За слики од екранот, програмерите можат да го користат знамето FLAG_SECURE за апликациите на Android и слични знаменца за iOS за да ги блокираат сите можности за слики од екранот кога ја користат апликацијата. Сепак, да претпоставиме дека деловните функции бараат можности за слики од екранот (на пр. Снимање слика од екранот на завршена трансакција PayNow). Во тој случај, препораката е да се оневозможат можностите за слики од екранот за екрани или страници што вклучуваат чувствителни податоци (PII и податоци за автентикација).
Програмерите може да размислат и за маскирање на влезот со чувствителни податоци и екрани со сензори кога апликацијата е заднина.
Работи кои треба да се забележат
Некои бившиampДеловите за тоа каде да се оневозможат овие можности за слики од екранот вклучуваат, но не се ограничени на: страници за најавување, страници за автентикација со повеќе фактори, безбедносни акредитиви и страници за промена на PII, итн.
Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Стандард за верификација на безбедност на апликации за мобилни телефони OWASP (MASVS) v2.0.0 (2023), стр. 31. · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 166-168, 257,
259, 265-267, 366, 480-481. · Упатства за управување со технолошки ризик на MAS (2021), стр. 56. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 8.
44

РЕЗИЛИЕНЦИЈА-БП07
Контрола
Апликацијата имплементира снимање против притискање на тастатурата или анти-тастатура против виртуелни тастатури од трети страни.
Опис
Снимањето со притискање на тастатурата и запишувањето на тастатурата се методи кои злонамерните актери ги користат за следење, евидентирање и снимање на копчињата притиснати на тастатурата без знаење и согласност на корисникот. Ова овозможува евидентирање и снимање на потенцијално чувствителни податоци (т.е. PII и податоци за автентикација).
Со имплементирање на контрамерки за притискање на тастатура и тастатура, програмерите можат да спречат непотребно губење на чувствителни податоци. Поконкретно, оваа контрола е насочена кон уредите со Android, бидејќи мајчината тастатура на уредите со Android може да се менува. Ваквите промени може да ги изложат апликациите на безбедносни пропусти бидејќи доверливата патека помеѓу влезовите на тастатурата и апликациите имаат недоверливи страни меѓу нив.
Упатство за имплементација
Програмерите не треба да дозволат да се користат несигурни виртуелни тастатури од трети страни за влезови што може да содржат чувствителни податоци. За таквите влезови се претпочита безбедна приспособена тастатура во апликација.
Со имплементирање на тастатура во апликација, програмерите можат да контролираат каде одат податоците за евиденција и да го намалат ризикот од несигурни виртуелни тастатури од трети страни кои дејствуваат како тастатура за снимање на тастатурата.
Заедно со користењето тастатури во апликацијата, програмерите треба да ги имплементираат следните предлози за влезови кои бараат чувствителни податоци (т.е. PII и податоци за автентикација): оневозможи автоматска корекција, автоматско пополнување, автоматско сугестија, сечење, копирање и залепување за функции/или апликации што содржат чувствителни податоци .
Работи што треба да се забележат Некои ексampФункциите што треба да ги користат тастатурите во апликацијата вклучуваат, но не се ограничени на најавување, внесување OTP или други фактори за верификација итн.
Оваа безбедносна контрола и најдобра практика првенствено се насочени кон уредите со Android. Главната цел е да се обезбеди сигурност на доверливиот пат. Бидејќи Android не обезбедува метод со кој може да се наметне употребата на оригинални/доверливи тастатури, програмерите треба да имплементираат тастатура во апликација за да се осигураат дека виртуелните тастатури од трета страна небезбедни не ги евидентираат информациите.
Спроведувањето на безбедна тастатура во апликацијата не ги ублажува ризиците поврзани со компромитиран уред.
Оваа безбедносна контрола е наведена во други стандарди. Ве молиме погледнете ја документацијата(ите) дадена во:
· Стандард за верификација на безбедност на апликации за мобилни телефони OWASP (MASVS) v2.0.0 (2023), стр. 31. · Водич за тестирање за безбедност на апликации за мобилни телефони OWASP (MASTG) v1.7.0 (2023), стр. 203, 214-215,
257, 259, 400, 414-415. · Упатства за управување со технолошки ризик на MAS (2021), стр. 56. · Насоки за безбеден развој на паметни телефони ENISA (2016), стр. 08, 23.
45

Референци

С/Н 1
2
3
4
5
6 7

Документ OWASP Стандард за верификација за безбедност на мобилни апликации (MASVS) v2.0.0 Водич за тестирање за безбедност на мобилни апликации (MASTG) v1.7.0 MAS Упатства за управување со ризици во технологијата, Упатства за безбедност за прифаќање плаќања за мобилни телефони PCI v2.0.0 Упатства за безбеден развој на паметни телефони ENISA Android Developercu Apple Devel

Извор OWASP
OWASP
MAS
PCI-DSS
ЕНИСА
Андроид Apple

Со датум од 2023 година
2023
2021
2017
2016
2024 2024

Документи / ресурси

Безбедна стандардна апликација CSA [pdf] Упатство за корисникот
Безбедна стандардна апликација, безбеден стандард, апликација

Референци

Упатство за употреба

Безбедна стандардна апликација

Информации за производот

Спецификации

За Стандардот

Цел, опсег и наменета публика

Известување и упатства за програмери

Дефиниции на документи и нормативни референци

Упатство за употреба на производот

Автентикација

Безбедносни контроли

AUTHN-BP01 – Повеќефакторска автентикација (MFA)

Упатство за имплементација

Најчесто поставувани прашања (ЧПП)

П: Која е целта на Стандардот за безбедна апликација на CSA?

П: Која е наменетата публика за безбедната апликација на CSA Стандардна?

П: Кои се придобивките од спроведувањето на Мулти-фактор Автентикација (MFA)?

Документи / ресурси

Референци

Поврзани мислења

Оставете коментар

Откажете го одговорот

П: Која е наменетата публика за безбедната апликација на CSA
Стандардна?

П: Кои се придобивките од спроведувањето на Мулти-фактор
Автентикација (MFA)?