Burp Suite: analisis request dan response dalam makmal
Jejak satu tindakan pengguna dan bandingkan hasil selepas perubahan terkawal. Sediakan bukti yang boleh disemak tanpa mendedahkan data sensitif.

Executive Summary
Burp Proxy menjadi perantara antara browser dengan aplikasi. Ia membolehkan trafik diperiksa dan diubah dalam kedua-dua arah. 1 Burp Repeater pula membolehkan mesej HTTP atau WebSocket diubah dan dihantar berulang kali. 2
Panduan ini membantu anda mengenal pasti request daripada satu tindakan pengguna. Kemudian, anda akan lihat bagaimana response berubah apabila satu input yang dibenarkan ditukar. Anda akan belajar merekod baseline, membuat perbandingan yang boleh diulang dan menulis kesimpulan dengan batasan yang jelas. Latihan ini tidak mengesahkan bahawa aplikasi mempunyai vulnerability.
Prasyarat dan Skop
Gunakan aplikasi makmal milik sendiri atau persekitaran ujian dengan kebenaran bertulis. Sediakan akaun dan data sintetik. Pilih endpoint yang disahkan oleh pemiliknya sebagai bacaan sahaja, serta senaraikan hostname dan laluan yang dibenarkan. PortSwigger mengingatkan bahawa Proxy boleh memberi kesan yang tidak dijangka. Vendor menasihatkan pengguna menggunakan sistem bukan produksi semasa belajar menggunakan fungsinya. 1
Untuk latihan ini, kami cadangkan anda tetapkan had request, tempoh latihan dan keadaan yang mewajibkan ujian dihentikan bersama pemilik makmal. Elakkan fungsi pembayaran, pemadaman, penghantaran e-mel dan perubahan akaun. Jangan gunakan sesi browser kerja atau data pelanggan. Nama endpoint dalam contoh di bawah hanyalah ilustrasi. Ia bukan arahan untuk mencari endpoint itu pada laman pihak lain.
Panduan ini mengandaikan Burp Suite sudah tersedia. Anda tidak perlu mengubah firewall, memasang CA pada sistem operasi atau mengubah konfigurasi Linux. Penulis belum menjalankan mana-mana contoh dalam makmal sebenar. Semua jangkaan hasil di sini juga belum diuji.
Kaedah dan Penjelasan
1. Tangkap satu perjalanan pengguna
Dalam Burp, buka Proxy → Intercept → Open Browser. Trafik browser terbina dalam ini melalui Burp secara automatik. 1 Buka hanya aplikasi makmal yang dibenarkan. Lakukan satu tindakan mudah, seperti menukar bahasa paparan katalog latihan.
Semak Proxy → HTTP history. History terus dikemas kini walaupun Intercept dimatikan. Pilih satu entri untuk melihat pasangan request dan response. 3 Untuk pemerhatian awal, gunakan Intercept off supaya navigasi tidak perlu menunggu keputusan manual. Catat tindakan yang dibuat sebelum beralih ke entri lain.
HTTP history memaparkan hostname, method, URL, masa, status code, panjang response dan MIME type. 3 Padankan maklumat ini dengan tindakan tadi, kemudian baca mesej penuh. Untuk latihan ini, pilih satu request yang tujuan dan kesannya boleh diterangkan oleh pemilik makmal.

2. Bina baseline sebelum mengubah input
Semasa memetakan aplikasi, OWASP WSTG mengesyorkan anda semak parameter pada URL, header dan body. Catat juga method dan konteks authentication. 4 Sediakan helaian kerja ringkas yang merekodkan tujuan halaman, input yang hendak diperiksa, keadaan sesi ujian dan response asal. Jangan salin nilai sesi ke dalam laporan umum.
Klik kanan request dan pilih Send to Repeater. Kemudian, buka tab Repeater yang terhasil. Repeater memaparkan sasaran serta editor request dan response. 5 Semak sasaran sebelum menekan Send. Hantar request asal yang telah disahkan selamat dahulu. Catat baseline sebelum mengubah apa-apa.
Kami cadangkan anda ulang baseline sekali untuk melihat sama ada hasilnya stabil. Jika dua request asal sudah menghasilkan kandungan yang berbeza, semak sebabnya bersama pemilik makmal. Selesaikan semakan ini sebelum membandingkan input. Jangan abaikan perbezaan itu semata-mata untuk mendapatkan keputusan yang kelihatan kemas.
3. Ubah satu perkara dengan tujuan jelas
Sebagai ilustrasi, gunakan request katalog latihan dengan laluan /catalog?lang=ms. Andaikan pemilik makmal mengesahkan bahawa parameter lang menerima ms dan en. Kedua-dua nilai ini hanya menukar bahasa paparan. Tukar nilai bahasa sahaja kepada en. Kekalkan sasaran, method dan input lain. Sebelum menghantar variasi itu, catat perubahan yang anda jangkakan.
Dalam Repeater, ubah mesej dan tekan Send untuk melihat response baharu. Ini mengikut aliran kerja rasmi vendor. 5 Latihan ini tidak memerlukan payload eksploitasi. Jangan meneka parameter tambahan atau meluaskan scope jika hasilnya tidak seperti yang dijangka.
Dalam contoh ilustrasi ini, teks paparan dijangka bertukar bahasa mengikut spesifikasi makmal. Hasil itu belum membuktikan bahawa input validation selamat untuk semua nilai. Jika response tidak berubah, rekod pemerhatian itu dahulu. Semak spesifikasi dan prasyarat ujian sebelum membuat kesimpulan bahawa parameter diabaikan.

Pengesahan Hasil
Bandingkan tiga rekod: baseline asal, request dengan satu perubahan dan baseline yang dihantar semula. Susunan ini ialah kaedah latihan yang dicadangkan, bukan ciri automatik Burp. Tandakan medan input yang berubah dan petikan response yang menyokong pemerhatian. Semak status, header dan kandungan sebenar. Jangan lihat saiz sahaja.
OWASP turut menyarankan anda semak cookie baharu dan redirect dalam response. 4 Hentikan perbandingan jika pengguna dibawa ke halaman lain atau keadaan sesi berubah. Semak sama ada prasyarat asal masih dipenuhi. Bezakan perkara yang anda lihat daripada sebab yang belum disahkan.
Repeater menyimpan perubahan mesej dalam sejarah tab dan menyediakan nota untuk request HTTP. 2 Gunakan nota untuk merekod objektif, satu perubahan yang dibuat dan keputusan sementara. Kami cadangkan ID tempatan seperti B1 untuk baseline dan V1 untuk variasi. Dengan cara ini, penyemak boleh mengikuti urutan bukti tanpa bergantung pada ingatan penguji.
Untuk latihan bahasa tadi, anda boleh membuat kesimpulan bahawa perubahan nilai bahasa menghasilkan paparan berbeza dalam keadaan ujian tersebut, jika hasil itu benar-benar diperhatikan. Untuk melabelkannya sebagai vulnerability, anda perlukan bukti bahawa tingkah laku aplikasi bercanggah dengan kawalan keselamatan yang sepatutnya. Catatan “perlu pengesahan lanjut” lebih berguna daripada finding yang tiada asas.

Batasan dan Pemulihan
Latihan satu request tidak meliputi keseluruhan aplikasi. Ia juga tidak menilai semua peranan pengguna, semua nilai input atau proses yang mempunyai beberapa langkah. Hadkan kesimpulan kepada endpoint, keadaan sesi dan variasi yang benar-benar diperiksa. Nyatakan jika ujian tidak dapat diulang atau response asal tidak stabil.
Untuk mengendalikan bukti, kami cadangkan anda simpan bahan mentah hanya di tempat simpanan ujian yang diluluskan dan hadkan aksesnya. Sediakan salinan laporan berasingan. Padamkan nilai Cookie, Authorization, token, alamat e-mel dan maklumat pengenalan peribadi daripada salinan itu. Semak screenshot dan nota secara manual sebelum berkongsi. Kekalkan nama medan yang diperlukan untuk memahami ujian, tetapi buang nilainya yang sensitif.
Selepas latihan, tutup browser makmal dan tamatkan sesi ujian. Pulihkan data sintetik jika ada perubahan yang tidak sengaja. Jika anda menggunakan browser luaran di luar panduan ini, pulihkan tetapan proxy yang diubah mengikut rekod asal. Laporkan sebarang kesan di luar scope kepada pemilik makmal sebelum meneruskan ujian.
Apa Yang Security Team Malaysia Perlu Buat
Jalankan latihan ini secara berpasangan antara penguji dengan pembangun. Seorang menerangkan hasil aplikasi yang dijangka. Seorang lagi menunjukkan bukti request dan response. Templat laporan yang dicadangkan merangkumi objektif, scope, masa bersama zon waktu, prasyarat, perubahan, pemerhatian, batasan dan tindakan susulan.
Jika pasukan berkongsi makmal, tentukan bersama siapa pemilik data ujian dan berapa lama bukti akan disimpan. Minta penyemak mengulang langkah dengan data sintetik sebelum merekodkan pemerhatian sebagai finding rasmi. Secara praktikal, latihan boleh dianggap selesai apabila pasangan request/response boleh dijejaki, perubahan boleh diterangkan dan laporan tidak mendedahkan rahsia. Ini cadangan operasi daripada pihak editorial, bukan dakwaan tentang insiden atau kewajipan undang-undang di Malaysia.
References
1. PortSwigger — Burp Proxy. 2. PortSwigger — Burp Repeater. 3. PortSwigger — HTTP history. 4. OWASP WSTG v4.2 — Identify Application Entry Points, WSTG-INFO-06. 5. PortSwigger — Working with HTTP messages in Burp Repeater.
Semua dokumentasi dirujuk pada 29 September 2026. Tarikh semakan dokumentasi bukan tarikh vulnerability ditemukan.