req_id

Masukan Working Group

8.1.6

Akan mempertimbangkan kembali Persyaratan ini agar lebih dapat ditindaklanjuti (misalnya, Cadangan hanya boleh dipertahankan selama X waktu, Cadangan harus dipantau untuk mencegah pencurian/kerusakan, Cadangan harus diaudit secara rutin untuk mengonfirmasi kemampuannya dipindahkan kembali ke produksi). Asumsi saat ini terlalu luas dan memerlukan definisi lebih lanjut.

5.1.4

Duplikat kasus pengujian lainnya. Ini adalah kasus pengujian dengan upaya tinggi dan nilai rendah. Sebaiknya dihapus.

7.3.3

Duplikat kasus pengujian lainnya. Ini adalah kasus pengujian dengan upaya tinggi dan nilai rendah. Sebaiknya dihapus.

1.2.2

dihapus karena tercakup dalam persyaratan lain seperti 4.1.1

2.2.4

Hapus Req karena sudah dicakup oleh 4.3.1

(4.3.1 Verifikasi bahwa antarmuka administratif menggunakan autentikasi multi-faktor yang sesuai untuk

mencegah penggunaan yang tidak sah.) yang mencakup ketahanan terhadap peniruan identitas terhadap phishing di antarmuka admin dan jalur akses internal lainnya

2.2.5

Hapus karena mTLS tidak didukung oleh sebagian besar CSP, dan sebagian besar developer yang menguji CASA akan menggunakan autentikasi berbasis sandi

2.4.3

Standar sebagaimana ditulis tidak cukup spesifik untuk dapat diterapkan

2.4.5

Persyaratan dihapus di ASVS V5 dan algoritma hashing yang direkomendasikan di 2.4.1 tidak dapat memenuhi persyaratan ini

2.7.5

Pengujian tidak dapat dilakukan karena mungkin memerlukan analisis penyedia OOB pihak ketiga, risikonya rendah karena kode autentikasi berumur pendek.

2.8.2

persyaratan hanya relevan dengan solusi MFA kustom, juga dicakup oleh 6.4.2 dan 6.4.1

2.8.5

Menghapus persyaratan karena sudah tercakup dalam 2.7.6. Selain itu, upaya login yang gagal tercakup dalam persyaratan logging ASVS

2.8.6

OTP fisik di tingkat aplikasi bukanlah kasus penggunaan umum, permintaan ini diperlukan untuk antarmuka admin. Namun, persyaratan 4.3.1 (Verifikasi bahwa antarmuka administratif menggunakan autentikasi multi-faktor yang sesuai untuk mencegah penggunaan yang tidak sah.) mencakup MFA untuk antarmuka admin dan akan mencakup risiko ini

2.9.1

Persyaratan ini mencakup perangkat fisik sesuai dengan ASVS (Kunci keamanan kriptografi adalah kartu smart atau kunci FIDO, di mana pengguna harus mencolokkan atau menyambungkan

kriptografi ke komputer untuk menyelesaikan autentikasi. Verifier mengirim nonce tantangan ke

perangkat atau software kriptografi, dan perangkat atau software menghitung respons berdasarkan

kunci kriptografi yang disimpan.) sehingga persyaratan ini di luar cakupan CASA karena risiko autentikasi perangkat fisik tercakup dalam 4.3.1 untuk tujuan MFA (Fisik atau software)

2.9.3

Persyaratan ini mencakup perangkat fisik sesuai dengan ASVS (Kunci keamanan kriptografi adalah kartu smart atau kunci FIDO, di mana pengguna harus mencolokkan atau menyambungkan

kriptografi ke komputer untuk menyelesaikan autentikasi. Verifier mengirim nonce tantangan ke

perangkat atau software kriptografi, dan perangkat atau software menghitung respons berdasarkan

kunci kriptografi yang disimpan.) sehingga persyaratan ini di luar cakupan CASA karena risiko autentikasi perangkat fisik tercakup dalam 4.3.1 untuk tujuan MFA (Fisik atau software)

2.10.1

Persyaratan bertentangan dengan 2.10.2

2.10.3

Dicakup oleh 2.4.1 (Verifikasi bahwa salah satu fungsi hashing sandi berikut digunakan saat menyimpan sandi pengguna untuk aplikasi: argon2id, scrypt, bcrypt, atau PBKDF2) yang mencakup risiko serangan offline dan penyimpanan sandi.

2.10.4

Dicakup oleh 6.4.2 Verifikasi bahwa materi kunci tidak diekspos ke aplikasi, tetapi menggunakan modul keamanan terisolasi seperti vault untuk operasi kriptografis.

3.2.3

Dicakup oleh 3.4.1, 3.4.2, dan 3.4.3

3.5.1

Pengguna dapat mencabut token melalui penyedia OAuth

4.3.3

Req dicakup oleh MFA untuk antarmuka admin dan akses istimewa

5.1.3

Persyaratan ini tercakup dalam persyaratan validasi input lainnya dan Jika kurangnya validasi tidak menimbulkan kerentanan logika bisnis yang sebenarnya, maka ini dapat menjadi tingkat keparahan yang lebih rendah. Contohnya, jika nomor telepon tidak divalidasi dengan benar, nomor telepon tersebut hanya akan ditampilkan dengan tidak benar di halaman info, yang tidak memiliki implikasi keamanan langsung.

5.1.4

Persyaratan ini tercakup dalam persyaratan validasi input lainnya dan Jika kurangnya validasi tidak menimbulkan kerentanan logika bisnis yang sebenarnya, maka ini dapat menjadi tingkat keparahan yang lebih rendah. Contohnya, jika nomor telepon tidak divalidasi dengan benar, nomor telepon tersebut hanya akan ditampilkan dengan tidak benar di halaman info, yang tidak memiliki implikasi keamanan langsung.

5.3.2

Bagian dari persyaratan ini yang menentukan bahwa setiap karakter unicode yang valid dapat membuat pengujian menjadi sulit. Tidak semua aplikasi akan menyertakan formulir teks yang cukup besar untuk memuat setiap karakter Unicode. Selain itu, tidak ada dukungan untuk sistem operasi dan alat peretasan tertentu untuk seluruh ruang unicode sehingga Anda tidak dapat mengujinya meskipun server mendukungnya. Nilai keamanan secara keseluruhan dipertanyakan. Awalnya disertakan dalam versi beta, tetapi dihapus karena masalah dalam pengujian.

6.2.5

dicakup oleh 6.2.4 dan 6.2.3

6.2.6

dicakup oleh 6.2.4 dan 6.2.3

6.3.1

dicakup oleh 6.2.4 dan 6.2.3

6.3.3

dicakup oleh persyaratan pembuatan angka acak lainnya.

7.1.2

dicakup oleh 7.1.1

7.1.3

dicakup oleh 7.1.1

7.3.1

dicakup oleh 7.1.1

7.3.3

dicakup oleh 7.1.1

8.1.3

Sulit untuk mendeskripsikan parameter yang dapat diterima atau diperlukan. Bukan kasus yang dapat diuji. Apa yang dianggap perlu? Bagaimana cara menentukan apakah pengecualian valid? Dianggap di luar cakupan CASA

8.3.3

Bukan persyaratan yang dapat diuji, relevan dengan kebijakan privasi dan persyaratan layanan, bukan keamanan aplikasi. Ini adalah tinjauan kepatuhan dan hukum dan berada di luar cakupan CASA

8.3.6

Kontrol khusus sistem (varian Windows/Linux) dan khusus perangkat, dan dalam sebagian besar kasus bukan kontrol aplikasi.

8.3.8

dicakup oleh 1.8.1, 1.8.2, dan 1.1.4

9.2.5

yang tercakup dalam tinjauan kebijakan logging dan 8.3.5 dari aplikasi.

10.1.1

Dicakup oleh peninjauan arsitektur dan merupakan praktik terbaik yang direkomendasikan. Persyaratan tidak dapat diuji

10.2.3

Tidak dapat dilakukan dalam jangka waktu yang wajar. Setiap kode yang aneh harus didokumentasikan dan ditinjau, tetapi menetapkan tugas tertentu untuk memastikan tidak ada pintu belakang akan memerlukan peninjauan kode baris demi baris secara mendalam dan tidak menjamin bahwa tidak ada pintu belakang.

Sulit untuk menguji fungsi berbahaya yang dirancang dengan baik

10.2.4

Tidak ada cara untuk menguji. Tidak dapat dilakukan dalam jangka waktu yang wajar. Setiap kode yang aneh harus didokumentasikan dan ditinjau, tetapi menetapkan tugas tertentu untuk memastikan tidak ada pintu belakang akan memerlukan peninjauan kode baris demi baris secara mendalam dan tidak menjamin bahwa tidak ada pintu belakang.

Sulit untuk menguji fungsi berbahaya yang dirancang dengan baik

10.2.5

Tidak ada cara untuk menguji. Tidak dapat dilakukan dalam jangka waktu yang wajar. Setiap kode yang aneh harus didokumentasikan dan ditinjau, tetapi menetapkan tugas tertentu untuk memastikan tidak ada pintu belakang akan memerlukan peninjauan kode baris demi baris secara mendalam dan tidak menjamin bahwa tidak ada pintu belakang.

Sulit untuk menguji fungsi berbahaya yang dirancang dengan baik

13.1.1

Dicakup oleh 5.2.6 dan 5.3.9

12.3.1

risiko penjelajahan jalur yang tercakup dalam persyaratan lain yang ada dari bab 5 (Validasi, Sanitasi, dan Encoding) ASVS dan CASA

12.3.3

Dicakup oleh 5.2.6 dan 5.3.9

12.3.6

dicakup oleh 10.3.2 12.4.1 dan 12.4.2

12.5.1

dicakup oleh 10.3.2 dan 12.4.2

12.5.2

dicakup oleh 10.3.2 12.4.1 dan 12.4.2

13.1.5

Persyaratan ini tercakup dalam persyaratan validasi input lainnya dan Jika kurangnya validasi tidak menimbulkan kerentanan logika bisnis yang sebenarnya, maka ini dapat menjadi tingkat keparahan yang lebih rendah. Contohnya, jika nomor telepon tidak divalidasi dengan benar, nomor telepon tersebut hanya akan ditampilkan dengan tidak benar di halaman info, yang tidak memiliki implikasi keamanan langsung.

13.2.2

Persyaratan ini tercakup dalam persyaratan validasi input lainnya dan Jika kurangnya validasi tidak menimbulkan kerentanan logika bisnis yang sebenarnya, maka ini dapat menjadi tingkat keparahan yang lebih rendah. Contohnya, jika nomor telepon tidak divalidasi dengan benar, nomor telepon tersebut hanya akan ditampilkan dengan tidak benar di halaman info, yang tidak memiliki implikasi keamanan langsung.

13.2.3

Dicakup oleh 4.2.2

13.2.5

Persyaratan ini tercakup dalam persyaratan validasi input lainnya dan Jika kurangnya validasi tidak menimbulkan kerentanan logika bisnis yang sebenarnya, maka ini dapat menjadi tingkat keparahan yang lebih rendah. Contohnya, jika nomor telepon tidak divalidasi dengan benar, nomor telepon tersebut hanya akan ditampilkan dengan tidak benar di halaman info, yang tidak memiliki implikasi keamanan langsung.

13.3.1

Persyaratan ini tercakup dalam persyaratan validasi input lainnya dan Jika kurangnya validasi tidak menimbulkan kerentanan logika bisnis yang sebenarnya, maka ini dapat menjadi tingkat keparahan yang lebih rendah. Contohnya, jika nomor telepon tidak divalidasi dengan benar, nomor telepon tersebut hanya akan ditampilkan dengan tidak benar di halaman info, yang tidak memiliki implikasi keamanan langsung.

14.4.1

dicakup oleh 5.3.1

14.4.2

Persyaratan ini tercakup dalam persyaratan validasi input lainnya dan Jika kurangnya validasi tidak menimbulkan kerentanan logika bisnis yang sebenarnya, maka ini dapat menjadi tingkat keparahan yang lebih rendah. Contohnya, jika nomor telepon tidak divalidasi dengan benar, nomor telepon tersebut hanya akan ditampilkan dengan tidak benar di halaman info, yang tidak memiliki implikasi keamanan langsung.

14.4.3

dicakup oleh 5.2.7 dan 5.3.3

14.4.5

dicakup oleh 6.2.1 dan 9.2.1

14.4.7

dicakup oleh 12.4.1

14.5.3

dicakup oleh 14.5.2

2.1.5

dicakup oleh 2.1.1

2.1.6

dicakup oleh 2.1.1

2.2.3

Tidak relevan dengan casa karena risikonya tercakup oleh kontrol anti-otomatisasi lainnya

2.5.6

dilindungi oleh perlindungan sandi lain

3.1.1

Risiko paparan rendah dan tercakup oleh kontrol ASVS lainnya

3.2.1

Risiko paparan rendah dan tercakup oleh kontrol ASVS lainnya

3.4.4

Risiko paparan rendah dan tercakup oleh kontrol ASVS lainnya

3.4.5

Risiko paparan rendah dan tercakup oleh kontrol ASVS lainnya

4.2.1

dicakup oleh 13.1.4

5.2.8

dicakup oleh pemeriksaan validasi dan pembersihan input lainnya

5.3.5

dicakup oleh pemeriksaan validasi dan pembersihan input lainnya

7.4.1

dicakup oleh pemeriksaan logging

8.2.3

dicakup oleh 8.1.1

9.1.1

dicakup oleh 6.2.1 dan 9.2.1

1.2.3

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.4.4

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.5.2

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.5.3

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.5.4

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.9.1

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.11.3

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.14.1

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.14.2

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.14.3

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.14.4

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.14.5

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

1.14.6

dicakup oleh 1.1.4, 1.8.4, dan 1.8.2

6.1.2

Dicakup oleh 6.1.1

6.1.3

Dicakup oleh 6.1.1

2.10.2

Dicakup oleh 2.5.4

2.2.1

Dicakup oleh 11.1.4

2.7.3

Dicakup oleh 2.7.2

2.7.4

Dicakup oleh 2.7.2

5.1.2

Dicakup oleh Kontrol Anti-Otomatisasi

6.2.2

algoritma kriptografi yang disetujui tidak ditentukan

8.2.1

Dicakup oleh 8.1.1

9.1.2

Dicakup oleh 9.2.1

9.1.3

Dicakup oleh 9.2.1

5.5.1

Dicakup oleh 1.8.2

14.2.1

Dicakup oleh 1.14.6

3.3.4

Hal ini tidak berlaku untuk aplikasi yang menggunakan AuthN/Z stateless. Setuju dengan rekomendasi NCC Group untuk menghapus. Hal ini harus dicakup oleh 3.3.3

req_id

Deskripsi

1.1.4

Verifikasi dokumentasi dan justifikasi semua batas kepercayaan, komponen, dan alur data signifikan aplikasi.

1.8.1

Memastikan bahwa semua data sensitif diidentifikasi dan diklasifikasikan ke dalam tingkat perlindungan

1.8.2

Pastikan semua tingkat perlindungan memiliki serangkaian persyaratan perlindungan terkait, seperti persyaratan enkripsi, persyaratan integritas, retensi, privasi, dan persyaratan kerahasiaan lainnya, serta persyaratan ini

diterapkan dalam arsitektur.

2.1.1

Memverifikasi bahwa sandi yang ditetapkan pengguna memiliki panjang minimal 12 karakter

2.5.4

Pastikan akun bersama atau default tidak ada (misalnya, "root",

"admin", atau "sa").

4.2.1

Pastikan data dan API sensitif dilindungi dari serangan Insecure Direct Object Reference (IDOR) yang menargetkan pembuatan, pembacaan, pembaruan, dan penghapusan catatan, seperti membuat atau memperbarui catatan orang lain, melihat catatan semua orang, atau menghapus semua catatan.

1.14.6

Pastikan aplikasi tidak menggunakan API yang tidak didukung, tidak aman, atau tidak digunakan lagi

teknologi sisi klien seperti plugin NSAPI, Flash, Shockwave, ActiveX,

Silverlight, NACL, atau applet Java sisi klien.