Aplikasi Standar Aman
Informasi produk
Spesifikasi
- Jeneng Produk: Standar Aplikasi Aman CSA
- Versi: 1.0
- Tanggal Rilis: 10 Januari 2024
Babagan Standar
Standar Aplikasi Aman CSA minangka sakumpulan pedoman lan paling apik
praktik kanggo ngleksanakake kontrol keamanan otentikasi ing
aplikasi seluler. Tujuane kanggo njamin otentikasi sing aman
mekanisme lan nglindhungi data sensitif saka akses ora sah. Ing
standar dikembangake kanthi konsultasi karo macem-macem organisasi
lan ahli ing bidang cybersecurity.
Tujuan, Cakupan, lan Pemirsa
Tujuan Standar Aplikasi Aman CSA yaiku nyedhiyakake
pangembang kanthi rekomendasi lan praktik paling apik kanggo implementasine
kontrol otentikasi aman ing aplikasi seluler. Standar
ditrapake kanggo pangembang lan organisasi sing melu ing
pangembangan aplikasi seluler sing mbutuhake otentikasi. Iku
dirancang kanggo nambah keamanan sakabèhé saka otentikasi
proses lan nglindhungi privasi pangguna.
Kabar lan Pandhuan Pangembang
Standar Aplikasi Aman CSA nyedhiyakake panuntun dhumateng pangembang babagan
ngleksanakake kontrol keamanan otentikasi. Iku nandheske ing
pentinge ngetutake praktik paling apik ing industri lan njamin
implementasine aman saka mekanisme bukti asli. Pangembang
kudu ngrujuk marang standar kanggo pandhuan rinci babagan implementasine
kontrol keamanan dianjurake.
Definisi Dokumen lan Referensi Normatif
Standar Aplikasi Aman CSA kalebu definisi dokumen lan
referensi normatif sing menehi kajelasan ing terminologi digunakake
lan deleng standar lan pedoman industri liyane sing cocog.
Pangembang kudu ngrujuk marang definisi lan referensi iki kanggo a
pangerten luwih saka standar.
Pandhuan Panggunaan Produk
Authentication
Otentikasi minangka komponèn penting ing paling seluler
aplikasi. Iki verifikasi identitas pangguna, klien,
aplikasi, lan piranti sadurunge menehi akses menyang tartamtu
sumber daya utawa ngidini tumindak tartamtu. Standar Aplikasi Aman CSA
menehi rekomendasi lan praktik paling apik kanggo implementasine aman
kontrol otentikasi.
Kontrol Keamanan
Standar Aplikasi Aman CSA kalebu ing ngisor iki
kontrol keamanan otentikasi:
| ID | Kontrol |
|---|---|
| AUTHN-BP01 | Aplikasi nggunakake Multi-Factor Authentication (MFA) kanggo keasliane transaksi beresiko dhuwur. |
| AUTHN-BP02 | Katrangan kontrol |
| AUTHN-BP03 | Katrangan kontrol |
| AUTHN-BP04 | Katrangan kontrol |
| AUTHN-BP05 | Katrangan kontrol |
| AUTHN-BP06 | Katrangan kontrol |
AUTHN-BP01 – Multi-Factor Authentication (MFA)
Ing sistem otentikasi siji-faktor tradisional, pangguna
biasane mung perlu ngetik Something-You-Know (kayata jeneng panganggo
lan tembung sandhi). Nanging, MFA nambahake lapisan verifikasi identitas
kanthi mbutuhake faktor tambahan kaya Soko-Sampeyan-Duwe lan
Something-You-Are. Iki ndadekake luwih tantangan kanggo angkoro
aktor kanggo kompromi akun lan nambah keamanan sakabèhé saka
proses otentikasi.
Pedoman Pelaksanaan
Pangembang kudu ngleksanakake Step-up MFA, sing mbutuhake
tingkat otentikasi tambahan kanggo transaksi sing luwih berisiko. Ing
Standar Aplikasi Aman CSA ngutamakake MFA ing ngisor iki
kombinasi:
- Soko-Sampeyan-Ngerti
- Soko-Sampeyan-Duwe
- Something-You-Are
Pitakonan sing Sering Ditakoni (FAQ)
P: Apa tujuane Standar Aplikasi Aman CSA?
A: Tujuan saka CSA kang Aman App Standard kanggo nyedhiyani
pangembang kanthi rekomendasi lan praktik paling apik kanggo implementasine
kontrol otentikasi aman ing aplikasi seluler.
P: Sapa sing dadi pamirsa kanggo Aplikasi Aman CSA
Standar?
A: CSA kang Aman App Standard dimaksudaké kanggo pangembang lan
organisasi sing melu pangembangan aplikasi seluler
sing mbutuhake otentikasi.
P: Apa keuntungan saka ngleksanakake Multi-Factor
Otentikasi (MFA)?
A: Ngleksanakake MFA nambah lapisan verifikasi identitas, nggawe
luwih tantangan kanggo aktor angkoro kanggo kompromi akun lan
nambah keamanan sakabehe proses otentikasi.
1
CSA's Safe App Standard Version 1.0 Dirilis 10 Januari 2024
2
Konsultasi karo:
The Association of Banks Singapore, Standing Committee on Cyber Committee Deloitte Southeast Asia Risk Advisory Ernst & Young Advisory Pte. Ltd. KPMG di Singapura Lazada Microsoft Singapore PricewaterhouseCoopers Risk Services Pte. Ltd.
Penafian:
Organisasi kasebut dikonsultasi ing Standar kanggo umpan balik lan komentar babagan kontrol keamanan, deskripsi kontrol keamanan, lan pedoman implementasi teknis. Nganti maksimal sing diidinake miturut hukum, CSA, lan konsultan eksternal ora bakal tanggung jawab kanggo ora akurat, kesalahan lan / utawa ngilangi sing ana ing kene utawa kanggo kerugian utawa kerusakan apa wae (kalebu mundhut bathi, bisnis, niat apik, utawa reputasi. , lan/utawa karusakan khusus, insidental, utawa konsekuensial) sing ana gandhengane karo panggunaan utawa katergantungan ing Standar iki. Organisasi sing ngembangake aplikasi seluler, panyedhiya layanan lan pangembang disaranake nimbang carane Standar bisa ditrapake ing kahanan tartamtu kanggo entuk saran legal lan / utawa teknis dhewe babagan isi lan / utawa implementasine rekomendasi ing Organisasi Standar ngembangake seluler. app, panyedhiya layanan lan pangembang kudu ngleksanani pertimbangan profesional yen lan nalika ngleksanakake Rekomendasi ing Standar, lan uga kudu nimbang yen langkah tambahan perlu ing hubungan kanggo kahanan tartamtu.
3
Isine
Konsultasi Kanthi: ………………………………………………………………………………………………… 3 Penafian: … …………………………………………………………………………………………………. 3 Babagan Standar ……………………………………………………………………………………… 6 Tujuan, Cakupan, lan Dimaksudake Pemirsa …………………………………………………………………………… 6 Kabar lan Pandhuan Pangembang ……………………… …………………………………………………………………. 7 Definisi Dokumen lan Referensi Normatif ………………………………………………………………… 8 1. Otentikasi ………………………………… ………………………………………………………………… 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. Wewenang ………………………………………………………………………………………………… ….. 24 PENULIS-BP01 …………………………………………………………………………………………………………… .. 25 PENULIS-BP02 …………………………………………………………………………………………………. .26 PENULIS-BP03 ……………………………………………………………………………………….. 27 PENULIS-BP04 …………………………………………………………………………………………………………….. 28 …………………………………………………………………………………………………………… ….. 29 3. Panyimpenan Data (Data-at-Rest) ……………………………………………………………………………………… …. 30 PENYIMPANAN-BP01 ……………………………………………………………………………………………………………. 31 PENYIMPANAN-BP02 ……………………………………………………………………………………………………………. 32 PENYIMPANAN-BP02a …………………………………………………………………………………………………. 33 PENYIMPANAN-BP02b …………………………………………………………………………………………………. 34 PENYIMPANAN-BP03 ……………………………………………………………………………………………………………. 35 …………………………………………………………………………………………………………… ……….. 36 4. Anti-Tampering & Anti-Reversing…………………………………………………………………………..37 KETAHANAN-BP01 ……………………… ………………………………………………………………………………………. 38 KETAHANAN-BP02 …………………………………………………………………………………………………. 39
4
KETAHANAN-BP03 ………………………………………………………………………………………………. 41 KETAHANAN-BP04 …………………………………………………………………………………………………. 42 KETAHANAN-BP05 …………………………………………………………………………………………………. 43 KETAHANAN-BP06 …………………………………………………………………………………………………. 44 KETAHANAN-BP07 …………………………………………………………………………………………………. 45 Referensi ………………………………………………………………………………………………… 46
5
Babagan Standar
Pambuka Standar Aplikasi Aman minangka standar sing disaranake kanggo aplikasi seluler (aplikasi), sing dikembangake dening Badan Keamanan Siber Singapura (CSA), kanthi konsultasi karo mitra industri saka institusi finansial, organisasi teknologi, perusahaan konsultasi lan lembaga pemerintah. Swaraview Tujuan saka Standar kasebut yaiku nyedhiyakake garis dasar kontrol keamanan sing disaranake kanggo pangembang lan panyedhiya aplikasi seluler sing kudu dituruti. Iki bakal mesthekake yen kabeh aplikasi lokal netepi set kontrol keamanan sing padha kanggo aplikasi seluler, saéngga nambah tingkat keamanan aplikasi sing di-host lan digawe ing Singapura.
Tujuan, Cakupan, lan Pemirsa
Dokumen iki dikembangake kanggo menehi saran lan saran marang pangembang kanggo mbantu dheweke ngetrapake fungsi keamanan ing aplikasi kasebut. Rekomendasi lan saran kasebut ditujokake kanggo mbantu para pangembang kanggo nyuda spektrum ancaman keamanan siber lan nglindhungi aplikasi saka penipuan seluler paling anyar lan eksploitasi malware seluler. Isi ing kene ora naleni, diwenehake kanthi basis non-reliance lan tegese informatif, lan ora dimaksudake kanggo ngenali ancaman cybersecurity potensial utawa kanthi lengkap nemtokake proses utawa sistem sing kudu ditindakake pangembang kanggo ngatasi utawa nyegah. ancaman. Versi 1 saka pedoman lan kontrol keamanan Safe App Standard bakal fokus utamane kanggo nyedhiyakake pedoman keamanan kanggo pangembang aplikasi berisiko tinggi kanggo nglawan malware seluler paling anyar lan eksploitasi scam sing katon ing lanskap ancaman Singapura. Nanging, kontrol keamanan iki uga bisa entuk manfaat lan dileksanakake dening app liyane. Disaranake kabeh pangembang ngupayakake ngetrapake langkah-langkah kasebut kanggo nambah keamanan aplikasi seluler. Sanajan Standar iki nduweni area fokus utama, iterasi ing mangsa ngarep bakal nggedhekake kanggo ngatasi praktik keamanan lan pedoman paling apik kanggo kabeh tumpukan aplikasi seluler.
6
Kabar lan Pandhuan Pangembang
Iki document urip sing bakal tundhuk review lan revisi kanthi periodik. Kaya standar liyane sing ditetepake, Safe App Standard minangka dokumen urip sing bakal dianyari kanthi rutin kanggo cocog karo lanskap ancaman sing saiki lan berkembang lan vektor serangan anyar. Mangga deleng CSA kang websitus kanggo tetep dianyari karo versi paling anyar saka Aman App Standard lan adaptasi ngukur keamanan lan kontrol patut. Standar iki kudu diwaca bebarengan lan ora ngganti, beda-beda, utawa ngganti kewajiban lan kewajiban legal, peraturan, utawa liyane saka pangembang lan panyedhiya aplikasi, kalebu sing ana ing Cybersecurity Act 2018, lan peraturan tambahan, kode praktik, standar kinerja, utawa pituduh ditulis ing ngisor iki. Panganggone dokumen iki lan implementasine rekomendasi ing kene uga ora ngecualiake utawa kanthi otomatis ngeculake pangembang lan panyedhiya aplikasi saka kewajiban utawa tugas kasebut. Isi dokumen iki ora dimaksudake minangka pernyataan resmi saka hukum utawa sulih saran legal utawa profesional liyane. Pandhuan pangembang babagan kerangka keamanan Safe App Standard Supaya gampang digunakake, pangembang kudu nggatekake yen Versi 1 saka Safe App Standard ngarahake wilayah kritis ing ngisor iki, lan dokumen kasebut bisa dipérang dadi subbagian ing ngisor iki:
· Authentication · Wewenang · Panyimpenan Data (Data-at-Rest) · Anti-Tamper & Anti-Reversing Area kritis iki kalebu kanggo njamin standarisasi keamanan aplikasi seluler marang vektor serangan sing paling umum digunakake dening aktor jahat ing ekosistem lokal kita. Standar Aplikasi Aman nyedhiyakake set kontrol keamanan, pedoman, lan praktik paling apik sing jelas lan ringkes kanggo nambah keamanan aplikasi seluler sing nyedhiyakake utawa ngaktifake transaksi berisiko tinggi.
7
Definisi Dokumen lan Referensi Normatif
Definisi Dokumen Ing ngisor iki ana sawetara definisi sing kudu digatekake dening pangembang lan pamaca nalika nggunakake dokumen iki: Data sensitif Data pangguna kayata Informasi Identifikasi Pribadi (PII) lan data otentikasi kayata kredensial, kunci enkripsi, sandhi sepisan, data biometrik. , token keamanan, sertifikat, lsp. Transaksi beresiko dhuwur yaiku sing kalebu:
· Owah-owahan kanggo fungsi financial sawetara examples kalebu nanging ora winates kanggo registrasi rincian payee pihak katelu, nambah watesan transfer dana, etc.
· Miwiti transaksi finansial sawetara examples kalebu nanging ora winates kanggo transaksi dana dhuwur-nilai, transfer dana dhuwur-nilai, transaksi kertu online, akses debit langsung, fungsi panyimpenan dhuwit, lan top-up, etc.
· Owah-owahan ing konfigurasi keamanan aplikasi sawetara examples iki kalebu nanging ora winates kanggo mateni cara otentikasi, nganyari token digital utawa kapercayan, etc.
Kontrol keamanan Tindakan operasional utawa teknis sing disaranake ing dokumen iki sing kudu ditindakake kanggo ngatur, ngawasi, lan nyuda potensial kerentanan utawa kedadeyan keamanan. Kontrol keamanan iki duwe ID ing ngisor iki, contone, AUTHN-BP01, AUTHOR-BP01, STORAGE-BP01, RESILIENCE-BP01. Referensi Normatif Standar Aplikasi Aman ngrujuk standar industri saka Open Web Proyek Keamanan Aplikasi (OWASP), Badan Uni Eropa kanggo Keamanan Jaringan lan Informasi (ENISA) lan Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS). Dhaptar referensi kaya ing ngisor iki:
· OWASP's MASVS (Mobile Application Security Verification Standard) · OWASP's MASTG (Mobile Application Security Testing Guide) · ENISA's Secure Development Guidelines (SSDG) · PCI DSS' Mobile Payment Acceptance Security Guidelines for Developers
8
9
1. Authentication
Pambuka
Otentikasi minangka komponen penting ing umume aplikasi seluler. Aplikasi iki umume nggunakake macem-macem formulir otentikasi, kalebu biometrik, PIN, utawa generator kode otentikasi multi-faktor. Mesthekake mekanisme otentikasi aman lan dileksanakake miturut praktik paling apik ing industri iku penting kanggo ngesyahke identitas pangguna.
Kanthi ngleksanakake kontrol keamanan sing kuat kanggo otentikasi, pangembang bisa mesthekake yen mung pangguna, klien, aplikasi, lan piranti sing bisa diotentikasi bisa ngakses sumber daya tartamtu utawa nindakake tumindak tartamtu. Liwat kontrol otentikasi sing aman, pangembang uga bisa nyuda risiko akses data sing ora sah, njaga integritas data sensitif, njaga privasi pangguna lan nglindhungi integritas fungsi transaksi sing beresiko dhuwur.
Kontrol ing kategori iki tujuane kanggo menehi rekomendasi kontrol keamanan otentikasi sing kudu ditindakake aplikasi kanggo nglindhungi data sensitif lan nyegah akses sing ora sah. Iki uga menehi pangembang praktik paling apik sing cocog kanggo ngetrapake kontrol keamanan kasebut.
kontrol keamanan
ID
Kontrol
AUTHN-BP01 AUTHN-BP01a AUTHN-BP01b AUTHN-BP01c AUTHN-BP02 AUTHN-BP03 AUTHN-BP03a AUTHN-BP03b AUTHN-BP04 AUTHN-BP05 AUTHN-BP06
Gunakake Multi-Factor Authentication kanggo otentikasi transaksi beresiko dhuwur. Ngleksanakake otentikasi Something-You-Know minangka salah sawijining faktor MFA. Ngleksanakake otentikasi Something-You-Have minangka salah sawijining faktor MFA. Ngleksanakake otentikasi Something-You-Are minangka salah sawijining faktor MFA. Gunakake faktor adhedhasar konteks kanggo keasliane. Ngleksanakake otentikasi sesi aman. Ngleksanakake otentikasi stateful aman. Ngleksanakake otentikasi stateless aman. Ngleksanakake mandhek sesi aman nalika logout, ora aktif, utawa nutup aplikasi. Ngleksanakake pangayoman brute force kanggo otentikasi. Ngleksanakake mekanisme verifikasi integritas transaksi.
10
AUTHN-BP01
Kontrol
Aplikasi kasebut nggunakake Multi-Factor Authentication (MFA) kanggo otentikasi transaksi berisiko tinggi.
Katrangan
Ing sistem otentikasi siji-faktor tradisional, pangguna biasane mung kudu ngetik Something-YouKnow1 kayata jeneng pangguna lan sandhi. Nanging, yen faktor siji iki gagal utawa dikompromi, kabeh proses otentikasi rentan marang ancaman.
MFA minangka prosedur otentikasi sing nambahake lapisan verifikasi identitas, ora mung mbutuhake Something-You-Know nanging uga Something-You-Have2 lan Something-You-Are3. Ngleksanakake MFA ndadekake luwih tantangan kanggo aktor angkoro kanggo kompromi akun lan nambah keamanan sakabehe proses otentikasi.
Pandhuan implementasine
Pangembang kudu nggunakake Step-up MFA. Iki minangka jinis MFA tartamtu ing ngendi aplikasi kasebut nggabungake strategi otentikasi sing mbutuhake tingkat otentikasi tambahan, utamane nalika nyoba transaksi kanthi risiko sing luwih dhuwur.
Pangembang kudu menehi prioritas kombinasi MFA ing ngisor iki kanthi urutan 1, 2, 3, lan 4, kanthi pilihan 1 minangka pilihan sing paling aman.
Faktor / Opsi Soko-Sampeyan-Ngerti Soko-Sampeyan-Duwe
· Token piranti lunak · Token hardware · SMS OTP Something-You-Are
1
2
3
4
1 Something-You-Know nuduhake informasi sing pangguna ngerti, kayata PIN (Personal Identification Number), sandhi, utawa pola, lsp. 2 Something-You-Have nuduhake kepemilikan piranti, aplikasi, utawa token fisik ngasilake kredensial otentikasi, sing bisa uga kalebu Sandi Siji Wektu (OTPs) adhedhasar wektu. Examptoken kuwi kalebu token piranti lunak, token hardware, lan SMS OTP. 3 Something-You-Are nuduhake pengenal biometrik, ing ngendi karakteristik fisik unik pangguna digunakake kanggo verifikasi, kayata sidik jari, pindai retina, pangenalan rai, utawa pangenalan swara.
11
Pangembang banget disaranake supaya ora ngandelake SMS lan email OTP minangka saluran kanggo otentikasi kanggo transaksi berisiko tinggi. Yen ora bisa, penting kanggo ngetrapake faktor biometrik utawa faktor otentikasi tambahan bebarengan karo SMS OTP lan email OTP. Bab sing kudu dicathet
· Apike banget kanggo milih solusi sing ora bisa ditindakake yen bisa. · Pangembang kudu mesthekake yen paling siji faktor MFA wis diverifikasi ing sisih klien, karo kabeh
liyane diverifikasi ing sisih server. Ing kasus yen otentikasi diverifikasi ing sisih klien, utamane kanggo Android, tindakake kode adhedhasar Lingkungan Eksekusi Terpercaya (TEE). · Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
o OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 21.
o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 51, 56. o Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 34, 50. o Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 11.
12
Kontrol AUTHN-BP01a Aplikasi ngetrapake otentikasi Something-You-Know minangka salah sawijining faktor MFA. Deskripsi Something-You-Know nggambarake lapisan dhasar verifikasi identitas sing mung nglibatake informasi sing mung dikenal pangguna, kayata PIN (Personal Identification Number), sandi, pola, lan liya-liyane. tingkat dhasar verifikasi identitas kanthi mrintahake pangguna kanggo nyedhiyakake informasi unik sing ana gandhengane karo akun kasebut. Iki minangka faktor penting ing prinsip "Soko-Sampeyan-Ngerti, Soko-Sampeyan-Duwe, lan Soko-Sampeyan-Apa," nyumbang kanggo strategi keamanan multi-lapisan sing komprehensif lan efektif. Pandhuan implementasine Pangembang kudu ngetrapake pedoman ing ngisor iki kanggo nggawe sandhi sing kuwat lan aman:
· Priksa manawa dawa tembung sandhi minimal 12 karakter utawa luwih. · Kalebu campuran huruf gedhe lan cilik, angka, lan karakter khusus sing diwatesi
~`! @#$%^&*()_-+=:;,.? Pangembang uga kudu ngenali lan ngindhari pitfalls umum ing nggawe tembung sandhi:
· Aja nggunakake tembung, frase, utawa kombinasi sing bisa ditebak. · Aja nglebokake rincian pribadi. · Nyingkiri karakter urutan (contone, "123456") utawa karakter sing bola-bali (contone, "aaaaa"). Bab sing kudu dicathet · Pangembang kudu ngetrapake rotasi kredensial mung ing aset organisasi utawa yen ora ana
Implementasi MFA ing pangguna pungkasan, contone diganti saben taun utawa miturut jangka wektu sing cocog. · Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi (s)
kasedhiya ing: o MAS Technology Risk Management Guidelines (2021), pg. 34. o Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 10.
13
Kontrol AUTHN-BP01b Aplikasi ngetrapake otentikasi Something-You-Have minangka salah sawijining faktor MFA. Deskripsi Something-You-Have mbutuhake pangguna kanggo otentikasi nganggo piranti fisik, app, utawa token sing ngasilake kredensial otentikasi, sing bisa uga kalebu One-Time Sandi (OTP) adhedhasar wektu. Examptoken kuwi kalebu token piranti lunak, token hardware, lan SMS OTP. Ngleksanakake Something-You-Have minangka salah sawijining faktor MFA nambah kerumitan proses otentikasi kanthi mbutuhake unsur sing nyata, kanthi signifikan nyuda kemungkinan akses sing ora sah. Iki minangka faktor penting ing prinsip "Soko-Sampeyan-Ngerti, Soko-Sampeyan, lan Soko-Sampeyan-Apa," nyumbang kanggo strategi keamanan multi-lapisan sing komprehensif lan efektif. Pandhuan implementasine Pangembang kudu nggunakake OTP adhedhasar wektu kanggo token piranti lunak, token hardware lan SMS OTP. Pandhuan ing ngisor iki kudu ditindakake:
· OTP mung kudu valid ora luwih saka 30 detik. · OTP sing salah input sawise 3 nyoba kudu ora valid, lan sesi pangguna
kudu dicabut utawa ditolak. Bab sing kudu dicathet
· Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 56-57. o Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 50, 51. o Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 10.
14
AUTHN-BP01c
Kontrol Aplikasi ngetrapake otentikasi Something-You-Are minangka salah sawijining faktor MFA.
Deskripsi Something-You-Are mbutuhake pangguna kanggo otentikasi nganggo pengenal biometrik kayata sidik jari, pindai retina, utawa pangenalan rai. Ngleksanakake Something-You-Are minangka salah sawijining faktor MFA nambahake faktor otentikasi sing dipersonalisasi lan angel ditiru. Iki menehi cara sing luwih kuat kanggo verifikasi identitas pangguna tinimbang faktor Something-You-Know lan Something-You-Have, nyuda risiko akses sing ora sah. Iki minangka faktor penting ing prinsip "Soko-Sampeyan-Ngerti, Soko-Sampeyan-Duwe, lan Soko-Sampeyan," nyumbang kanggo strategi keamanan multi-lapisan sing komprehensif lan efektif. Pandhuan implementasine Pengembang kudu ngetrapake otentikasi biometrik sisih server nggunakake platform identifikasi biometrik sing dipercaya kaya Singpass. Nanging, yen ora bisa ditindakake, pangembang kudu ngetrapake otentikasi biometrik sisih klien liwat mekanisme Lingkungan Eksekusi Terpercaya (TEE) piranti kayata CryptoObject lan Konfirmasi Dilindungi Android kanggo layanan Android utawa Keychain kanggo iOS. Bab sing kudu dicathet
· Pangembang kudu mbatesi fungsi aplikasi ing piranti sing ora duwe hardware Trusted Executed Environment (TEE) utawa biometrik. Kanggo exampNanging, piranti Android kurang TEE bisa dideteksi nggunakake "isInsideSecureHardware" API Android.
· Pangembang kudu mbatalake otentikasi biometrik yen ana owah-owahan ing mekanisme biometrik, kayata ndhaptar bekas driji anyar ing piranti kasebut. Platform iOS lan Android ndhukung nyetel kunci crypto app supaya kadaluwarsa kanggo nanggepi owah-owahan kasebut.
· Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 227233, 422-426. o Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 51. o Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 11, 26.
15
AUTHN-BP02
Kontrol Aplikasi nggunakake faktor adhedhasar konteks kanggo keasliane. Katrangan Faktor adhedhasar konteks ngenalake unsur dinamis kayata lokasi pangguna lan atribut piranti. Nalika MFA nyedhiyakake lapisan keamanan sing kuat kanthi mbutuhake sawetara faktor otentikasi, nggabungake faktor basis konteks nggawe proses otentikasi sing luwih lengkap lan adaptif sing bisa menehi keuntungan tambahan kanggo ngatasi risiko sing berkembang saka akses sing ora sah. Ngleksanakake faktor adhedhasar konteks nyilikake katergantungan marang kredensial statis, dadi luwih tantangan kanggo aktor ala kanggo nyoba akses sing ora sah. Pandhuan implementasine Pangembang kudu nimbang faktor kontekstual ing ngisor iki kanggo verifikasi identitas pangguna:
· Geolokasi: Idini akses adhedhasar lokasi nyata piranti nggunakake GPS, Wi-Fi, utawa alamat IP geolokasi.
· Jinis Piranti: Idini akses adhedhasar karakteristik piranti. contone, ukuran layar bisa nemtokake manawa piranti iku smartphone utawa tablet.
Bab sing kudu dicathet Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 56, 58. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 11.
16
AUTHN-BP03
Kontrol Aplikasi ngetrapake otentikasi sesi aman. Katrangan Otentikasi sesi sing aman njamin manajemen sesi sing kuat kanggo otentikasi stateful lan stateless. Sesi sing ora dikelola kanthi apik, ora preduli apa aplikasi kasebut ngetutake metode otentikasi stateful4 utawa stateless5, bisa nyebabake ancaman keamanan kayata akses ora sah, pembajakan sesi, utawa pelanggaran data. Ngleksanakake otentikasi sesi sing aman kanggo sesi stateful nggunakake pengenal sesi sing aman, komunikasi sing dienkripsi lan wektu entek sing tepat kanggo nyegah akses sing ora sah. Kanggo otentikasi stateless, iku njamin sing token tamper-tahan, njaga integritas otentikasi tanpa gumantung ing panyimpenan sisih server. Pandhuan implementasine Pengembang kudu ngetrapake otentikasi sesi sing aman kanthi nggunakake praktik paling apik ing ngisor iki kanggo metode otentikasi stateful (AUTHN-BP03a) lan stateless (AUTHN-BP03b) kanggo sesi. Bab sing kudu dicathet Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 51-55. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 51. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 10.
4 Otentikasi stateful nuduhake manajemen negara sesi ing sisih server, biasane mbutuhake nggunakake pengenal sesi. 5 Otentikasi stateless nuduhake manajemen sesi tanpa nyimpen informasi sing gegandhengan karo pangguna ing sisih server.
17
Kontrol AUTHN-BP03a Aplikasi ngetrapake otentikasi stateful sing aman. Katrangan Otentikasi stateful sing aman kalebu nglindhungi lan njaga sesi sing terus-terusan. Nalika otentikasi stateful nyedhiyakake pengalaman pangguna sing lancar liwat sesi pangguna sing terus-terusan, bisa uga rentan marang macem-macem ancaman keamanan, kayata aktor jahat sing nyoba nyolong pengenal sesi. Ngleksanakake otentikasi stateful aman nglindhungi akun pangguna saka akses ora sah lan kerentanan potensial sing ana gandhengane karo manajemen sesi tanpa ngrusak keseimbangane antarane kegunaan lan keamanan. Pandhuan implementasine Pangembang kudu ngenali titik pungkasan sisih server sing nyedhiyakake informasi sensitif utawa fungsi kritis. Pangembang uga kudu nggunakake praktik paling apik otentikasi sesi stateful ing ngisor iki:
· Nolak panjalukan kanthi ID utawa token sesi sing ilang utawa ora valid. · Gawe ID Sesi kanthi acak ing sisih server tanpa ditambahake URLs. · Ningkatake keamanan ID Sesi kanthi dawa lan entropi sing tepat, nggawe angel ditebak. · Ijol-ijolan ID Sesi mung liwat sambungan HTTPS sing aman. · Aja nyimpen ID sesi ing panyimpenan sing terus-terusan. · Verifikasi ID sesi kanggo akses pangguna menyang unsur app sing duwe hak istimewa. · Mungkasi sesi ing sisih server, mbusak informasi sesi nalika entek utawa metu. Bab sing kudu dicathet Yen ana keraguan, coba gunakake platform lan protokol otentikasi sing dipercaya. Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 52.
18
Kontrol AUTHN-BP03b Aplikasi ngetrapake otentikasi stateless sing aman. Katrangan Otentikasi stateless sing aman kalebu praktik token sing aman kanggo otentikasi sing efektif lan bisa diukur. Nalika otentikasi tanpa negara menehi keuntungan, bisa uga luwih rentan marang ancaman keamanan kayata impersonation pangguna yen token ora digawe, dikirim lan disimpen kanthi aman. Ngleksanakake otentikasi stateless aman mesthekake yen saben token otentikasi ditangani kanthi aman nalika entuk keuntungan saka efisiensi lan skalabilitas, nyuda resiko akses sing ora sah. Pandhuan Implementasi Pangembang kudu nggunakake praktik paling apik otentikasi sesi stateless ing ngisor iki:
· Generate token ing sisih server tanpa appending menyang URLs. · Ningkatake keamanan token kanthi dawa lan entropi sing tepat, dadi angel ditebak. · Exchange token mung liwat sambungan HTTPS aman. · Priksa manawa ora ana data sensitif, kayata PII, sing diselehake ing token. · Aja nyimpen token ing panyimpenan sing terus-terusan. · Verifikasi token kanggo akses pangguna menyang unsur aplikasi sing duwe hak istimewa. · Mungkasi token ing sisih server, mbusak informasi token nalika entek utawa metu. · Cryptographically mlebu token nggunakake algoritma aman, ngindhari nggunakake null algoritma. Sing kudu dicathet · Yen ragu, coba gunakake platform lan protokol otentikasi sing dipercaya. · Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi (s)
kasedhiya ing: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 52-53.
19
AUTHN-BP04
Kontrol Aplikasi ngetrapake sesi aman nalika logout, ora aktif utawa nutup aplikasi. Katrangan Penghentian sesi sing aman njamin penutupan sesi pangguna sing efektif. Ing skenario kayata logout, ora aktif, utawa skenario penutupan aplikasi, ana potensial aktor ala kanggo ngeksploitasi titik akses sing isih ana yen sesi ora dikelola kanthi bener. Ngleksanakake mandap sesi aman sajrone logout, ora aktif utawa penutupan aplikasi bisa nyuda resiko akses ora sah kanthi otomatis mungkasi sesi pangguna lan nglindhungi informasi pangguna supaya ora diakses dening pihak sing ora sah. Pandhuan implementasine Pangembang kudu menehi otentikasi maneh pangguna sawise metu, aplikasi ora aktif, idleness, latar mburi, wektu entek mutlak, utawa penutupan tiba-tiba / paksa. Pangembang uga kudu ngasilake pengenal sesi anyar ing server nalika pangguna pindhah menyang tingkat otentikasi anyar kanggo nyegah fiksasi sesi. Bab sing kudu dicathet
· Pangembang kudu mesthekake yen mungkasi sesi kalebu ngresiki utawa deauthorizing kabeh token sing disimpen sacara lokal utawa pengenal sesi.
· Pangembang kudu nemtokake wektu entek idle adhedhasar risiko lan sifat layanan finansial.
· Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 55-56, 58. o Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 51. o Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 11.
20
AUTHN-BP05
Kontrol Aplikasi ngetrapake proteksi brute force kanggo otentikasi. Description Serangan pasukan brute melu nyoba otomatis lan sistematis kanggo guess Diverifikasi pangguna, contoneample, kanthi nyoba macem-macem kombinasi jeneng panganggo lan sandhi kanggo entuk akses ora sah. Perlindhungan brute force mbatesi jumlah nyoba mlebu sajrone wektu tartamtu. Ngleksanakake proteksi brute force kanggo otentikasi bisa nyuda resiko akses ora sah, nglindhungi akun pangguna lan njaga integritas proses otentikasi. Pandhuan implementasine Pengembang kudu ngetrapake mekanisme brute force liwat praktik paling apik ing ngisor iki:
· Ngleksanakake mriksa anti-otomatis. · Aplikasi watesan tarif kanggo nyoba mlebu. · Nggabungake wektu tundha tambahan progresif (contone 30 detik, 1 menit, 2 menit, 5
menit) kanggo nyoba mlebu. · Nindakake kunci akun. Bab sing kudu dicathet · Pangembang kudu dicathet yen kabeh mekanisme MFA rentan marang pasukan kasar. · Pangembang kudu menehi alasan kanggo ngunci akun lan nyedhiyakake sarana sing bisa diakses
kanggo pangguna kanggo otentikasi dhewe lan mbusak lockout. Examples kalebu nelpon helpline utawa nggunakake verifikasi biometrik. · Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
o Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 10, 16.
21
AUTHN-BP06
Kontrol Aplikasi ngetrapake mekanisme verifikasi integritas transaksi. Description Nalika otentikasi njamin identitas pangguna, iku ora ngilangke kamungkinan saka aktivitas fraudulent sak proses transaksi. Mekanisme verifikasi integritas transaksi minangka fungsi keamanan tambahan sing menehi wektu lan alat kanggo pangguna kanggo nanggepi kemungkinan penipuan. Ngleksanakake mekanisme verifikasi integritas transaksi mesthekake yen saben transaksi ditindakake kanthi teliti kanggo ngonfirmasi akurasi lan keasliane. Pandhuan Implementasi Pangembang bisa ngetrapake praktik paling apik sing disaranake:
· Miwiti telpon verifikasi / konfirmasi transaksi. · Nyedhiyani riwayat transaksi nyata-wektu. · Ngleksanakake wektu cooldown saka 12 jam kanggo 24 jam. · Pateni transaksi jaban rangkah kanthi gawan; ngaktifake mung liwat MFA. Bab sing kudu dicathet Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 57-58.
22
23
2. Wewenang
Pambuka
Keamanan wewenang dianggo bebarengan karo keamanan otentikasi. Keamanan wewenang ing aplikasi seluler minangka garis pertahanan sing penting amarga nggambarake sapa sing bisa ngakses sumber daya ing aplikasi. Iki nggawe kontrol sistematis lan validasi hak akses pangguna ing app.
Pangembang bisa mesthekake yen mung pangguna, klien, aplikasi, lan piranti sing sah sing bisa ngakses sumber daya tartamtu utawa nindakake tumindak tartamtu kanthi ngetrapake kontrol wewenang lan persiyapan wewenang sing kuwat. Liwat kontrol wewenang, pangembang uga bisa nyuda risiko akses data sing ora sah, njaga integritas data sensitif, njaga privasi pangguna lan nglindhungi integritas fungsi transaksi berisiko dhuwur. Sanajan penegakan mekanisme kasebut kudu ana ing titik pungkasan sing adoh, aplikasi sisih klien uga penting kanggo ngetutake praktik paling apik sing cocog kanggo njamin panggunaan protokol wewenang sing aman.
Kontrol ing kategori iki nyedhiyakake kontrol keamanan wewenang sing kudu ditindakake app kanggo njaga data sensitif lan nyegah akses sing ora sah. Iki uga menehi pangembang praktik paling apik babagan cara ngetrapake kontrol keamanan kasebut.
kontrol keamanan
ID
Kontrol
AUTHOR-BP01 Ngleksanakake wewenang sisih server.
AUTHOR-BP02 Ngleksanakake wewenang sisih klien liwat piranti naleni.
AUTHOR-BP03 Kabar pangguna kabeh ijin sing dibutuhake sadurunge miwiti nggunakake app.
PENULIS-BP04
Kabar pangguna kanggo kabeh transaksi beresiko dhuwur sing wis sah lan rampung.
24
PENULIS-BP01
Kontrol Aplikasi ngetrapake wewenang sisih server. Katrangan Otorisasi sisih server nuduhake validasi lan menehi ijin akses menyang pangguna utawa aplikasi dening server utawa server wewenang. Iki mesthekake yen kaputusan lan ijin kontrol akses diatur lan dileksanakake ing sisih server tinimbang klien. Kanthi ngleksanakake wewenang sisih server, pangembang nyuda kesempatan kanggo panyerang angkoro kanggo tamper utawa lulus langkah-langkah keamanan ing app kanggo entuk akses ora sah menyang data sensitif (yaiku PII lan data Authentication). Pandhuan implementasine Pengembang kudu ngetrapake wewenang sisih server sawise otentikasi sukses, sadurunge menehi ijin akses. Pangembang kudu mesthekake yen pangguna diwenehi akses adhedhasar ing ngisor iki:
· Peran sing ditugasake kanthi ijin: Priksa manawa pangguna mung bisa nindakake tugas sing cocog karo tanggung jawabe.
· Faktor kontekstual: Skenario akses dinamis kayata Wektu Akses lan Analisis Perilaku.
Bab sing kudu dicathet Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 50-55, 58. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), pg. 10. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 10-11.
25
PENULIS-BP02
Kontrol Aplikasi ngetrapake wewenang sisih klien liwat ikatan piranti.
Katrangan
Wewenang sisih klien yaiku proses ngatur ijin akses ing aplikasi seluler. Iki beboyo amarga gumantung ing sisih klien bisa mbukak aplikasi kanggo kerentanan kayata akses sing ora sah lan potensial penipuan.
Yen fungsi bisnis app (contone, instantiating token piranti lunak) mbutuhake wewenang sisih klien, disaranake ngiket piranti (praktik keamanan sing nggandhengake wewenang kanggo ngakses hak istimewa ing piranti tartamtu). Kanthi ngetrapake piranti naleni, app bisa verifikasi identitas piranti lan nggawe kapercayan. Iki nyuda risiko sing ana gandhengane karo akses sing ora sah lan njaga dalan sing aman lan dipercaya ing antarane piranti, aplikasi, lan server.
Pandhuan implementasine
Pangembang kudu nggawe ikatan antarane aplikasi lan piranti nalika identitas pangguna digunakake kanggo pisanan ing piranti seluler sing ora kadhaptar.
Pangembang uga kudu verifikasi manawa aplikasi:
· Priksa modifikasi piranti wiwit runtime pungkasan. · Priksa modifikasi kanggo tandha identitas piranti. · Priksa manawa piranti sing mbukak app ing negara aman (contone, ora jailbreaking utawa rooting). Ing ndhuwur mung sawetara mantanamples saka Techniques laku paling apik digunakake dening industri. Nalika ekosistem piranti seluler berkembang, teknik kasebut bisa uga dadi ketinggalan jaman. Dadi, para pangembang kudu ngupayakake praktik paling apik ing industri paling anyar kanggo verifikasi ikatan piranti. Bab sing kudu dicathet
Kanggo verifikasi piranti ing piranti Android, pangembang bisa:
· Entuk pengenal unik kaya IMEI utawa ID Android. · Njupuk informasi mbangun. · Manfaatake fitur API OS asli, kayata SafetyNet Google.
Kanggo verifikasi piranti ing piranti iOS, pangembang bisa:
· Gunakake layanan OS asli, kayata ID piranti Apple liwat UIDevice.
Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 316-317, 516. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 51, 56.
26
PENULIS-BP03
Kontrol Aplikasi ngabari pangguna kabeh ijin sing dibutuhake sadurunge miwiti nggunakake app. Katrangan Ijin sing dibutuhake minangka hak lan kapabilitas tartamtu sing dijaluk app saka piranti seluler. Ijin iki nemtokake sumber daya utawa fungsi apa sing bisa diakses aplikasi ing piranti pangguna. Sawetara mantanamples kalebu, nanging ora diwatesi, kamera, mikropon, lokasi, etc. Kanthi ngleksanakake kabar sing tepat sing ngandhani pangguna babagan ijin apa sing dijaluk, pangembang bisa nyegah pangguna kanthi ora sengaja menehi ijin sing berlebihan, sing bisa ngidini para aktor jahat ngeksploitasi kerentanan. lan nyolong data sensitif (yaiku PII lan Data Authentication). Kabar kasebut uga bakal ngidini pangguna nggawe keputusan babagan aplikasi sing diinstal. Pandhuan implementasine Pangembang kudu nggunakake tandha In-App (In-App) kanggo njaluk ijin akses pangguna. Pangembang uga kudu mesthekake yen Notifikasi / Tandha ora nampilake data sensitif. Bab sing kudu digatekake Pangembang mung kudu njaluk ijin penting kanggo fungsi app. Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 56, 58. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 8, 18, 28. · Pandhuan Pangembang Apple babagan Privasi, https://developer.apple.com/design/human-interface-
pedoman/privasi (Jan 2024). · Pandhuan Pangembang Android babagan Privasi, https://developer.android.com/quality/privacy-and-
keamanan (Jan 2024).
27
PENULIS-BP04
Kontrol Aplikasi ngabari pangguna kanggo kabeh transaksi beresiko dhuwur sing wis sah lan rampung.
Katrangan Yen app nduweni fungsi transaksi beresiko dhuwur, pangguna kudu dilaporake langsung yen transaksi wis diidinake lan rampung. Kanthi ngleksanakake kontrol iki, pangembang bisa mesthekake yen pangguna langsung weruh nalika transaksi beresiko dhuwur wis diidinake lan rampung supaya bisa ngenali potensial transaksi penipuan sanalika bisa.
Pandhuan implementasine Pangembang kudu nggunakake cara ing ngisor iki kanggo menehi tandha pangguna:
· In-Application (In-App) tandha. · Kabar email. · Notifikasi Short Message Service (SMS). Pangembang uga kudu mesthekake yen Notifikasi / Tandha ora nampilake data sensitif.
Ing ndhuwur mung sawetara mantanampteknik notifikasi praktik paling apik sing digunakake dening industri. Nalika ekosistem piranti seluler berkembang, teknik kasebut bisa uga dadi ketinggalan jaman. Dadi, para pangembang kudu ngupayakake praktik paling apik ing industri paling anyar kanggo menehi kabar marang pangguna babagan transaksi berisiko tinggi sing sah lan rampung.
Sing kudu digatekake Pangembang mung kudu njaluk ijin penting kanggo fungsi aplikasi.
Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 52. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), pg. 10. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 8. · Pandhuan Pangembang Apple babagan Privasi, https://developer.apple.com/design/human-interface-
pedoman/privasi (Jan 2024). · Pandhuan Pangembang Android babagan Privasi, https://developer.android.com/quality/privacy-and-
keamanan (Jan 2024).
28
29
3. Panyimpenan Data (Data-at-Rest)
Pambuka
Keamanan Panyimpenan Data kanggo data-at-rest yaiku kanggo njaga integritas lan rahasia data sensitif (yaiku data PII lan Otentikasi) sing disimpen sacara lokal ing piranti sisih klien lan sisih server app nalika ora aktif digunakake utawa ditularake. Iki kalebu praktik paling apik, langkah-langkah perlindungan lan teknik enkripsi sing digunakake kanggo ngamanake data sing disimpen ing basis data, files, caches, memori, lan Trusted Execution Environment (TEE) ing piranti seluler lan wilayah sing padha ing server app.
Pangembang bisa mesthekake yen data pangguna dilestarekake lan dilindhungi kanthi ngetrapake kontrol keamanan sing kuat kanggo nyimpen data kanthi istirahat. Kontrol data-at-rest sing tepat uga mesthekake yen app bisa ngurangi risiko akses ora sah, kompromi piranti, potensial pelanggaran data, lan data bocor lan nguatake pertahanan app.
Kontrol ing ngisor iki mesthekake yen data sensitif sing disengaja disimpen dening app wis dilindhungi kanthi cukup, preduli saka lokasi target. Iki uga nyakup bocor sing ora disengaja amarga nggunakake API utawa kemampuan sistem sing ora bener.
kontrol keamanan
ID
Kontrol
STORAGE-BP01 Simpen data sensitif sing mung perlu kanggo transaksi.
STORAGE-BP02 Ngleksanakake panyimpenan aman saka data sensitif.
STORAGE-BP02a Simpen data sensitif kanthi aman ing sisih server.
STORAGE-BP02b
Simpen data sensitif kanthi aman ing sisih klien ing Lingkungan Eksekusi Terpercaya (TEE).
STORAGE-BP03 Mbusak data sensitif yen ora perlu maneh.
30
STORAGE-BP01
Kontrol Aplikasi nyimpen data sensitif sing mung perlu kanggo transaksi. Katrangan Data sensitif ditetepake minangka data pangguna (PII) lan data otentikasi (contone, kredensial, kunci enkripsi, lsp.) Pangembang mung kudu nyimpen data sensitif sing perlu kanggo fungsi bisnis app. Nglumpukake informasi sing ora perlu nambah dampak saka pelanggaran keamanan potensial, nggawe aplikasi dadi target sing menarik kanggo para aktor sing jahat. Kanthi ngleksanakake kontrol keamanan iki, pangembang bisa mesthekake yen cahya diwatesi kanggo data sing dibutuhake kanggo fungsi bisnis tartamtu, minimalake impact yen ana akses sing ora sah utawa pelanggaran data. Pandhuan implementasine Pangembang kudu nggolongake data sing digunakake dening aplikasi adhedhasar tingkat sensitivitas organisasi lan adhedhasar syarat hukum. Pangembang kudu ngetrapake pedoman ing ngisor iki kanggo ngamanake data sing diklasifikasikake minangka sensitif:
1. Ngleksanakake solusi panyimpenan aman adhedhasar sensitivitas ing sisih klien / server-sisih. 2. Aplikasi langkah-langkah proteksi data (contone tokenising, hashing karo uyah, enkripsi) 3. Busak data sensitif yen ora perlu maneh. Bab sing kudu dicathet Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 190, 398. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 9-10, 36, 38. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 6.
31
STORAGE-BP02
Kontrol Aplikasi ngetrapake panyimpenan data sensitif sing aman. Katrangan Panyimpenan sing aman kanggo aplikasi seluler nuduhake teknik lan praktik kanggo nglindhungi data sensitif sing disimpen ing piranti seluler lan server app saka akses ora sah, nyolong utawa tampering. Iki kalebu praktik paling apik kayata enkripsi, hashing, tokenisasi, lan kontrol akses sing tepat. Kanthi ngetrapake panyimpenan sing aman, pangembang bisa nyuda akses ora sah, kompromi piranti, kemungkinan pelanggaran data lan bocor data. Pandhuan implementasine Pangembang kudu ngetrapake solusi panyimpenan sing aman sing cocog karo sensitivitas data. Pangembang uga kudu menehi prioritas ing urutan ngisor iki kanggo solusi panyimpenan sing aman (saka data sing paling sensitif nganti data sing paling sensitif):
1. Sisih server (kabeh data sensitif kudu disimpen ing sisih server). 2. Sisih klien ing Lingkungan Eksekusi Dipercaya (ing kasus ing sisih server ora
bisa, nyimpen kabeh data sensitif ing TEE sisih klien). Bab sing kudu dicathet Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 17-18. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 190-203, 398-
406. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 06-07.
32
STORAGE-BP02a
Kontrol
Aplikasi nyimpen data sensitif kanthi aman ing sisih server.
Katrangan
Nyimpen data sensitif ing sisih server nuduhake nyimpen data ing server app utawa database remot. Pendekatan kasebut nggawe lingkungan sing luwih apik kanggo nglindhungi data saka akses utawa pelanggaran sing ora sah, ngidini kontrol akses sing luwih aman, opsi kanggo ngetrapake langkah-langkah keamanan sing luwih apik kayata enkripsi sing luwih rumit lan pranata nganyari keamanan sing luwih cepet.
Kanthi ngetrapake panyimpenan data sensitif ing sisih server, pangembang bisa nyuda risiko panyimpenan data sisih klien, amarga panyimpenan sisih klien luwih rentan marang teknik eksploitasi panyimpenan data sing umum digunakake dening aktor jahat ing penipuan seluler.
Pandhuan implementasine
Pangembang kudu ngetrapake paling ora 1 saka langkah-langkah perlindungan data ing ngisor iki:
1. Kanggo sandhi mung, pangembang bisa nggunakake hashing karo salt6. Tinimbang nyimpen sandhi sing nyata, uyah unik digawe lan digabungake karo sandhi, nggawe hash asin.
2. Pangembang bisa encrypt7 data sensitif karo standar enkripsi kayata AES-128. 3. Pangembang bisa ngetrapake tokenisasi8 kanthi tokenisasi sing dikelola dhewe utawa tokenisasi
layanan, ngganti data sensitif karo token yen bisa. Kajaba iku, pangembang kudu njamin tokenisasi cukup dawa lan kerumitan (didhukung dening kriptografi aman) adhedhasar sensitivitas data lan kabutuhan bisnis.
Ing ndhuwur mung sawetara mantanamples saka praktik paling apik digunakake dening industri. Nalika ekosistem piranti seluler berkembang, praktik paling apik iki bisa uga dadi ketinggalan jaman. Dadi, pangembang kudu ngetutake praktik paling apik ing industri paling anyar kanggo nyimpen data sensitif kanthi aman ing sisih server.
Bab sing kudu dicathet
Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 19-20. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 71-77, 219-227,
416-421. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 30, 36-37, 39. · Pedoman Keamanan Penerimaan Pembayaran PCI Mobile v2.0.0 (2017), pg. 9. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 6-9.
6 Hashing karo uyah digunakake kanggo nambah lapisan keamanan ekstra kanthi nggawe komputasi intensif kanggo panyerang kanggo decipher data sensitif asli. Ing konteks panyimpenan sandi utawa derivasi kunci, pangembang kudu nggunakake fungsi derivasi tombol siji-arah utawa algoritma hash alon, kayata PBKDF2, bcrypt, utawa scrypt. 7 Enkripsi digunakake kanggo ngowahi data dadi format sing ora bisa diwaca, mesthekake yen sanajan diakses tanpa wewenang, data sensitif tetep rahasia. 8 Tokenisasi digunakake kanggo ngganti data sensitif karo token kanggo nyuda resiko paparan data sensitif.
33
STORAGE-BP02b
Kontrol
Aplikasi nyimpen data sensitif kanthi aman ing sisih klien ing Lingkungan Eksekusi Terpercaya (TEE).
Katrangan
Lingkungan Eksekusi Terpercaya (TEE) minangka area terisolasi ing arsitektur hardware utawa prosesor piranti seluler sing nyedhiyakake lingkungan sing aman banget kanggo nyimpen data sensitif lan nglakokake operasi sensitif utawa kritis. Iki dirancang kanggo nglindhungi data sensitif, kunci cryptographic lan proses kritis saka akses ora sah utawa tampering. Yen fungsi bisnis app mbutuhake panyimpenan data sensitif ing sisih klien, disaranake kanggo nyimpen ing TEE piranti.
Kanthi ngetrapake panyimpenan data sensitif sing tepat ing TEE sisih klien, pangembang bisa nyuda ancaman sing asale saka piranti sing dikompromi lan saka aktor jahat eksternal. Panyimpenan kasebut uga bisa nyuda akses ora sah menyang data sensitif pangguna ing aplikasi lan nyegah kunci enkripsi supaya ora dicolong.
Pandhuan implementasine
Pangembang kudu nyimpen data sensitif kanthi aman ing sisih klien ing Lingkungan Eksekusi Terpercaya (TEE) kayata Android's ARM's TrustZone, Apple's Secure Enclave.
Pangembang uga kudu nyimpen minimal dhaptar data sensitif ing TEE:
· Pengenal biometrik. · Token bukti asli. · Kunci kriptografi ing sistem manajemen kunci sing aman kayata Android Keystore, iOS
Gantungan kunci.
Ing ndhuwur mung sawetara mantanamples apa pangembang data sensitif kudu nyimpen ing TEE. Nalika ekosistem piranti seluler berkembang, pangembang kudu nggunakake kebebasan kanggo nyimpen data sing dianggep perlu kanggo disimpen ing TEE.
Bab sing kudu dicathet
Kanggo piranti tanpa TEE hardware, pangembang bisa nimbang panggunaan TEE virtual.
Utawa, pangembang bisa nimbang mateni app utawa mateni fungsi transaksi beresiko dhuwur saka app, amarga app dianggep ora aman kanggo transaksi beresiko dhuwur.
Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 19-20. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 75, 93, 194-200. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 51. · Pedoman Keamanan Penerimaan Pembayaran Mobile PCI v2.0.0 (2017), pg. 07-09, 14. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 10.
34
STORAGE-BP03
Kontrol
Aplikasi mbusak data sensitif yen ora perlu maneh.
Katrangan
Mbusak data sensitif nuduhake proses mbusak utawa mbusak data rahasia, pribadi utawa sensitif saka piranti panyimpenan, server utawa database kanthi permanen. Proses iki mesthekake yen data sensitif dibusak ora bisa dibalekake lan ora bisa diakses, dijupuk, ora sengaja kapapar, utawa dibangun maneh dening wong sing ora sah utawa liwat cara pemulihan data.
Kanthi ngleksanakake proses iki, pangembang bisa nyilikake jendhela ing ngendi panyerang bisa ngeksploitasi kerentanan kanggo nyolong data sensitif.
Pandhuan implementasine
Pangembang kudu nggunakake teknik keamanan panyimpenan sing terus-terusan ing ngisor iki:
· Mbusak cookie sing disimpen nalika mungkasi app utawa nggunakake panyimpenan cookie ing memori. · Mbusak kabeh data sensitif ing instal app. · Mbusak kabeh database kanthi manual files sing ngemot data sensitif (contone, iOS WebView caches) saka
ing file sistem nalika fungsi bisnis sing gegandhengan ora ana.
Ing ndhuwur mung sawetara mantanamples saka praktik paling apik digunakake dening industri. Nalika ekosistem piranti seluler berkembang, teknik kasebut bisa uga dadi ketinggalan jaman. Dadi, pangembang kudu ngetutake praktik paling apik ing industri paling anyar kanggo mbusak data sensitif yen ora perlu maneh.
Bab sing kudu dicathet
Pangembang kudu eling supaya netepi standar sing ditampa lan undang-undang panyimpenan data sing relevan kalebu nanging ora diwatesi:
· Personal Data Protection Act (PDPA) · General Data Protection Regulation (GDPR) · The Payment Card Industry Data Security Standard (PCI DSS)
Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 199, 206-214, 403-414.
· Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 39. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 07, 09-10.
35
36
4. Anti-Tampering & Anti-Reversing
Pambuka
Anti-TampKontrol keamanan lan Anti-Reversing minangka langkah tambahan sing bisa ditindakake para pangembang kanggo nglawan serangan sing nyoba nglawan.amper utawa aplikasi reverse engineer. Kanthi ngleksanakake loro fitur kasebut, pangembang nambahake pirang-pirang lapisan pertahanan menyang aplikasi, dadi luwih angel kanggo aktor jahat supaya bisa sukses.amper utawa aplikasi reverse engineer, sing bisa nyebabake:
· Nyolong utawa kompromi aset bisnis sing terkenal kayata algoritma kepemilikan, rahasia dagang, utawa data sensitif,
· Kerugian finansial saka pangguna sing nggunakake aplikasi kasebut kanggo transaksi berisiko tinggi, · Kerugian finansial organisasi amarga kelangan pendapatan utawa tindakan hukum, · Rusak reputasi merek amarga publisitas negatif utawa rasa ora puas pelanggan
Kontrol mesthekake yen app mbukak ing platform dipercaya, nyegah tampering ing runtime lan njamin integritas fungsi app. Kajaba iku, kontrol ngalangi pangerten kanthi nggawe angel para panyerang ngerteni kepiye cara aplikasi kasebut.
kontrol keamanan
ID
Kontrol
RESILIENCE-BP01 Mlebu karo sertifikat saka toko app resmi.
RESILIENCE-BP02 Ngleksanakake jailbreak / deteksi ROOT. RESILIENCE-BP03 Ngleksanakake deteksi emulator.
RESILIENCE-BP04 Ngleksanakake deteksi anti-malware.
RESILIENCE-BP05 Ngleksanakake mekanisme anti-hooking.
RESILIENCE-BP06 Ngleksanakake overlay, remot viewing, lan tangkapan layar.
KETAHANAN-BP07
Ngleksanakake anti-keystroke njupuk utawa anti-keylogger marang keyboard virtual pihak katelu.
37
KETAHANAN-BP01
Kontrol
Aplikasi kasebut ditandatangani kode kanthi sertifikat saka toko aplikasi resmi.
Katrangan
Aplikasi asring diapusi dening aktor jahat lan disebarake liwat saluran sing kurang diatur. Teken aplikasi kanthi sertifikat sing diwenehake dening toko aplikasi resmi njamin OS seluler lan pangguna yen aplikasi seluler kasebut saka sumber sing wis diverifikasi.
Ngleksanakake tandha kode mbantu sistem operasi nemtokake manawa bakal ngidini piranti lunak mbukak utawa nginstal adhedhasar tandha tangan utawa sertifikat sing digunakake kanggo mlebu kode kasebut. Iki mbantu nyegah instalasi lan eksekusi aplikasi sing bisa mbebayani. Kajaba iku, tandha kode uga mbantu verifikasi integritas, amarga teken bakal ganti yen app wis tampedan karo.
Pandhuan implementasine
Pangembang kudu menehi tandha kode aplikasi kanthi sertifikat. Bagian iki nyedhiyakake examples saka carane nindakake iki liwat loro platform paling populer iOS lan Android.
Kanggo Apple's App Store, bisa ditindakake kanthi ndhaptar ing Program Pangembang Apple lan nggawe panyuwunan tandha sertifikat ing portal pangembang. Pangembang bisa ndhaptar Program Pangembang Apple lan bisa ngrujuk pandhuan pangembang ing ngisor iki kanggo tandha kode ing ngisor iki sing kudu dicathet.
Kanggo Android, ana macem-macem toko App. Kanggo Google Play Store, bisa ditindakake kanthi ngonfigurasi Play App Signing sing dadi syarat distribusi liwat Google Play Store. Kanggo informasi luwih lengkap babagan carane nggawe pangembang bisa ngunjungi pandhuan pangembang Android ing bab sing kudu dicathet.
Kanggo toko resmi liyane, deleng pedoman pangembang masing-masing babagan tandha kode sumber aplikasi. Sing kudu dicathet Kontrol keamanan iki uga dadi syarat kanggo nerbitake aplikasi ing toko aplikasi resmi, mula, rekomendasi aplikasi sampeyan kudu ditandatangani kode kanthi sertifikat saka toko aplikasi resmi. Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· Apple Developer Program Guide for Code Signing, https://developer.apple.com/support/code-signing (Jan 2024).
· Pandhuan Pangembang Android babagan Privasi, https://developer.android.com/quality/privacy-andsecurity (Jan 2024).
· OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 325-326, 522523.
· ENISA Smartphone Secure Development Guidelines (2016), pg. 21.
38
KETAHANAN-BP02
Kontrol
App ngleksanakake jailbreak utawa deteksi ROOT.
Katrangan
Piranti sing wis bosok lan jailbroken umume dianggep ora aman. Piranti sing wis bosok utawa jailbroken ngidini pangguna entuk hak istimewa sing luwih dhuwur, supaya luwih gampang ngatasi watesan keamanan lan OS. Hak istimewa sing kaya ngono bisa dadi ora aman kanggo aplikasi amarga hak istimewa kasebut ngidini para aktor jahat duweni potensi ngeksploitasi kerentanan, nyolong kredensial, njupuk alih piranti pangguna lan nglakokake transaksi aplikasi penipuan.
Kanthi ngleksanakake jailbreak utawa deteksi root, pangembang bisa nyegah eksploitasi kasebut ing ndhuwur, nglindhungi properti intelektual aplikasi, njamin stabilitas aplikasi lan nyegah bypass sistem ing-app.
Pandhuan implementasine
Pangembang kudu ngetrapake jailbreak utawa deteksi ROOT kanthi ngleksanakake mriksa ing ngisor iki ing app kanggo piranti Android:
1. Priksa superuser utawa SU binar. 2. Ndeteksi ROOT file owah-owahan sistem. 3. Mangga madosi app bosok. 4. Priksa Recovery adat. 5. Priksa panggunaan API sing ora aman.
Pangembang kudu ngleksanakake jailbreak utawa deteksi ROOT kanthi ngleksanakake mriksa ing ngisor iki ing app kanggo piranti iOS:
1. Ndeteksi panggunaan API sing diwatesi. 2. Goleki njiwet jailbreak kaya mods. 3. Goleki toko app ora resmi, contone, mriksa tandha Cydia App Store. 4. Goleki modifikasi kernel. 5. Priksa integritas kritis file sistem. 6. Gunakake perpustakaan pihak katelu sing dirancang kanggo ndeteksi piranti tampering
Ing ndhuwur mung sawetara mantanamples saka praktik paling apik mriksa sing digunakake dening industri. Nalika ekosistem piranti seluler berkembang, pamriksaan kasebut bisa uga ora ana. Dadi, pangembang kudu ngetrapake praktik paling apik ing industri paling anyar kanggo ngetrapake jailbreak utawa deteksi root.
39
Bab sing kudu dicathet Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 319-320, 5069,
518-519. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 50. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 11, 23.
9 https://github.com/crazykid95/Backup-Mobile-Security-Report/blob/master/Jailbreak-Root-DetectionEvasion-Study-on-iOS-and-Android.pdf
40
KETAHANAN-BP03
Kontrol
App ngleksanakake deteksi emulator.
Katrangan
Emulator minangka piranti lunak sing digunakake kanggo nyoba aplikasi seluler kanthi ngidini pangguna nyoba aplikasi seluler ing macem-macem versi lan piranti seluler sing ditiru. Senajan migunani kanggo testing, app ngirim ora ngidini piyambak kanggo dipasang ing emulator njaba lingkungan pembangunan.
Kanthi ngleksanakake deteksi emulasi, pangembang bisa nyegah aktor jahat saka nglakokake analisis dinamis, rooting, debugging, instrumentasi, hooking, lan tes fuzz ing piranti sing bisa ditiru sing bisa dikontrol. Kanthi mengkono, pangembang bisa nyegah aktor jahat nemokake kerentanan ing aplikasi kanggo eksploitasi.
Pandhuan implementasine
Pangembang kudu ngetrapake strategi deteksi ing ngisor iki kanggo ngenali fitur kanggo solusi emulasi sing umum digunakake. Sawetara rekomendasi sing kudu dipriksa yaiku:
· Priksa panggunaan baterei. · Priksa wektuamps lan jam. · Priksa prilaku multi-tutul. · Priksa memori lan analisis kinerja. · Nindakake mriksa jaringan. · Priksa manawa iku adhedhasar hardware. · Priksa apa adhedhasar OS. · Priksa bekas driji piranti. · Priksa konfigurasi mbangun. · Priksa layanan lan aplikasi emulator.
Ing ndhuwur mung sawetara mantanamples saka praktik paling apik mriksa sing digunakake dening industri. Nalika ekosistem piranti seluler berkembang, pamriksaan kasebut bisa uga ora ana. Dadi, pangembang kudu ngetutake praktik paling apik ing industri paling anyar kanggo ngetrapake deteksi emulator. Bab sing kudu dicathet Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31-32. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 325, 521.
41
KETAHANAN-BP04
Kontrol
Aplikasi kasebut nindakake deteksi anti-malware.
Katrangan
Aplikasi malware tambah akeh digunakake dening aktor jahat minangka vektor kanggo kompromi piranti seluler pangguna amarga piranti kasebut nyedhiyakake pangguna kanthi kepenak sing dibutuhake kanggo nindakake transaksi saben dina. Aplikasi malware utamane nggunakake fitur sideloading minangka saluran supaya pangguna nginstal malware ing piranti kasebut.
Kanthi ngetrapake kemampuan deteksi anti-malware ing app nalika runtime, pangembang bisa nyegah pangguna supaya ora dieksploitasi liwat malware sing ngeksploitasi kerentanan aplikasi lan kerentanan OS, nyolong kredensial, njupuk alih piranti, lan nglakokake transaksi penipuan.
Pandhuan implementasine
Pangembang kudu ngetrapake kemampuan deteksi anti-malware ing aplikasi kasebut. Iki bisa ditindakake kanthi macem-macem cara, nanging ora diwatesi ing:
· Nggabungake Runtime-Application-Self-Protection (RASP) Software Development Kit (SDK) menyang app.
· Gunakake RASP SDK kanggo mriksa lan ndeteksi aplikasi malware nalika runtime. · Priksa lan nyegah overlay. · Nyegah clickjacking. · Nyegah memori app hooking.
Ing ndhuwur mung sawetara mantanamples saka praktik paling apik mriksa sing digunakake dening industri. Nalika ekosistem piranti seluler berkembang, pamriksaan kasebut bisa uga ora ana. Dadi, pangembang kudu ngetutake praktik paling apik ing industri paling anyar kanggo ngetrapake deteksi anti-malware.
Bab sing kudu dicathet
Yen ana wujud kejahatan sing dideteksi, pangembang kudu mateni aplikasi kasebut lan menehi informasi sing dibutuhake kanggo pangguna babagan sebabe aplikasi kasebut dipateni lan nggusah pangguna supaya instal aplikasi sing ala ing piranti kasebut.
Utawa, pangembang kudu ngelingake pangguna, lan mateni fungsi beresiko dhuwur ing aplikasi kasebut nganti pangguna ndandani aplikasi sing ala. Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 40, 49. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 23.
42
KETAHANAN-BP05
Kontrol
Aplikasi kasebut ngetrapake mekanisme anti-hooking.
Katrangan
Hooking nuduhake teknik sing digunakake dening panyerang kanggo nyegat utawa ngowahi prilaku aplikasi seluler nalika runtime. Iki kalebu nglebokake utawa nyambung menyang aliran eksekusi aplikasi kanggo ngawasi aktivitas, ngowahi prilaku, nyuntikake kode ala utawa ngowahi fungsi kode sing ana kanggo ngeksploitasi kerentanan.
Kanthi ngetrapake mekanisme anti-hooking ing aplikasi, pangembang bisa nyegah serangan ing ndhuwur lan nyegah akses sing ora sah, nglindhungi operasi transaksi sing beresiko dhuwur, ndeteksi lan nyegah tampering lan modifikasi nyoba, ngreksa properti intelektual lan njaga linuwih app.
Pandhuan implementasine
Pangembang kudu ngetrapake conto ing ngisor ikiampmekanisme kanggo ngurangi serangan hooking:
· Ngleksanakake proteksi kanggo mblokir injeksi kode. · Ngleksanakake pangayoman kanggo nyegah cara hooking dening nyegah modifikasi kanggo app
kode sumber (loro ing klien lan server). · Ngleksanakake proteksi kanggo nyegah eksekusi kode sing diowahi ing app sampeyan. · Ngleksanakake proteksi kanggo nyegah akses memori lan manipulasi memori kanggo app sampeyan. · Ngleksanakake tamper algoritma tahan utawa anti-tampering SDKs (umume dikenal minangka
Runtime-Application-Self-Protection SDKs). · Priksa paramèter sing ora aman kayata API lan paramèter sing lungse.
Ing ndhuwur mung sawetara mantanamples saka praktik paling apik mriksa sing digunakake dening industri. Nalika ekosistem piranti seluler berkembang, pamriksaan kasebut bisa uga ora ana. Dadi, pangembang kudu ngetutake praktik paling apik ing industri paling anyar kanggo ngetrapake mekanisme anti-hooking. Bab sing kudu dicathet Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 135-140, 189,
318-319, 339-340, 390, 520. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 56. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 23, 26.
43
KETAHANAN-BP06
Kontrol
App ngleksanakake overlay, remot viewing, lan tangkapan layar.
Katrangan
Informasi sensitif bisa dijupuk utawa direkam tanpa idin eksplisit pangguna nalika app duwe fungsi ngrekam layar, gambar utawa overlay. Kanggo example:
· Serangan overlay ngapusi pangguna kanthi nggawe lapisan palsu sing niru aplikasi sing dipercaya, ngarahake nyolong data sensitif.
· Remote viewserangan kalebu akses ora sah menyang layar piranti, ngidini panyerang kanggo harvest data sensitif saka adoh.
· Serangan tangkapan layar dumadi nalika aktor jahat nangkep layar piranti tanpa idin pangguna, ngekstrak data sensitif.
Implementasi overlay, remote viewTindakan pancegahan lan gambar layar bisa mesthekake yen informasi sensitif tetep aman, privasi pangguna dijunjung lan data sensitif dilindhungi saka mundhut utawa penyalahgunaan sing ora disengaja.
Pandhuan implementasine
Pangembang kudu ngetrapake anti-tampmriksa ering lan anti-malware liwat RASP SDK kanggo nyegah aplikasi angkoro nggunakake overlay, lan remot viewing exploitasi.
Kanggo gambar, pangembang bisa nggunakake gendera FLAG_SECURE kanggo aplikasi Android lan gendera sing padha kanggo iOS kanggo mblokir kabeh kemampuan gambar nalika nggunakake aplikasi kasebut. Nanging, umpamane fungsi bisnis mbutuhake kemampuan gambar (contone, njupuk gambar saka transaksi PayNow sing wis rampung). Ing kasus kasebut, rekomendasi yaiku mateni kemampuan gambar layar kanggo layar utawa kaca sing kalebu data sensitif (PII lan Data Otentikasi).
Pangembang uga bisa nimbang input masking karo data sensitif lan layar sensor nalika app latar mburi.
Bab sing kudu dicathet
Sawetara mantanamples saka ngendi kanggo mateni kemampuan gambar iki kalebu nanging ora winates ing: kaca mlebu, Multi-Factor Authentication kaca, Kredensial Keamanan, lan kaca ganti PII, etc.
Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 166-168, 257,
259, 265-267, 366, 480-481. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 56. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 8.
44
KETAHANAN-BP07
Kontrol
App ngleksanakake anti-keystroke njupuk utawa anti-keylogger marang keyboard virtual pihak katelu.
Katrangan
Pengambilan tombol lan keylogging minangka cara sing digunakake dening aktor jahat kanggo ngawasi, nyathet, lan ngrekam tombol sing ditekan ing keyboard tanpa kawruh lan idin pangguna. Iki ngidini logging lan njupuk data sing potensial sensitif (yaiku PII lan Data otentikasi).
Kanthi ngetrapake keystroke lan keylogging countermeasures, pangembang bisa nyegah mundhut data sensitif sing ora perlu. Luwih khusus, kontrol iki ngarahake piranti Android, amarga keyboard asli piranti Android bisa diganti. Owah-owahan kasebut bisa mbukak aplikasi kanggo kerentanan keamanan amarga dalan sing dipercaya ing antarane input keyboard lan aplikasi duwe pihak sing ora dipercaya ing antarane.
Pandhuan implementasine
Pangembang ngirim ora ngidini keyboard virtual pihak katelu sing ora aman digunakake kanggo input sing bisa ngemot data sensitif. Papan tombol khusus ing-app sing aman luwih disenengi kanggo input kasebut.
Kanthi ngleksanakake keyboard ing-app, pangembang bisa ngontrol menyang endi data logging lan nyuda risiko keyboard virtual pihak katelu sing ora aman sing tumindak minangka keylogger kanggo nangkep keystrokes.
Bebarengan karo nggunakake keyboard ing-app, pangembang kudu ngetrapake saran ing ngisor iki kanggo input sing mbutuhake data sensitif (yaiku PII lan Data Otentikasi): Pateni koreksi otomatis, isi otomatis, saran otomatis, potong, salin, lan tempel kanggo fungsi/utawa aplikasi sing ngemot data sensitif. .
Iku kanggo Wigati Sawetara exampSawetara fungsi sing kudu nggunakake keyboard ing-app kalebu nanging ora diwatesi kanggo mlebu log, ngetik OTP, utawa faktor verifikasi liyane, lsp.
Kontrol keamanan lan praktik paling apik iki utamane ngarahake piranti Android. Tujuan utama yaiku njamin keamanan dalan sing dipercaya. Amarga Android ora nyedhiyakake cara kanggo ngetrapake panggunaan keyboard asli/dipercaya, pangembang kudu ngetrapake keyboard ing-app kanggo mesthekake papan tombol virtual pihak katelu sing ora aman ora nyathet informasi.
Nerapake keyboard ing-app sing aman ora nyuda risiko sing ana gandhengane karo piranti sing dikompromi.
Kontrol keamanan iki dirujuk ing standar liyane. Mangga deleng dokumentasi sing kasedhiya ing:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 203, 214-215,
257, 259, 400, 414-415. · Pedoman Manajemen Risiko Teknologi MAS (2021), pg. 56. · Pedoman Pengembangan Aman Smartphone ENISA (2016), pg. 08, 23.
45
Referensi
S/N 1
2
3
4
5
6 7
Dokumen OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 MAS Technology Risk Management Guidelines, PCI Mobile Payment Acceptance Security Guidelines v2.0.0 ENISA Smartphone Secure Development Guides Android Developers Apple Developer Documentation
Sumber OWASP
OWASP
MAS
PCI-DSS
ENISA
Android Apple
Tanggal 2023
2023
2021
2017
2016
2024 2024
46
Dokumen / Sumber Daya
 |
CSA Aman Standar App [pdf] Pandhuan pangguna Aplikasi Standar Aman, Standar Aman, Aplikasi |
