Status passed dari tim Quality Assurance sering menjadi salah satu penanda penting sebelum aplikasi memasuki tahap produksi. Fitur telah diuji, alur utama berjalan, kesalahan yang ditemukan telah diperbaiki, dan aplikasi dianggap memenuhi requirement yang sebelumnya ditetapkan.

Dari perspektif kualitas perangkat lunak, kondisi tersebut tentu merupakan pencapaian penting.

Namun, ada satu kesimpulan yang sebaiknya tidak langsung diambil: aplikasi yang berhasil melewati QA belum otomatis dapat disebut aman.

Alasannya sederhana. Sebagian besar proses QA dirancang untuk memastikan aplikasi bekerja sebagaimana mestinya. Sementara itu, serangan siber justru berangkat dari pertanyaan yang berlawanan: apa yang dapat terjadi ketika aplikasi digunakan dengan cara yang tidak pernah direncanakan?

Perbedaan perspektif inilah yang membuat keamanan aplikasi membutuhkan pengujian tersendiri.

QA Menguji Fungsi, Penyerang Menguji Batas Sistem

Bayangkan sebuah aplikasi memiliki fitur untuk melihat informasi akun pengguna.

Dalam skenario normal, QA dapat menguji apakah pengguna berhasil login, apakah profil muncul dengan benar, apakah perubahan data dapat disimpan, dan apakah pengguna menerima pesan kesalahan ketika memasukkan data yang tidak valid.

Seluruh fungsi tersebut mungkin berjalan sempurna.

Namun, seorang penyerang tidak berhenti pada pertanyaan apakah halaman profil bekerja.

Ia dapat mencoba mengubah parameter pada request, mengganti identifier pengguna, memanggil API secara langsung, menggunakan token dengan hak akses berbeda, atau mencoba mengakses data tanpa melalui alur yang tersedia pada antarmuka aplikasi.

Di sinilah perbedaan antara software testing dan security testing menjadi penting.

Satu pihak memastikan bahwa sistem menghasilkan respons yang diharapkan. Pihak lainnya mencoba menemukan respons yang seharusnya tidak pernah diberikan oleh sistem.

Test Case Tidak Selalu Mewakili Cara Penyerang Berpikir

Proses QA umumnya dibangun berdasarkan requirement, user story, acceptance criteria, serta alur bisnis yang telah ditentukan.

Sebagai contoh, sebuah transaksi mungkin dirancang melalui tahapan:

login → memilih produk → memasukkan informasi → melakukan pembayaran → menerima konfirmasi.

Tim QA dapat memastikan setiap tahap bekerja dengan benar.

Masalahnya, penyerang tidak berkewajiban mengikuti perjalanan pengguna tersebut.

Ia mungkin langsung memanggil endpoint pembayaran. Ia dapat mengubah nilai transaksi sebelum request dikirimkan. Ia mungkin menggunakan kembali request yang sebelumnya valid. Ia juga dapat mencoba melewati tahapan tertentu untuk mengetahui apakah server tetap memproses permintaan tersebut.

Karena itu, antarmuka aplikasi tidak boleh dianggap sebagai batas keamanan.

Sistem perlu tetap mampu mempertahankan aturan authentication, authorization, validasi, dan business logic meskipun pengguna tidak mengikuti alur yang telah dirancang.

Aplikasi Dapat Berfungsi dengan Benar sekaligus Memiliki Celah Keamanan

Salah satu kesalahpahaman yang masih sering terjadi dalam pengembangan sistem adalah menyamakan aplikasi yang stabil dengan aplikasi yang aman.

Padahal keduanya mengukur hal yang berbeda.

Misalnya, sebuah sistem memiliki fitur perubahan alamat pengiriman. Secara fungsional, fitur tersebut bekerja dengan baik. Data alamat dapat diperbarui, tersimpan di database, kemudian digunakan ketika transaksi dilakukan.

Masalah keamanan baru terlihat apabila pengguna ternyata dapat memodifikasi parameter tertentu sehingga alamat milik akun lain ikut berubah.

Dari perspektif fungsi, proses penyimpanan tetap berhasil.

Namun dari perspektif keamanan, aplikasi telah gagal memastikan bahwa pengguna hanya dapat mengubah data yang menjadi haknya.

Kondisi serupa dapat terjadi pada banyak fungsi lain seperti reset password, pengelolaan akun, upload dokumen, transaksi, approval, pemberian diskon, hingga akses terhadap API.

Karena itu, tidak adanya bug fungsional tidak dapat digunakan sebagai bukti bahwa tidak terdapat vulnerability.

Penyerang Tidak Selalu Menyerang Satu Fitur

Risiko keamanan juga menjadi lebih kompleks karena serangan nyata tidak selalu bergantung pada satu kelemahan besar.

Dalam beberapa kasus, beberapa kelemahan kecil dapat digabungkan menjadi sebuah attack path.

Sebagai contoh, kesalahan konfigurasi dapat membuka informasi mengenai endpoint tertentu. Endpoint tersebut kemudian memiliki mekanisme authorization yang lemah. Setelah berhasil mengaksesnya, penyerang memperoleh informasi tambahan yang dapat digunakan untuk meningkatkan hak akses.

Jika setiap masalah dilihat secara terpisah, dampaknya mungkin tampak terbatas.

Ketika dihubungkan, konsekuensinya dapat berubah secara signifikan.

Inilah salah satu alasan penetration testing tidak cukup dilakukan seperti sebuah checklist sederhana. Pengujian perlu mempertimbangkan bagaimana sebuah kelemahan dapat digunakan untuk membuka peluang serangan berikutnya.

Kerentanan Business Logic Sering Tidak Terlihat dari Pengujian Normal

Bagian yang semakin penting dalam keamanan aplikasi modern adalah business logic vulnerability.

Business logic merupakan aturan yang menentukan bagaimana sebuah aplikasi seharusnya menjalankan proses bisnis.

Misalnya, sistem menetapkan bahwa voucher hanya dapat digunakan satu kali.

QA dapat menguji apakah voucher berhasil digunakan, apakah potongan harga sesuai, dan apakah transaksi selesai dengan benar.

Security testing akan membawa skenario tersebut lebih jauh.

Apakah request penggunaan voucher dapat dikirim berkali-kali?

Apa yang terjadi ketika dua request dikirim hampir bersamaan?

Apakah voucher masih dapat digunakan melalui endpoint yang berbeda?

Apakah status transaksi dapat dikembalikan sehingga voucher kembali aktif?

Pertanyaan-pertanyaan tersebut tidak selalu berkaitan dengan fungsi yang rusak. Sebaliknya, fitur dapat bekerja sangat baik, tetapi aturan bisnisnya dapat dimanipulasi.

OWASP bahkan menempatkan pengujian business logic sebagai area tersendiri dalam pengujian keamanan aplikasi, termasuk validasi data, pemalsuan request, pemeriksaan integritas proses, pembatasan penggunaan fungsi, hingga upaya melewati workflow.

Artinya, pengujian keamanan tidak cukup hanya mencari kesalahan teknis pada kode. Cara sebuah aplikasi menjalankan proses bisnis juga perlu menghadapi skenario penyalahgunaan.

Authorization Menjadi Salah Satu Batas yang Harus Benar-Benar Diuji

Banyak aplikasi bisnis saat ini memiliki beberapa role sekaligus.

Ada pengguna biasa, administrator, supervisor, operator, finance, vendor, atau role khusus lain dengan hak akses berbeda.

Pada sisi QA, pengujian dapat memastikan menu tertentu hanya muncul pada role yang tepat.

Namun keamanan tidak cukup dibuktikan dari tampilan menu.

Pertanyaan yang lebih penting adalah: apa yang terjadi apabila pengguna biasa mengirim request secara langsung ke endpoint administrator?

Apakah server benar-benar menolak permintaan tersebut?

Bagaimana ketika identifier transaksi milik pengguna lain dimasukkan?

Apakah sistem melakukan validasi authorization pada setiap request?

Masalah seperti ini penting karena kontrol pada sisi antarmuka hanya mengatur apa yang terlihat oleh pengguna. Keputusan keamanan yang sebenarnya harus tetap ditegakkan oleh sistem di sisi server.

API Membuat Batas Aplikasi Semakin Luas

Aplikasi modern juga semakin jarang bekerja secara mandiri.

Satu aplikasi dapat terhubung dengan payment gateway, layanan autentikasi, cloud storage, sistem internal perusahaan, marketplace, layanan pihak ketiga, maupun berbagai microservice melalui API.

Integrasi tersebut memberikan efisiensi, tetapi sekaligus memperbesar attack surface.

Sebuah fitur mungkin aman ketika digunakan melalui tampilan aplikasi. Namun endpoint di belakangnya dapat memiliki mekanisme validasi berbeda.

Penyerang juga tidak perlu mengakses aplikasi sebagaimana pengguna normal. API dapat dipanggil secara langsung menggunakan request yang dimodifikasi.

Inilah sebabnya pengujian terhadap aplikasi modern perlu melihat sistem secara lebih luas daripada sekadar halaman yang muncul di browser.

Authentication, authorization, konfigurasi, API, session management, hingga hubungan antar fitur perlu dipandang sebagai satu rangkaian.

Lingkungan Production Mengubah Tingkat Risiko

Aplikasi yang masuk production juga mulai menghadapi kondisi yang jauh lebih sulit dikendalikan.

Sistem dapat diakses dari internet, berinteraksi dengan berbagai perangkat, menerima request dalam jumlah besar, terhubung dengan layanan eksternal, serta digunakan oleh pengguna dengan pola perilaku yang beragam.

Di lingkungan tersebut, asumsi-asumsi yang sebelumnya terlihat aman dapat mulai diuji.

Endpoint yang tidak pernah digunakan oleh pengguna normal dapat ditemukan. Parameter yang dianggap tidak mungkin berubah dapat dimanipulasi. Kredensial dapat dicoba secara otomatis. API dapat dipanggil tanpa melalui UI.

Karena itu, keamanan tidak seharusnya diposisikan sebagai pemeriksaan tambahan setelah seluruh pengembangan selesai.

NIST melalui Secure Software Development Framework mendorong praktik keamanan untuk terintegrasi ke dalam software development lifecycle. Prinsip Secure by Design juga menempatkan keamanan sebagai bagian dari proses perancangan dan pengembangan sistem, bukan sekadar lapisan tambahan di tahap akhir.

Pendekatan tersebut semakin relevan ketika aplikasi menjadi bagian penting dari operasional perusahaan.

QA dan Security Testing Tidak Perlu Dipertentangkan

Mengatakan bahwa QA tidak cukup bukan berarti mengecilkan peran QA.

Sebaliknya, QA merupakan bagian yang sangat penting dalam pengembangan perangkat lunak.

Perbedaannya berada pada tujuan pengujian.

QA mencoba menjawab:

Apakah aplikasi bekerja sesuai requirement?

Sedangkan security testing mencoba menjawab:

Apakah aplikasi tetap aman ketika seseorang berusaha melanggar requirement tersebut?

Keduanya merupakan pertanyaan yang berbeda dan sama-sama penting.

Perusahaan tidak seharusnya memilih salah satu. Pendekatan yang lebih matang adalah menempatkan functional testing dan security testing sebagai dua lapisan validasi yang saling melengkapi.

Penetration Testing Membawa Perspektif Penyerang ke Dalam Pengujian

Di sinilah penetration testing memiliki peran penting.

Pengujian tidak hanya berusaha menemukan vulnerability, tetapi mencoba memahami bagaimana kelemahan tersebut dapat dimanfaatkan dalam kondisi yang menyerupai serangan.

Tester dapat mengevaluasi authentication, authorization, session, input, API, business logic, hingga kemungkinan beberapa kelemahan digunakan secara berantai.

Pendekatan seperti ini membantu perusahaan memahami bukan sekadar daftar celah, tetapi juga konsekuensi apabila kelemahan benar-benar dieksploitasi.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Dalam banyak kondisi, sistem telah melalui berbagai tahapan pengembangan dan pengujian fungsi. Namun ketika dilihat dari perspektif ofensif, masih terdapat skenario yang sebelumnya tidak masuk ke dalam test case normal.

Kondisi tersebut bukan sesuatu yang aneh.

Tim developer, QA, dan security memang melihat aplikasi dari perspektif yang berbeda. Justru perbedaan perspektif inilah yang perlu dimanfaatkan untuk meningkatkan kualitas dan keamanan sistem secara keseluruhan.

Pertanyaan Pentingnya Bukan Lagi Sekadar “Apakah QA Sudah Selesai?”

Sebelum aplikasi dipublikasikan, pertanyaan yang diajukan perusahaan sebaiknya tidak berhenti pada status QA.

Ada beberapa pertanyaan lain yang layak menjadi perhatian.

Apakah authorization antar-role benar-benar telah diuji?

Apakah endpoint API tetap aman jika dipanggil langsung?

Apakah business logic dapat dimanipulasi?

Apakah validasi hanya dilakukan pada sisi frontend?

Apakah terdapat kemungkinan melewati urutan proses yang telah dirancang?

Apakah beberapa kelemahan dapat digabungkan menjadi attack path?

Dan yang paling penting, apakah aplikasi pernah diuji oleh pihak yang memang berusaha membuat sistem melakukan sesuatu yang seharusnya tidak diperbolehkan?

Pertanyaan seperti ini memberikan gambaran keamanan yang lebih realistis dibanding sekadar memastikan seluruh fungsi telah mendapatkan tanda centang.

Aplikasi Baru Benar-Benar Diuji ketika Asumsinya Mulai Dilanggar

Keberhasilan melewati QA tetap menjadi indikator penting bahwa aplikasi telah memenuhi standar kualitas tertentu.

Namun keamanan membutuhkan pembuktian yang berbeda.

Sistem perlu diuji ketika pengguna tidak mengikuti workflow, ketika request dimodifikasi, ketika batas role dicoba dilewati, ketika API dipanggil secara langsung, dan ketika beberapa fungsi digunakan dengan cara yang tidak pernah direncanakan oleh tim pengembang.

Di titik itulah keamanan aplikasi mulai benar-benar diuji.

QA membuktikan bahwa aplikasi dapat digunakan sebagaimana dirancang.

Security testing membantu perusahaan memahami apakah aplikasi juga mampu bertahan ketika seseorang berusaha menyalahgunakannya.

Uji Keamanan Aplikasi Bersama Fourtrezz

Jika perusahaan Anda sedang mempersiapkan aplikasi untuk production, melakukan evaluasi keamanan sistem, atau ingin mengetahui risiko yang mungkin tidak terlihat selama proses QA, Fourtrezz dapat menjadi mitra untuk melakukan pengujian keamanan secara lebih terarah.

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk membantu perusahaan mengidentifikasi kerentanan pada aplikasi, API, maupun infrastruktur. Pendekatan pengujian dapat disesuaikan dengan kebutuhan dan ruang lingkup sistem perusahaan.

Kolaborasi ini dapat membantu tim mendapatkan perspektif tambahan terhadap keamanan aplikasi sekaligus memperoleh temuan dan rekomendasi yang dapat digunakan sebagai dasar perbaikan.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]