siapa yang tidak tahu cara memakai teknologi jaman sekarang, ibu, anak dan saudara kalian bahkan sudah mengerti akan adanya teknologi yang digunakan sehari-hari.
Baca Juga : Cookie Tracking and Stealing using Cross-Site Scriptingtapi kali ini saya tidak akan membahas tentang tutorial hacking ataupun berita seputar teknologi, saya akan membagikan cara melaporkan bug vulnerability yang benar sesuai Etical Hacking Indonesia
Keterampilan penting bagi seorang peneliti keamanan adalah kemampuan untuk menulis laporan kerentanan yang singkat dan jelas. Laporan kerentanan yang ditulis dengan baik akan membantu tim keamanan mereproduksi dan memperbaiki masalah lebih cepat dan meminimalkan kemungkinan eksploitasi. Dalam posting ini, kita akan masuk ke komponen laporan kerentanan yang baik dan beberapa tips dan trik yang telah saya pelajari di sepanjang jalan.
1. Cara Penulisan yang baik; Membuat Judul dan Ringkasan Deskriptif
Bagian pertama dari laporan kerentanan yang bagus akan selalu berupa judul deskriptif dan ringkasan yang jelas.
Apa kerentanan yang Anda temukan? Apakah ini sesuai dengan 10 OWASP teratas? Di mana itu ditemukan pada target? Idealnya, judul laporan harus deskriptif sampai-sampai memungkinkan tim keamanan yang bekerja bersama Anda untuk segera mendapatkan gagasan tentang apa yang Anda laporkan dan potensi kritikannya. Misalnya, alih-alih mengatakan
Report Title:
IDOR on a critical endpoint
IDOR on a critical endpoint
judul laporan anda seharusnya :
Report Title:
IDOR on "https://example.com/change_password" leads to account takeover for all users
IDOR on "https://example.com/change_password" leads to account takeover for all users
Dalam dua detik pertama membaca laporan Anda, insinyur keamanan sudah memiliki ide bagus tentang apa yang akan terjadi di sisa laporan. Dan di bagian ringkasan berikutnya, sertakan detail tambahan yang tidak dapat Anda sertakan dalam judul, seperti parameter pos yang digunakan untuk serangan, bagaimana Anda menemukannya, dan sebagainya.
Report Summary:The "https://example.com/change_password" endpoint takes two POST body parameters: "user_id" and "new_password". A POST request to this endpoint would change the password of user "user_id" to "new_password". This endpoint is not validating the "user_id" parameter and as a result, any user can change anyone else's password by manipulating the "user_id" parameter.
2. Sertakan Penilaian Tingkat Permasalahan.
Seringkali bermanfaat untuk memasukkan penilaian yang jujur tentang keparahan masalah dalam laporan Anda. Selain bekerja dengan Anda untuk memperbaiki kerentanan, tim keamanan memiliki tanggung jawab lain untuk cenderung juga. Memasukkan penilaian keparahan yang jujur akan membantu mereka memprioritaskan kerentanan mana yang harus diperbaiki terlebih dahulu, dan memastikan bahwa kerentanan kritis segera diatasi.
Pelajari skala CVSS untuk gagasan umum tentang seberapa kritis setiap jenis kerentanan. Kemudian, cari tahu apa yang dipedulikan perusahaan klien Anda dan kerentanan mana yang akan menghadirkan dampak bisnis terbesar. Selalu sesuaikan penilaian Anda agar sesuai dengan prioritas bisnis klien. Misalnya, beberapa perusahaan mungkin menganggap kebocoran tanggal lahir pengguna sebagai masalah besar dan yang lain mungkin tidak. Sementara kebocoran informasi kartu kredit pengguna hampir selalu dianggap sebagai masalah mendesak.
Berikan penilaian keparahan yang akurat dalam laporan Anda berdasarkan jenis kerentanan dan dampak bisnis. Ini akan membantu membuat hidup semua orang lebih mudah dan berkontribusi pada hubungan positif antara Anda dan tim keamanan.
Tingkat keparahan masalah: Tinggi
3. Berikan Langkah-Langkah Yang Jelas untuk Diproduksi
Berikan petunjuk langkah-demi-langkah tentang cara mereproduksi kerentanan dan sertakan semua detail relevan yang dapat Anda pikirkan. Yang terbaik untuk mengasumsikan bahwa insinyur di sisi lain laporan tidak memiliki pengetahuan tentang kerentanan dan tidak tahu cara kerja aplikasi secara detail. Misalnya, ini adalah bagian "langkah untuk mereproduksi" dari laporan oke :
Langkah-langkah untuk mereproduksi: Masuk ke situs dan kunjungi "https://example.com/change_password". Klik pada tombol "Ubah kata sandi". Mencegat permintaan, dan ubah parameter "user_id" ke ID pengguna lain.
Dan ini adalah bagian "langkah untuk mereproduksi" dari laporan yang baik :
Langkah-langkah untuk mereproduksi:
Buat dua akun di "example.com", pengguna A dan pengguna B. Masuk ke "example.com" sebagai akun A dan kunjungi "https://example.com/change_password".
Isi kata sandi baru yang diinginkan di bidang "kata sandi baru" yang terletak di kiri atas halaman. Klik pada tombol "Ubah kata sandi" yang terletak di kanan atas halaman.
Mencegat permintaan POST ke "https://example.com/change_password" dan ubah parameter POST user_id ke ID pengguna akun B.
Anda sekarang dapat masuk ke akun B menggunakan kata sandi baru yang telah Anda pilih.
Meskipun laporan pertama mungkin masih akan dipahami oleh tim keamanan, laporan kedua jauh lebih spesifik. Ini menghindari ambiguitas dan kesalahpahaman dan mempercepat proses mitigasi kerentanan.
4. Berikan Proof Of Concept
Untuk kerentanan sederhana, langkah-langkah untuk mereproduksi yang telah Anda berikan sering juga berfungsi sebagai PoC. Tetapi untuk kerentanan yang sifatnya lebih kompleks, ada baiknya menyertakan "bukti" video atau foto kerentanan tersebut. Anda juga dapat menyertakan URL, skrip, atau unggah file apa pun yang telah Anda gunakan saat memvalidasi kerentanan.
Misalnya, untuk kerentanan CSRF, sertakan file HTML dengan muatan CSRF, dan untuk XXE, sertakan file XML buatan yang Anda gunakan selama serangan. Skrip PoC seperti ini menghemat waktu tim keamanan karena mereka tidak perlu menyiapkan muatan serangan sendiri.
5. Jelaskan Skenario Dampak dan Serangan
Memberikan Masukkan cara yang masuk akal tentang bagaimana kerentanan dapat dieksploitasi. Pikirkan tentang bagaimana penyerang jahat akan melakukan dengan kerentanan yang Anda temukan.
Cobalah untuk meningkatkan dampak kerentanan sebanyak mungkin dan berikan perusahaan klien perasaan realistis tentang bagaimana bug dapat dieksploitasi jika ditemukan oleh penyerang jahat.
Ini akan membantu perusahaan memprioritaskan perbaikan secara internal dan menentukan apakah langkah-langkah tambahan dan penyelidikan internal diperlukan.
6. Rekomendasikan Mitigasi yang Mungkin
Jika Anda bisa, rekomendasikan kemungkinan mitigasi dalam laporan Anda. Ini akan menghemat waktu tim yang digunakan untuk meneliti mitigasi untuk kerentanan itu. Anda hanya harus melakukan ini jika Anda memiliki ide bagus tentang akar penyebab masalah. Seringkali, Anda sebagai peneliti keamanan yang menemukan kerentanan akan menjadi yang paling akrab dengan perilaku fitur aplikasi tertentu dan dengan demikian akan berada dalam posisi terbaik untuk menghasilkan perbaikan yang komprensif.
Jangan Menganggap Apa Pun
Jangan berasumsi bahwa tim keamanan akan dapat memahami segalanya dalam laporan Anda. Ingat, Anda mungkin telah menatap titik akhir ini selama seminggu, tetapi bagi para insinyur yang berkomunikasi dengan Anda, ini semua informasi baru.
Mereka memiliki sejumlah besar tanggung jawab lain di atas piring mereka dan seringkali tidak terbiasa dengan fitur seperti Anda. Bantu mereka memahami apa yang Anda temukan.
Jadilah sebisa mungkin dan sertakan semua detail yang dapat Anda pikirkan, bahkan yang menurut Anda tidak perlu. Pikirkan tentang konsekuensi potensial dari penggunaan kata-kata yang tidak perlu versus konsekuensi dari meninggalkan detail penting: hal terburuk yang dapat terjadi jika Anda terlalu bertele-tele adalah bahwa laporan Anda akan membutuhkan dua menit ekstra untuk dibaca.
Tetapi jika Anda meninggalkan detail penting, perbaikan kerentanan mungkin tertunda, dan bug mungkin dieksploitasi oleh penyerang jahat!
Ingat: Tim Developer Juga Manusia
Jadikan laporan Anda semudah mungkin dibaca. Tulis dengan nada percakapan dan sertakan tautan ke referensi untuk pengetahuan keamanan yang tidak jelas.
Jangan gunakan 1337 5p34k, slang, atau singkatan, karena ini membuat teks lebih sulit dibaca dan akan menambah gangguan pembaca Anda.
Berkomunikasi dengan insinyur keamanan dengan hormat dan profesionalisme. Berikan tindak lanjut dan klarifikasi dengan sabar dan segera.
Dan ingat, kita semua membuat kesalahan. Jika orang yang menangani laporan Anda membuat kesalahan atau salah menangani masalah, komunikasikan dan jelaskan proses pemikiran Anda, dan uraikan rincian teknis kerentanan tersebut.
Jika itu masih tidak menyelesaikan masalah, eskalasi masalah melalui platform bug atau insinyur keamanan lainnya di tim. Dan jika Anda adalah orang yang melakukan kesalahan selama proses, komunikasikan itu kepada tim keamanan sesegera mungkin dengan semua perincian yang relevan.
Masalah miskomunikasi pasti akan terjadi, tetapi ingat bahwa sebagai peneliti keamanan, Anda memiliki kekuatan untuk meminimalkan kemungkinan itu dengan memberikan laporan kerentanan yang jelas dan komprehensif.
Dengan mengasah keterampilan komunikasi Anda selain keterampilan meretas, Anda akan menghemat waktu semua orang dan memaksimalkan nilai Anda sebagai peretas!
Sumber Refrensi : https://medium.com/swlh/how-to-write-a-better-vulnerability-report-20163ab913fb