Mengapa Ujian Penembusan API Penting bagi Organisasi

Mengapa Pentest API Memerlukan Tumpuan Tersendiri

Dahulu, pengujian aplikasi web meliputi 'segala-galanya' kerana logik tertumpu di pelayan dan keluarannya dalam bentuk HTML. Hari ini, aplikasi moden membahagikan logik antara klien (React, aplikasi mudah alih) dengan API bahagian belakang yang berkomunikasi dalam JSON. Permukaan serangan API kini boleh menjadi 5–10 kali lebih besar daripada antara muka pengguna (UI) yang menggunakannya.

Lebih rumit lagi, API kerap dipanggil oleh lebih daripada satu klien, iaitu aplikasi web, aplikasi mudah alih, integrasi rakan kongsi dan sistem dalaman. Setiap klien mungkin mempunyai keperluan pengesahan identiti yang berbeza, dan kawalan yang munasabah untuk satu klien mungkin tidak mencukupi untuk klien yang lain.

Pentest API yang baik mendekati API sebagai produk yang berasingan dengan model ancaman tersendiri. Pentest ini menguji setiap titik akhir bagi setiap peranan dan mencuba senario tanpa kebenaran, terutamanya cubaan untuk membaca atau mengubah data yang sepatutnya tidak boleh diakses oleh pemanggil.

OWASP API Top 10: Panduan Ringkas

OWASP API Security Top 10 ialah rujukan standard untuk pentest API. Berbeza daripada OWASP Web Top 10 yang menekankan suntikan (injection) dan XSS, versi API menekankan kebenaran akses dan pendedahan data.

• API1 Kebenaran Peringkat Objek yang Rosak (Broken Object Level Authorization, BOLA): yang paling biasa; pengguna A membaca data pengguna B.
• API2 Pengesahan Identiti yang Rosak (Broken Authentication): token boleh diteka, JWT tanpa pengesahan tandatangan.
• API3 Kebenaran Peringkat Sifat Objek yang Rosak (Broken Object Property Level Authorization): medan sensitif boleh diubah melalui penetapan pukal (mass assignment).
• API4 Penggunaan Sumber Tanpa Had (Unrestricted Resource Consumption): tiada had kadar, kos awan melonjak.
• API5 Kebenaran Peringkat Fungsi yang Rosak (Broken Function Level Authorization): titik akhir pentadbir boleh dipanggil oleh pengguna biasa.
• API6 Akses Tanpa Had kepada Aliran Perniagaan Sensitif (Unrestricted Access to Sensitive Business Flows): penyalahgunaan automasi pada proses pembayaran atau pendaftaran.
• API7 Pemalsuan Permintaan Sisi Pelayan (Server Side Request Forgery, SSRF): titik akhir menerima URL daripada pengguna.
• API8 Salah Konfigurasi Keselamatan (Security Misconfiguration): CORS yang terlalu longgar dan laluan nyahpepijat yang terdedah.
• API9 Pengurusan Inventori yang Tidak Betul (Improper Inventory Management): titik akhir v1 lama masih aktif dan terdedah kepada serangan.
• API10 Penggunaan API yang Tidak Selamat (Unsafe Consumption of APIs): bahagian belakang memanggil API pihak ketiga tanpa pengesahan input.

REST dan GraphQL: Perbezaan dalam Pentest

API REST tradisional mempunyai titik akhir yang berasingan seperti GET /users/123 atau POST /orders. Pentest REST melibatkan penyenaraian setiap titik akhir, percubaan pelbagai kaedah HTTP dan pengujian kebenaran akses pada setiap satu. Alat seperti Postman, Burp Suite dan ffuf sangat membantu.

Sebaliknya, GraphQL mempunyai satu titik akhir (biasanya /graphql) yang menerima pertanyaan (query) yang menentukan apa yang pengguna mahu. Hal ini mengubah model ancaman secara mendasar. Penguji perlu menyemak introspeksi (sama ada skema didedahkan), kedalaman pertanyaan (untuk serangan penafian perkhidmatan, DoS), pengelompokan permintaan (untuk memintas had kadar) dan kebenaran akses pada peringkat penyelesai.

Banyak organisasi mengaktifkan introspeksi GraphQL dalam produksi 'untuk kemudahan pembangun'. Tindakan ini setara dengan mendedahkan peta lengkap API kepada penyerang. Pentest GraphQL hampir selalu menemui perkara ini sebagai penemuan tahap sederhana hingga tinggi.

Peranan Swagger dan Postman dalam Penentuan Skop

Pentest API tanpa dokumentasi ibarat memetakan bandar tanpa peta. Ia boleh dilakukan, tetapi sangat tidak cekap. Penguji akan menghabiskan separuh masa tugasan hanya untuk mencari titik akhir. Sediakan spesifikasi OpenAPI/Swagger atau koleksi Postman sebagai sebahagian daripada penerimaan tugasan pentest.

Dokumentasi yang lengkap merangkumi senarai semua titik akhir, kaedah HTTP yang disokong, parameter (laluan, pertanyaan dan badan permintaan), pengesahan identiti yang diperlukan, serta contoh permintaan dan respons. Bagi GraphQL, sediakan skema yang lengkap atau benarkan introspeksi dalam persekitaran ujian.

Penguji juga akan membandingkan dokumentasi dengan keadaan sebenar dan biasanya menemui titik akhir yang 'tidak didokumentasikan' tetapi masih aktif. Inilah salah satu nilai pentest: bukan sekadar menguji perkara yang anda tahu wujud, tetapi menemui perkara yang anda lupa wujud.

Konteks Perbankan Terbuka dan BNM

Bank Negara Malaysia telah menggalakkan rangka kerja API terbuka untuk perbankan, dengan piawaian seperti spesifikasi BNM Open API untuk perkongsian data dan pemulaan pembayaran. Bagi institusi kewangan, ini bermakna beratus-ratus titik akhir API baharu yang didedahkan kepada rakan kongsi luaran seperti syarikat teknologi kewangan (fintech) dan pengagregat.

Setiap titik akhir dalam ekosistem ini perlu diuji dengan teliti. RMiT secara jelas menghendaki pengujian keselamatan API sebagai sebahagian daripada kitar hayat pembangunan. Penemuan API yang tidak diuruskan boleh menjadi vektor pelanggaran data atau penipuan pembayaran berskala besar.

Bagi fintech yang membangunkan perkhidmatan berasaskan API bank, ujian keselamatan dua hala adalah penting: API anda sendiri (yang didedahkan kepada pelanggan) dan integrasi anda dengan API bank (yang anda gunakan). Pentest yang berkualiti meliputi kedua-dua arah.

Penemuan Kritikal yang Berulang

Berdasarkan tugasan API yang kami jalankan, BOLA terus mendominasi senarai penemuan. Sebab utamanya ialah pembangun mengandaikan bahawa jika UI menghalang pengguna A daripada melihat data pengguna B, API juga selamat. Hakikatnya, API dipanggil terus melalui Burp atau Postman tanpa UI sebagai pengantara.

Penemuan biasa yang kedua ialah JWT yang tidak disahkan dengan betul: algoritma 'none' diterima, kunci rahsia yang lemah, atau pengepala alg daripada token dipercayai tanpa semakan (kes klasik). Penemuan ketiga ialah had kadar yang dilaksanakan pada proksi songsang tetapi boleh dipintas dengan menukar pengepala X-Forwarded-For.

Akhir sekali, terdapat kebocoran data dalam respons ralat. Banyak API mengembalikan jejak tindanan (stack trace) lengkap, pertanyaan SQL atau metadata struktur pangkalan data apabila ralat berlaku. Hal ini memberikan peta dalaman aplikasi kepada penyerang.