Security Testing ala White Box dan Black Box

Seperti halnya pengujian kode yang memiliki pendekatan white box dan black box, security testing juga memiliki pendekatan white box dan black box. Pendekatan white box mengasumsikan si penguji memiliki akses terhadap kode yang diuji sehingga ia dapat melakukan analisis terhadap kode tersebut. Sementara itu, pendekatan black box menguji sistem dari luar, tanpa perlu mengetahui kode dari sistem yang diuji.

Kedua pendekatan di atas memiliki keseruan dan tantangannya masing-masing. Keseruan ini ditujukan bukan hanya bagi para bug hunter, hacker, dan teman-temannya. Keseruan ini tentunya dapat dirasakan oleh developer juga.

White box Security Testing

Di model testing ini, kamu memiliki akses ke kode dari sistem yang diuji. Ada beberapa cara untuk melakukan white box security testing. Sebagai contoh, kamu dapat melakukan static code analysis, di mana kamu menggunakan sebuah alat untuk menganalisis kode dan memberitahukan kerentanan yang dapat dideteksi olehnya. Contoh alat yang dapat dipakai adalah semgrep.

💻 Mulai Belajar Pemrograman

Belajar pemrograman di Dicoding Academy dan mulai perjalanan Anda sebagai developer profesional.

Daftar Sekarang

Pada kesempatan ini, mari kita berkenalan dengan pendekatan white box testing yang terinspirasi oleh Autodesk Continuous Threat Modeling.

Threat modeling adalah aktivitas menganalisis ancaman terhadap sebuah sistem. Dari hasil analisa ini, kita dapat memasang pengaman untuk meminimalisir peluang dan dampak dari ancaman tersebut.

Yang menarik dari threat modeling ala Autodesk ini adalah ia dapat dilakukan secara terus menerus oleh developer, bukan hanya security tester.

Karena analisis dapat dilakukan oleh developer, aktivitas menjaga keamanan dari sebuah sistem tidak harus ditaruh di tahap akhir dari proses pengembangan software. Aktivitas ini dapat dikerjakan di awal. Ini salah satu cara untuk meningkatkan keamanan dari sistem yang dibangun.

Dalam Autodesk Continuous Threat Modeling, analisis security dilakukan berdasarkan konteks perubahan yang dilakukan oleh developer. Sebagai contoh, bila developer sedang membangun fungsionalitas baru di mana sistem akan menerima inputan dari user, developer tersebut akan diberi beberapa panduan untuk menjaga agar fungsi baru ini dibangun dengan aman. Contohnya seperti

verifikasi dan batasi ukuran dari input yang diterima,
validasi input
bersihkan (sanitize) output,
dan sebagainya.

Kamu dapat mempelajari beragam checklist dari Autodesk pada link ini.

Contoh Continuous Threat Modeling di Dicoding

Dicoding mengadopsi pendekatan ini dalam aktivitas pengembangan aplikasi yang dilakukan. Security checklist yang dibangun disesuaikan dengan architecture, komponen, dan flow yang terjadi di sistem Dicoding. Ini karena beragam komponen memiliki perannya masing-masing. Sebagai contoh, untuk menjaga agar konten dari user ditampilkan secara aman, maka proses pembersihan data dilakukan di komponen view saja dan tidak perlu dilakukan di komponen lain.

Model continuous threat modeling ini bila menjadi bagian inti dari pengembangan aplikasi akan dapat membantu aktivitas testing otomatis dan security review yang dilakukan.

Untuk aktivitas testing otomatis, kita ambil contoh ketika aplikasi menerima input dari user. Karena semua input harus dicurigai, aplikasi perlu melakukan proses validasi. Untuk memastikan bahwa proses validasi ini diterapkan dengan benar dan agar tidak terhapus dengan tidak sengaja, maka developer dapat membuat unit test-nya. Ini akan meringankan beban developer dari harus menguji pengamanan tersebut secara manual.

Aktivitas code review juga dibantu dengan adanya checklist ala continuous threat model ini. Karena security checklist dibangun seputar konteks perubahan, maka aktivitas code review menjadi lebih mudah. Ketika memeriksa perubahan yang terjadi (dengan membaca diff-nya), maka code reviewer bisa fokus pada kemungkinan attack di konteks perubahan tersebut.

Misalnya ketika perubahan terjadi di kode yang mengakses database, code reviewer bisa memeriksa kemungkinan SQL Injection. Reviewer tidak perlu fokus mencari SQL Injection ketika mereview komponen yang tidak berurusan dengan database. Contoh lain, bila mereview perubahan yang terjadi di berkas Javascript ataupun server side template, reviewer bisa memeriksa kemungkinan XSS.

Perlu diingat bahwa aktivitas code review juga menjadi bagian dari security testing. Ketika code reviewer menemukan kode yang dianggap rentan, ia dapat melakukan testing secara spesifik pada perubahan tersebut. Hal ini memungkinan proses testing yang terfokus. Karena cakupan dari security tesnya lebih kecil, testing dapat dilakukan sesering mungkin.

Black box Security Testing

Aktivitas testing ala black box ini tidak kalah serunya dengan pendekatan white box di atas. kamu mencari celah keamanan tanpa harus mengetahui kode dari aplikasi. Ini berarti kamu perlu memahami cara kerja aplikasi dan mengenali komunikasi yang terjadi di dalamnya

Misalnya ketika menelaah aplikasi web, kamu bisa

mencatat alur kerjanya,
mengamati komunikasi network dari browser ke server menggunakan proxy (misalnya zaproxy, mitmproxy, burp),
dan sebagainya.

Ada beberapa pendekatan populer yang dapat kamu pelajari bila ingin mendalami black box testing (terutama ketika menguji aplikasi web).

Sebagai contoh, untuk menguji apakah alur autentikasi sebuah web itu aman, kamu dapat mengujinya dengan cara berikut:

Login menggunakan user tertentu
Copy cookies-nya
Logout
Kemudian gunakan cookies yang diperoleh pada tahap 2 di atas untuk melakukan request baru pada halaman-halaman non public

Bila aplikasi rentan, kamu dapat membuka halaman non-public atas nama user pada tahapan 1 di atas. Pengujian ini dapat dilakukan tanpa harus membaca kode di mana proses autentikasi diterapkan.

Terus Kembangkan Kemampuan Menguji Keamanan Sistem

Bagi seorang developer, pemahaman yang baik akan security dapat meningkatkan peran dan dampak yang dapat dilahirkannya. Ia dapat meminimalisir celah keamanan dari kode yang dia tulis. Selain itu, ia juga dapat membantu developer lainnya untuk menggunakan API yang aman.

Developer yang paham security juga dapat membantu membangun kultur pengembangan yang lebih terintegrasikan dengan keamanan. Ini adalah hal yang sangat penting. Salah satu masalah dari penerapan security adalah ketika ia dilakukan di bagian terakhir dari pengembangan aplikasi. Pendekatan ini tidak terlalu efektif.

Jadi, bila kamu bertanya-tanya, “Hal apa yang bisa aku pelajari lebih lanjut?”, cobalah untuk memahami aspek security dari platform yang kamu gunakan.

Security bukanlah hal yang statis. Ia adalah bidang yang dinamis dan terus berkembang.

Kamu memiliki tips security testing lain? Atau ada masukan dan kritikan terhadap pendekatan di atas? Kami sangat senang bila kamu mau memberikan masukan untuk terus meningkatkan keamanan dari sebuah sistem.