Apakah Ujian Penembusan Aplikasi Web? Panduan Keselamatan untuk PKS Malaysia

Mengapa PKS Malaysia menjadi sasaran utama

Sektor PKS menyumbang lebih daripada 38% KDNK Malaysia, dan kebanyakannya kini beroperasi dalam talian sepenuhnya: kedai e-dagang di Shopify atau WooCommerce, sistem tempahan tersuai dan portal pelanggan untuk perkhidmatan profesional. Penyerang oportunis telah lama beralih daripada hanya mengejar bank kepada PKS atas satu sebab praktikal, iaitu pulangan bagi setiap usaha lebih tinggi apabila pertahanan lemah.

Trend yang kami lihat dalam dua tahun kebelakangan ini di Malaysia ialah serangan perisian tebusan (ransomware) terhadap syarikat logistik, pengambilalihan akaun pengguna pada platform e-dagang, dan pencurian pangkalan data pelanggan daripada aplikasi program kesetiaan. Banyak PKS tidak menyedari bahawa pencurian data peribadi pelanggan ialah pelanggaran PDPA yang membawa implikasi denda dan reputasi.

Faktor yang menjadikan PKS mudah terdedah termasuk penggunaan rangka kerja sistem pengurusan kandungan (CMS) tanpa kemas kini berkala, pergantungan kepada pembangun bebas tanpa kajian keselamatan, ketiadaan tembok api aplikasi web (WAF), dan yang paling kritikal, ketiadaan pengujian keselamatan sebelum pelancaran. Pentest tahunan untuk aplikasi web utama kini merupakan pelaburan asas, bukan kemewahan.

OWASP Top 10 ringkas dalam bahasa Malaysia

OWASP Top 10 ialah senarai 10 kategori kerentanan aplikasi web yang paling kritikal dan dikemas kini setiap beberapa tahun. Walaupun bukan keseluruhan skop pentest, ia merupakan garis dasar yang perlu difahami oleh setiap penguji dan pembangun.

Versi terkini (2021, dengan kemas kini 2025) menumpukan perhatian pada kelemahan reka bentuk dan konfigurasi, bukan hanya pepijat pengaturcaraan. Ini mencerminkan hakikat bahawa kerentanan moden semakin kerap berlaku pada lapisan logik perniagaan dan integrasi, bukan sekadar sintaks SQL atau XSS klasik.

• A01 Kawalan Akses yang Rosak (Broken Access Control): pengguna mengakses sumber milik pengguna lain (IDOR, peningkatan keistimewaan).
• A02 Kegagalan Kriptografi (Cryptographic Failures): penyimpanan kata laluan yang tidak selamat, TLS lemah, kunci tertanam dalam kod.
• A03 Suntikan (Injection): suntikan SQL, suntikan arahan, suntikan LDAP.
• A04 Reka Bentuk yang Tidak Selamat (Insecure Design): kelemahan reka bentuk; tiada model ancaman.
• A05 Salah Konfigurasi Keselamatan (Security Misconfiguration): mod nyahpepijat dalam produksi, ketiadaan pengepala keselamatan.
• A06 Komponen yang Terdedah dan Lapuk (Vulnerable and Outdated Components): pustaka lapuk dengan CVE yang diketahui.
• A07 Kegagalan Pengenalan dan Pengesahan Identiti (Identification and Authentication Failures): pengesahan identiti yang rosak, penetapan sesi (session fixation).
• A08 Kegagalan Integriti Perisian dan Data (Software and Data Integrity Failures): rantaian bekalan, deserialisasi yang tidak selamat.
• A09 Kegagalan Pengelogan dan Pemantauan Keselamatan (Security Logging and Monitoring Failures): tiada jejak audit untuk forensik.
• A10 Pemalsuan Permintaan Sisi Pelayan (Server-Side Request Forgery, SSRF): eksploitasi panggilan rangkaian daripada pelayan.

Metodologi pentest aplikasi web: dari peninjauan hingga laporan

Pentest aplikasi web yang berkualiti mengikut fasa yang jelas. Fasa pertama, perancangan dan penentuan skop, menentukan aplikasi sasaran, peranan pengguna, persekitaran (biasanya ujian penerimaan pengguna (UAT) atau persekitaran pementasan yang mencerminkan produksi), dan peraturan penglibatan seperti waktu ujian dan vektor yang dilarang.

Fasa kedua, peninjauan dan penghitungan (reconnaissance dan enumeration), melibatkan pemetaan permukaan serangan: titik akhir, parameter, teknologi bahagian belakang, dan corak pengesahan identiti. Penguji menggunakan gabungan alat seperti Burp Suite Professional dan ffuf serta analisis manual untuk membina peta aplikasi.

Fasa ketiga, eksploitasi, ialah inti pentest. Penguji menguji setiap penemuan untuk mengesahkan bahawa ia boleh dieksploitasi dan menentukan impak sebenar. Ini berbeza daripada VA yang berhenti pada 'mungkin terdedah'. Fasa terakhir, pelaporan, menghasilkan dokumen teknikal yang mengandungi langkah untuk menghasilkan semula isu, bukti eksploitasi, klasifikasi CVSS, dan cadangan pemulihan yang khusus.

VA dan pentest: perbezaan yang sering dikelirukan

Penilaian kerentanan (vulnerability assessment, VA) menggunakan alat automatik seperti Nessus, Qualys atau OpenVAS untuk mengimbas senarai kerentanan yang diketahui. Ia luas, pantas dan baik untuk pemantauan berterusan. Namun, alat ini tidak memahami logik perniagaan, dan kerap menghasilkan banyak positif palsu serta terlepas kerentanan kontekstual.

Pentest ialah aktiviti yang dilakukan oleh manusia dan dipandu objektif. Penguji bukan sahaja mengimbas, malah mencuba mengeksploitasi, menggabungkan beberapa kerentanan kecil menjadi serangan yang ketara, dan mengesahkan impak. Pentest mendedahkan IDOR, keadaan perlumbaan (race condition), logik perniagaan yang rosak dan kelemahan kontekstual yang tidak dapat dikesan oleh pengimbas.

Bagi kebanyakan PKS Malaysia, gabungan kedua-duanya ialah pilihan yang betul: VA bulanan atau berterusan untuk memastikan tampalan keselamatan sentiasa dikemas kini, dan pentest manual tahunan (atau selepas perubahan besar) untuk kerentanan yang lebih mendalam.

Persediaan sebelum penglibatan

Pentest yang berjaya bermula dengan persediaan teknikal yang baik. Pertama, sediakan persekitaran pementasan atau UAT yang mencerminkan produksi sebanyak mungkin, termasuk data sampel, semua integrasi pihak ketiga (kotak pasir jika perlu), dan peranan pengguna yang relevan.

Kedua, sediakan kredensial ujian untuk setiap peranan: pelanggan biasa, pelanggan premium, pentadbir dan pengurus kewangan. Tanpa kredensial, penguji terpaksa bergantung pada ujian tanpa pengesahan identiti (unauthenticated testing) yang terlepas separuh permukaan serangan aplikasi.

Ketiga, sediakan senarai putih IP untuk alamat penguji dalam WAF dan pengehad kadar anda. Jika tidak, pengimbas pentest akan disekat dan masa penglibatan terbazir pada sekatan infrastruktur, bukan pada keselamatan aplikasi. Akhir sekali, maklumkan pasukan SOC atau pembekal perkhidmatan keselamatan terurus (MSSP) anda tentang tempoh ujian supaya respons insiden tidak dicetuskan tanpa sebab.

Penemuan biasa dalam aplikasi PKS Malaysia

Berdasarkan penglibatan yang kami jalankan untuk PKS dalam pelbagai sektor, iaitu e-dagang, teknologi pendidikan, klinik dan firma profesional, corak penemuan yang berulang sangat konsisten.

Yang pertama dan paling kritikal ialah pengesahan identiti yang rosak. Ini termasuk token sesi yang tidak dibatalkan semasa log keluar, tetapan semula kata laluan tanpa had kadar, dan pengesahan dua faktor (2FA) yang boleh dipintas melalui titik akhir API yang dilupakan. Yang kedua ialah IDOR (Insecure Direct Object Reference), misalnya pengguna A boleh mendapatkan invois pengguna B dengan menukar ID dalam URL.

Yang ketiga ialah XSS yang masih meluas, terutamanya dalam halaman papan pemuka pentadbir yang dianggap 'dalaman'. Yang keempat ialah kebocoran data dalam respons API yang termasuk medan yang tidak digunakan oleh antara muka pengguna (UI) tetapi mengandungi maklumat pengenalan peribadi (PII). Akhir sekali, terdapat masalah konfigurasi seperti CORS yang terlalu longgar, kekurangan CSP, dan titik akhir nyahpepijat yang ditinggalkan dalam produksi.

• Pengesahan identiti yang rosak: token tidak dibatalkan, pengesahan dua faktor (2FA) boleh dipintas.
• IDOR: invois, dokumen dan rekod pengguna lain boleh diakses.
• XSS tersimpan dalam papan pemuka pentadbir.
• Kebocoran PII dalam respons API.
• Salah konfigurasi CORS yang membenarkan asal (origin) yang tidak dipercayai.