Basic Web Security Testing — APIs | sempetbaca

Halo dan selamat datang kembali di artikel sempetbaca artikel kali ini tentang pengujian web keamanan dasar. Hari ini, kita akan melihat salah satu komponen terpenting dalam pengembangan perangkat lunak modern yang menetapkan protokol komunikasi untuk interaksi dalam sistem perangkat lunak - Application Programming Interface (API).

Karena OWASP memiliki cakupan yang baik tentang praktik keamanan untuk REST API (seperti daftar tajuk keamanan, CORS, menggunakan HTTPS alih-alih HTTP, penanganan kesalahan, dll), kami hanya akan melihat area lain yang dapat diuji dan diverifikasi oleh siapa pun. . 

Tanpa basa-basi lagi, mari selami

Catatan: Kami tidak akan membahas teori keamanan secara mendalam. Silakan baca di sini jika Anda ingin tahu lebih banyak.

Tes # 1: Kontrol akses diterapkan untuk semua API Sebagian besar sistem akan memiliki beberapa peran akses pengguna (yaitu peran admin dan pengguna dasar) yang menyediakan akses ke fitur tertentu. Misalnya, lihat diagram Matriks Kontrol Akses Pengguna (UAM) di bawah ini untuk pemesanan sistem lapangan bulu tangkis.

Jadi, akan ada fitur (atau API) yang tidak dapat diakses untuk peran tertentu (misalnya, menambah dan menghapus pengguna hanya dapat diakses oleh staf admin).

Bagaimana Anda dapat memverifikasi:

1. Masuk sebagai staf admin dan lakukan tindakan fitur khusus admin (mis. Melihat daftar akun staf)

2. Buka konsol browser> tab 'Jaringan'> Salin titik akhir API> Keluar

3. Masuk sebagai staf biasa dan tekan titik akhir ini secara langsung

4. API harus mengembalikan status 'Tidak Sah' atau 'Dilarang'

Tes # 2: Token dari pengguna A tidak dapat digunakan untuk pengguna B Seperti yang disebutkan di artikel kami sebelumnya tentang pengujian keamanan dasar untuk sesi web, semua token harus unik; token milik satu pengguna seharusnya tidak tersedia untuk pengguna lain. Jika sistem Anda menggunakan mekanisme token CSRF, harus ada pemetaan antara token CSRF dan token sesi / akses.

Bagaimana Anda dapat memverifikasi:

1. Masuk sebagai pengguna admin> Buka konsol browser> tab 'Aplikasi'

2. Salin semua token (mis. Sesi / akses dan token CSRF) ke file teks

3. Logout dan Login ke sistem sebagai pengguna staf biasa

4. Buka konsol browser> tab 'Aplikasi'

5. Ganti token CSRF saat ini dengan yang Anda salin sebelumnya

6. Lakukan tugas di sistem

7. Pengguna harus keluar dari aplikasi.

Tes # 3: Pesan kesalahan dari tanggapan API tidak terlalu spesifik Seringkali, orang, situs web, atau artikel akan memberi tahu Anda hal ini:

Benar ~ Memiliki pesan kesalahan yang mengungkapkan terlalu banyak kegagalan adalah seperti memberi tahu pencuri (yang ingin merampok rumah Anda) di mana kunci rumah Anda disimpan atau apa kode sandi kunci pintu Anda (jika Anda menggunakan kunci digital). Dan Anda mungkin bertanya-tanya:

Berikut beberapa contoh pesan kesalahan "terlalu spesifik":

Namun, memiliki terlalu sedikit informasi tentang kesalahan juga menjadi masalah bagi tim produk karena dapat mempersulit aktivitas debugging sistem.

Cara terbaik adalah memiliki kode status kesalahan, jenis kesalahan, dan pesan kesalahan yang umum (tapi ramah pengguna) dan menstandarkannya untuk semua API. Berikut beberapa contoh pesan kesalahan yang disarankan untuk ditampilkan:

Ada beberapa cara untuk menguji pesan kesalahan dari tanggapan API:

• Mengirim permintaan tanpa isi permintaan 'Content-Type'

• Mengirim permintaan dengan isi permintaan 'Content-Type' yang tidak valid

• Kirim permintaan tanpa sesi / token akses *

• Kirim permintaan dengan sesi / token akses yang tidak valid *

• Mengirim permintaan dengan format isi permintaan yang salah misalnya Jika permintaan menerima jenis JSON, kirim string JSON yang rusak seperti {"nama":}

• Kirim permintaan dengan username / password yang salah (untuk login)

* opsional: Beberapa sistem akan menyimpan token sesi / akses di suatu tempat alih-alih menerima permintaan API

Bisnis menggunakan API untuk menghubungkan layanan dan mentransfer data. API yang terpapar atau tidak aman berada di balik beberapa pelanggaran data utama karena mereka mengekspos data pribadi, keuangan, dan / atau medis yang sensitif untuk konsumsi publik. Tentu saja, tidak semua data sama atau harus dilindungi dengan cara yang sama; pendekatan untuk mengamankan API harus bergantung pada risiko sistem dan klasifikasi serta sensitivitas data. Oh! Kami telah menyusun daftar hal-hal yang harus diperhatikan, baik dari daftar periksa OWASP dan dari informasi di atas dalam artikel ini:

Anda mungkin juga ingin membaca artikel kami sebelumnya tentang pengujian keamanan dasar untuk web sessions dan file upload validation.

Oke sekian untuk artikel kali ini semoga membantu kalian yang ingin mulai belajar untuk melakukan pentesting pada API