Di banyak tempat yang menerapkan paradigma, seperti Agile, DevOps, atau Lean, shipping code (men-deploy kode) bagaikan detak jantung bagi perusahaan. Aktivitas ini dianggap krusial untuk meningkatkan peluang sukses sebuah perusahaan.

Ini karena fitur yang dibangun oleh para developer, baru dapat dirasakan oleh pengguna ketika kodenya sudah di-ship (atau di-deploy).  Ini adalah momen penting untuk mengetahui tingkat keberhasilan dan manfaat dari fitur yang dibangun.

Selayaknya detak jantung, proses shipping ini penting untuk dilakukan sesering mungkin dan semudah mungkin. Seringkali fitur akan mengalami perubahan dan pengembangan setelah ia pertama kali diluncurkan. Ini adalah hal yang wajar. Proses shipping akan membuka arus timbal balik dengan para pengguna.

Oleh karena itu, dalam perspektif DevOps, aktivitas memberi manfaat dan dampak ke pengguna ini perlu berjalan semulus mungkin. Alhasil, banyak aktivitas pengembangan yang dilakukan sedini mungkin. Contohnya adalah aktivitas testing menggunakan pendekatan Test Driven Development agar keakuratan dari software yang dikembangakan dapat teruji sedini mungkin.

Salah satu hal yang sangat penting dalam alur pengembangan software adalah sisi keamanan aplikasi. Agar aktivitas membangun dan menjaga keamanan dari sistem mendukung detak jantung perusahaan, ia perlu menjadi bagian integral dari aktivitas membangun software. Keamanan aplikasi perlu dilakukan sedini dan sesering mungkin. Bagaimana caranya? Salah satu caranya adalah para developer terlibat dan menjadi aktor utama dalam security.

Tingkatkan Keamanan Aplikasi Dengan Menggabungkan TDD & Continuous Threat modeling

Di kelas Menjadi Front-End Web Developer Expert, dijelaskan bagaimana developer menggunakan positive flow dan negative flow untuk menerapkan Test Driven Development (TDD). Positive flow menjabarkan bagaimana alur kerja normal dari sebuah fitur. Sementara itu, negative flow menjabarkan kekeliruan yang bisa terjadi di flow ini sehingga kekeliruan ini harus bisa ditangani dan diuji secara otomatis.

Kita bisa mengembangkan lagi model di atas untuk mendukung keamanan dari sistem, yaitu dengan memperkenalkan abuse case. Abuse case ini menjelaskan bagaimana sebuah fitur atau alur kerja dapat dieksploitasi oleh pihak-pihak tertentu. Biasanya, ia digunakan untuk mengakali logika yang sudah dipasang oleh developer. Celah-celah ini bisa berpotensi menjadi celah keamanan.

Sebagai contoh, marilah kita ambil skenario mengubah password milik pengguna. Anggaplah kita sudah membuat positive dan negative flow seperti contoh di bawah ini:

1. Pengguna memasukkan password lamanya.
2. Pengguna mengetikkan password barunya.
3. Pengguna memastikan password benar dengan mengetikkannya kembali.
4. Sistem memastikan password lamanya benar.
   • Password lama tidak sesuai -> proses gagal. Kabari pengguna bahwa password lamanya keliru.
5. Sistem memvalidasi password baru.
   • Password kurang dari 10 karakter -> proses gagal. Kabari pengguna untuk memasukkan password yang lebih panjang.
   • Password baru dan password konfirmasi tidak sama -> proses gagal. Kabari pengguna untuk memastikan password baru dan password konfirmasi sama.
6. Sistem memperbarui password pengguna.

Bagaimana flow di atas dapat diakali (di-abuse) ?

Bagaimana bila di langkah 6, seorang pengguna bisa mengakali sistem untuk memperbarui password di akun lain? Akun yang tak semestinya ter-update? Bagaimana hal ini bisa terjadi?

Kita misalkan sebuah sistem memiliki API PUT /users/{id} untuk memperbarui password seorang pengguna. Apa yang terjadi bila seorang pengguna bermain-main dengan nilai {id} di atas? Misalnya seorang pengguna memiliki id 406. Kemudian ia mencoba API berikut:

• PUT /users/205
• PUT /users/0
• PUT /users/1
• dan seterusnya.

Pengguna di atas sedang berusaha mengakali (abuse) logika yang telah dibuat oleh developer. Bila pengakalan tersebut berhasil, ia bisa mengambil alih akun milik user lain, bahkan akun milik admin.

Berkaca dari potensi di atas, maka developernya dapat melengkapi flow yang sudah dibuat sebagai berikut:

1. Pengguna memasukkan password lamanya.
2. Pengguna mengetikkan password barunya.
3. Pengguna memastikan password benar dengan mengetikkannya kembali.
4. Sistem memastikan password lamanya benar.
   • Password lama tidak sesuai -> proses gagal. Kabari pengguna bahwa password lamanya keliru.
5. Sistem memvalidasi password baru.
   • Password kurang dari 10 karakter -> proses gagal. Kabari pengguna untuk memasukkan password yang lebih panjang.
   • Password baru dan password konfirmasi tidak sama -> proses gagal. Kabari pengguna untuk memastikan password baru dan password konfirmasi sama.
6. Sistem memperbarui password pengguna.
   • Memperbarui akun yang berbeda -> gagal.

Nah, karena abuse case 6.1 ada pada flow di atas, developer akan memasukkan alur tersebut ke dalam tesnya. Ini adalah contoh shift left untuk aspek security. Aktivitas mengamankan sistem dilakukan sedini mungkin, jauh sebelum software diluncurkan ke pengguna.

Yang jadi pertanyaan, bagaimana developer bisa tahu abuse case yang mungkin terjadi di fitur yang ia sedang kembangkan?

Bangun Abuse Case Menggunakan Continuous Threat Modeling ala Autodesk

Pada artikel sebelumnya, kami sempat menyinggung mengenai white box security testing menggunakan Continuous Threat modeling. Kamu bisa membaca artikel tersebut untuk memahami dasar dari model ini.

Developer bisa terbantukan dalam membangun abuse case dengan memanfaatkan checklist yang disediakan oleh autodesk ataupun yang dibangun bersama di perusahaan masing-masing.

Kita ambil contoh flow memperbarui password milik user sebelumnya. Di checklist yang telah kami cantumkan sebelumnya, ada beberapa security checklist yang bisa kita gunakan:

• Menambahkan fungsi untuk mengubah data sensitif di sistem (If you added functionality that changes sensitive properties or objects in the system).
• Membuat proses atau aktor baru (If you created a new process or actor).
• Menerima input yang tidak bisa kamu kontrol dari sumber yang diragukan (If you received uncontrolled input from an untrusted source).

Dari tiga skenario di atas, ada beberapa checklist yang dapat kita gunakan untuk melengkapi flow yang telah kita buat:

1. Lindungi dengan authorization. Ini contoh 6.1 pada flow sebelumnya.
2. Pastikan secrets tidak disimpan secara plaintext.
3. Verifikasi dan batasi ukuran dari input. Kita bisa membatasi maksimal karakter yang dimasukan user sebanyak 60 karakter.
4. Pertimbangkan bagaimana inputan ini digunakan di sistem. Ini berhubungan dengan nomor 2 di atas. Password akan disimpan di database. Agar password tidak disimpan secara plaintext, kita bisa menggunakan hashing sebelum passwordnya disimpan.

Nomor 1 dan 3 dapat kita masukan ke unit test dalam proses TDD. Sementara itu, nomor 2 dan 4 dapat kita tambahkan ke integration test. Dengan memasukkan aspek security ke rutinitas utama developer seperti ini, maka developer akan menjadi lebih sadar akan perannya dalam membangun keamanan aplikasi.

Tingkatkan Keamanan Aplikasi Dengan STRIDE

Alat lain yang dapat membantu kita membangun abuse case adalah dengan menjawab What Could Go Wrong atau masalah apa yang bisa terjadi? Dan untuk menjawab pertanyaan ini, STRIDE menawarkan kategori penyerangan yang dapat dieksplorasi oleh developer:

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

Bila kamu belum menyadarinya, STRIDE adalah kependekan dari kategori serangan di atas. Ketika membaca kategori di atas, kita bisa jadi sangat kebingungan. Apa itu spoofing? Apa itu repudiation?

Di sinilah serunya STRIDE. Model ini dikembangkan dengan model permainan kartu yang diberi nama Elevation of Privilege. Permainan ini melibatkan pihak-pihak yang memiliki pengetahuan mengenai sistem dan fitur yang dibangun. Pihak yang diundang dalam permainan ini bukan hanya tim security, melainkan tim lain juga sangat penting untuk terlibat.

Permainan ini memiliki aturan yang sederhana. Kamu dapat melihat penjelasan dan contohnya di video ini. Untuk memperoleh kartunya, kamu dapat mengunduhnya di sini.

Dari video di atas, kamu dapat melihat bagaimana permainan ini membantu developer untuk mengeksplorasi bagaimana sistemnya atau fiturnya dapat diakali oleh peretas.

Sebagai contoh, melanjutkan flow update password sebelumnya, di kategori Tampering ada model serangan seperti ini.

Model serangan ini sama dengan model serangan yang sudah kita catat sebelumnya (di flow 6.1).

Berikut adalah contoh serangan lainnya yang berhubungan dengan flow update password.

Mempelajari kartu di atas, developer bisa menyadari bahwa dia harus memasang log untuk mencatat siapa yang melakukan aktivitas pembaruan password dan kapan hal tersebut dilakukan.

Masih banyak lagi model serangan yang dapat dipelajari oleh developer dengan memainkan kartu-kartu yang ada di STRIDE. Hal ini dapat membantu developer dalam mengembangkan abuse case.

Developer Sadar Security

Dengan terlibatnya developer dalam aktivitas security, maka keamanan menjadi bagian penting dalam alur pembangunan aplikasi. Keamanan tidak menjadi aktivitas akhir ataupun aktivitas yang terlupakan.

Tidak bisa dipungkiri bahwa aspek keamanan bukanlah hal yang mudah dipahami bagi banyak developer. Itulah mengapa kita perlu mengeksplorasi cara-cara untuk memudahkan developer menjaga keamanan dari sistemnya tanpa harus menunggu orang lain melakukannya.

Dua model yang disampaikan di artikel ini hanyalah beberapa contoh pendekatan yang bisa dicoba untuk membantu developer membangun sistem yang aman. Ada banyak lagi model lainnya (threat modeling) yang dapat dipelajari.

Apa pun modelnya, salah satu tujuan utamanya adalah bagaimana shipping code yang merupakan detak jantung bagi perusahaan dapat menjadi aktivitas yang lebih aman dan memberikan kode yang aman juga untuk perusahaan dan penggunanya.