Studi Kasus Pentest: Mengungkap Celah Keamanan pada Aplikasi Perusahaan
Bayangkan sebuah perusahaan memiliki aplikasi yang digunakan oleh ribuan pelanggan setiap hari.
Aplikasi tersebut digunakan untuk:
- membuat akun;
- melihat data transaksi;
- melakukan pemesanan;
- mengakses informasi pelanggan;
- dan memantau status layanan.
Dari sisi bisnis, aplikasi berjalan dengan baik.
Tidak ada gangguan besar.
Server juga aktif.
Firewall telah dipasang.
Antivirus dan monitoring sudah tersedia.
Namun pertanyaannya:
Apakah aplikasi tersebut benar-benar aman?
Inilah pertanyaan yang coba dijawab melalui pentest atau penetration testing.
Pentest dapat membantu perusahaan melihat keamanan sistem dari perspektif attacker melalui pengujian yang terkontrol dan dilakukan berdasarkan izin serta scope yang telah disepakati.
Dalam artikel ini, kita akan melihat studi kasus pentest pada sebuah aplikasi perusahaan fiktif, mulai dari persiapan hingga remediation.
Tujuannya bukan untuk menunjukkan cara menyerang sistem secara detail, melainkan memahami bagaimana pentest membantu menemukan risiko yang mungkin tidak terlihat dalam pemeriksaan biasa.
Apa Itu Pentest?
Pentest atau penetration testing adalah proses pengujian keamanan terhadap sistem, aplikasi, jaringan, atau aset digital dengan menggunakan pendekatan simulasi serangan secara legal dan terkontrol.
Pentest dapat membantu perusahaan menjawab beberapa pertanyaan penting:
- Apakah aplikasi memiliki celah keamanan?
- Apakah vulnerability dapat dimanfaatkan?
- Seberapa besar dampaknya?
- Apakah kontrol keamanan berjalan sebagaimana mestinya?
- Apa yang harus diperbaiki?
- Apakah perbaikan sudah efektif?
Pentest berbeda dengan sekadar vulnerability scanning.
Jika vulnerability assessment membantu menemukan potensi vulnerability, pentest dapat melakukan validasi dan analisis yang lebih mendalam sesuai scope.
Studi Kasus: Pentest pada Aplikasi Customer Portal
Untuk memudahkan pembahasan, gunakan contoh perusahaan fiktif:
PT Digital Sejahtera
Perusahaan ini memiliki sebuah aplikasi bernama:
Customer Portal
Aplikasi digunakan oleh pelanggan untuk:
- login;
- melihat profil;
- melihat transaksi;
- mengunduh dokumen;
- mengajukan permintaan layanan;
- dan melihat informasi akun.
Aplikasi tersebut terhubung dengan beberapa komponen lain:
Customer Portal
↓
API
↓
Application Server
↓
Database
Karena aplikasi menangani data pelanggan, perusahaan memutuskan melakukan penetration testing.
Mengapa Perusahaan Melakukan Pentest?
Ada beberapa alasan.
1. Aplikasi Akan Mengalami Perubahan Besar
Perusahaan akan meluncurkan fitur baru.
2. Aplikasi Terhubung ke API
API menjadi bagian penting dari komunikasi antara aplikasi dan backend.
3. Aplikasi Memproses Data Pelanggan
Data pelanggan merupakan aset yang perlu dilindungi.
4. Perusahaan Ingin Melakukan Security Validation
Management ingin mendapatkan gambaran mengenai kondisi keamanan aplikasi dari perspektif pihak yang melakukan pengujian secara independen.
Tahap 1: Menentukan Scope
Sebelum pengujian dimulai, perusahaan menentukan scope.
In Scope
- Customer Portal;
- API yang digunakan aplikasi;
- authentication;
- authorization;
- fungsi utama aplikasi.
Out of Scope
- sistem partner;
- aplikasi pihak ketiga;
- sistem internal tertentu;
- destructive testing.
Scope ini penting agar tester mengetahui batasan pengujian.
Tahap 2: Authorization dan Rules of Engagement
Perusahaan memberikan authorization kepada tim pentest.
Kemudian disepakati:
- waktu pengujian;
- target;
- metode pengujian;
- batasan aktivitas;
- PIC;
- emergency contact;
- prosedur jika terjadi gangguan.
Misalnya pengujian hanya dilakukan pada:
Staging Environment
bukan production.
Ini dapat membantu mengurangi risiko terhadap operasional.
Tahap 3: Reconnaissance
Tester mulai memahami aplikasi.
Tujuannya adalah memetakan:
- halaman;
- fungsi;
- endpoint;
- authentication flow;
- API;
- dan attack surface.
Tester tidak langsung melakukan eksploitasi.
Langkah awal adalah:
Memahami bagaimana aplikasi bekerja.
Tahap 4: Mapping Attack Surface
Setelah melakukan reconnaissance, tester membuat pemetaan sederhana.
Contohnya:
Login
↓
Dashboard
↓
Customer Profile
↓
Transaction
↓
Document
↓
API
Setiap fungsi kemudian dipertimbangkan sebagai bagian dari attack surface.
Tahap 5: Vulnerability Identification
Tester melakukan security testing terhadap area yang telah ditentukan.
Beberapa kategori yang diperiksa antara lain:
Authentication
Apakah mekanisme login memiliki kontrol keamanan yang memadai?
Authorization
Apakah user hanya dapat mengakses data yang menjadi haknya?
Session Management
Apakah session dikelola dengan aman?
Input Validation
Apakah input pengguna diproses dengan benar?
API Security
Apakah API memiliki kontrol akses yang sesuai?
Business Logic
Apakah terdapat kelemahan dalam workflow aplikasi?
Temuan Pertama: Access Control
Salah satu temuan dalam studi kasus ini adalah kelemahan pada access control.
Bayangkan terdapat dua pengguna:
User A
dan
User B
User A seharusnya hanya dapat melihat data miliknya sendiri.
Namun tester menemukan kondisi di mana mekanisme authorization pada fungsi tertentu tidak diterapkan secara konsisten.
Akibatnya, terdapat potensi akses terhadap resource yang seharusnya bukan milik user tersebut.
Mengapa Temuan Ini Penting?
Dari perspektif teknis, masalahnya adalah:
Authorization Control Weakness
Namun dari perspektif bisnis, risikonya lebih besar.
Potensi dampaknya dapat mencakup:
- unauthorized access;
- data exposure;
- privacy risk;
- reputational risk;
- compliance risk.
Jadi laporan tidak cukup hanya mengatakan:
“Ditemukan vulnerability pada access control.”
Perusahaan perlu mengetahui:
“Apa dampaknya terhadap bisnis?”
Temuan Kedua: Authentication Weakness
Tester kemudian menemukan kelemahan pada mekanisme authentication.
Misalnya terdapat kontrol keamanan tertentu yang belum diterapkan secara optimal pada proses login.
Temuan tersebut kemudian dianalisis untuk mengetahui:
- kondisi yang diperlukan;
- tingkat risiko;
- sistem yang terdampak;
- dan potensi konsekuensinya.
Penting untuk dipahami bahwa menemukan potensi kelemahan authentication tidak otomatis berarti akun dapat diambil alih.
Temuan perlu divalidasi dalam batas scope yang telah ditentukan.
Temuan Ketiga: API Authorization
Aplikasi Customer Portal menggunakan API untuk mengambil data.
Tester kemudian melakukan pengujian terhadap mekanisme authorization API.
Hasil pengujian menunjukkan bahwa beberapa endpoint memiliki kontrol akses yang perlu diperkuat.
Ini menjadi penting karena:
Keamanan frontend tidak otomatis menjamin keamanan backend.
Misalnya aplikasi menyembunyikan sebuah tombol dari user.
Tetapi jika backend tidak melakukan authorization dengan benar, kontrol tersebut tetap dapat memiliki kelemahan.
Karena itu:
Authorization harus diterapkan di sisi server pada setiap fungsi yang membutuhkan pembatasan akses.
Temuan Keempat: Business Logic
Temuan berikutnya berkaitan dengan business logic.
Aplikasi memiliki proses:
Create Request
↓
Approval
↓
Processing
↓
Completion
Tester menemukan bahwa validasi pada salah satu tahap belum sepenuhnya konsisten.
Dalam kondisi tertentu, workflow dapat menghasilkan status yang tidak sesuai dengan aturan bisnis yang diharapkan.
Ini merupakan contoh bahwa vulnerability tidak selalu berbentuk:
“Bug teknis.”
Kelemahan juga dapat muncul dari:
Logika bisnis yang tidak divalidasi dengan baik.
Mengapa Scanner Saja Tidak Cukup?
Beberapa temuan dalam studi kasus ini mungkin tidak mudah ditemukan hanya dengan automated scanner.
Scanner sangat berguna untuk:
- discovery;
- detection;
- vulnerability identification.
Namun pengujian seperti:
Authorization
Business Logic
Workflow
sering membutuhkan pemahaman konteks aplikasi dan manual testing.
Inilah salah satu alasan mengapa:
Vulnerability assessment dan pentest memiliki fungsi yang berbeda.
Mengelompokkan Temuan
Setelah pengujian selesai, semua temuan dikategorikan.
Contoh:
| Finding | Severity | Area |
| Access Control Weakness | High | Customer Portal |
| Authentication Weakness | Medium | Login |
| API Authorization Issue | High | API |
| Business Logic Issue | Medium | Transaction |
Severity bukan sekadar label.
Setiap temuan perlu dianalisis berdasarkan:
- exploitability;
- affected asset;
- data sensitivity;
- business impact;
- dan criticality sistem.
Dari Technical Risk Menjadi Business Risk
Inilah bagian penting dalam laporan pentest.
Misalnya:
Technical Finding
API Authorization Weakness
↓
Potential Impact
Unauthorized access terhadap resource tertentu.
↓
Business Impact
Potensi paparan data pelanggan.
↓
Business Risk
Privacy, reputational, operational, atau compliance risk.
Dengan alur tersebut, management dapat memahami mengapa sebuah vulnerability perlu segera diperbaiki.
Bagaimana Perusahaan Menentukan Prioritas?
Tidak semua finding harus diperbaiki dengan urutan yang sama.
Perusahaan dapat menggunakan pendekatan:
Severity
Exploitability
Business Impact
Asset Criticality
Misalnya:
Finding A
High severity + data pelanggan + internet-facing
→ Prioritas tinggi
Finding B
Low severity + sistem internal non-kritis
→ Prioritas lebih rendah
Dengan pendekatan tersebut, remediation menjadi lebih terarah.
Tahap Remediation
Setelah menerima laporan pentest, tim perusahaan mulai melakukan perbaikan.
Misalnya:
Access Control
Memperkuat server-side authorization.
Authentication
Memperbaiki mekanisme authentication sesuai kebutuhan risiko.
API
Menerapkan authorization secara konsisten pada endpoint yang relevan.
Business Logic
Menambahkan validasi terhadap workflow.
Tahap ini membutuhkan kolaborasi antara:
Security
Developer
IT
Product Owner
Business
Mengapa Developer Perlu Terlibat?
Pentest bukan hanya urusan tim security.
Ketika vulnerability ditemukan pada aplikasi, developer biasanya menjadi bagian penting dari remediation.
Developer perlu memahami:
Mengapa vulnerability terjadi?
Bagaimana memperbaikinya?
Bagaimana mencegah vulnerability serupa muncul kembali?
Karena itu, hasil pentest dapat menjadi input untuk meningkatkan:
- secure coding;
- code review;
- application architecture;
- security testing;
- dan SDLC.
Tahap Retesting
Setelah remediation selesai, perusahaan melakukan retesting sesuai scope.
Tujuannya adalah memastikan:
Apakah vulnerability benar-benar sudah diperbaiki?
Contohnya:
Sebelum Remediation
Access control:
Finding → Open
Setelah Remediation
Dilakukan pengujian ulang.
Hasil:
Finding → Fixed
atau
Finding → Still Open
Jika masih terbuka, diperlukan perbaikan lanjutan.
Hasil Akhir Studi Kasus
Setelah seluruh proses selesai, perusahaan mendapatkan gambaran yang lebih jelas.
Sebelum pentest:
“Aplikasi kami berjalan normal.”
Setelah pentest:
“Kami mengetahui area mana yang memiliki risiko keamanan dan apa yang perlu diperbaiki.”
Perbedaannya sangat penting.
Aplikasi yang berjalan normal belum tentu:
Aplikasi yang aman.
Apa yang Dipelajari dari Studi Kasus Ini?
Ada beberapa pembelajaran penting.
1. Sistem Berjalan Normal Bukan Berarti Aman
Bug keamanan tidak selalu terlihat dalam operasional sehari-hari.
2. Authentication dan Authorization Harus Dibedakan
User yang berhasil login belum tentu boleh mengakses seluruh resource.
3. API Harus Diuji
Aplikasi modern sangat bergantung pada API.
4. Business Logic Penting
Tidak semua vulnerability dapat ditemukan melalui automated scanning.
5. Pentest Harus Menghasilkan Tindakan
Finding harus dilanjutkan dengan remediation.
6. Retesting Sangat Penting
Perusahaan perlu memastikan perbaikan efektif.
Pentest Bukan Sekadar “Mencari Bug”
Dari studi kasus tersebut terlihat bahwa nilai pentest bukan hanya menemukan bug.
Pentest membantu perusahaan memahami:
Attack Surface
↓
Vulnerability
↓
Exploitability
↓
Impact
↓
Risk
↓
Remediation
Dengan demikian, pentest menjadi bagian dari proses risk management dan continuous security improvement.
Kapan Perusahaan Sebaiknya Melakukan Pentest?
Pentest dapat dipertimbangkan ketika:
Aplikasi Baru Akan Diluncurkan
Terutama aplikasi yang berhubungan dengan pelanggan atau transaksi.
Ada Perubahan Besar
Misalnya perubahan architecture atau fitur penting.
Ada API Baru
Karena API dapat menjadi bagian penting dari attack surface.
Migrasi ke Cloud
Perubahan environment dapat membawa risiko baru.
Sistem Menangani Data Penting
Misalnya data pelanggan atau informasi bisnis penting.
Secara Berkala
Sebagai bagian dari security testing program perusahaan.
Checklist Pentest Aplikasi Perusahaan
Sebelum pentest:
☐ Tentukan tujuan pengujian
☐ Tentukan scope
☐ Tentukan target
☐ Pastikan authorization
☐ Tentukan Rules of Engagement
☐ Tentukan PIC
☐ Tentukan environment
☐ Siapkan backup/recovery sesuai kebutuhan
Saat pentest:
☐ Reconnaissance
☐ Attack surface mapping
☐ Vulnerability identification
☐ Validation
☐ Controlled testing
☐ Impact analysis
Setelah pentest:
☐ Review report
☐ Prioritize findings
☐ Remediation
☐ Retesting
☐ Update security control
Bagaimana Menjadikan Hasil Pentest sebagai Program Perbaikan?
Kesalahan umum perusahaan adalah menganggap pentest selesai ketika laporan diterima.
Padahal proses yang lebih ideal adalah:
Pentest
↓
Finding
↓
Risk Assessment
↓
Prioritization
↓
Remediation
↓
Retesting
↓
Security Improvement
Dengan cara ini, pentest menjadi bagian dari siklus keamanan yang berkelanjutan.
Pentest dan Pengembangan Kompetensi Tim
Teknologi saja tidak cukup untuk membangun keamanan aplikasi.
Perusahaan juga membutuhkan SDM yang memahami:
- cybersecurity;
- penetration testing;
- vulnerability assessment;
- secure application development;
- network security;
- risk management;
- dan incident response.
Terutama bagi perusahaan yang ingin membangun kemampuan cybersecurity internal.
Tim IT dan Security perlu memahami bagaimana:
Identify → Assess → Validate → Remediate → Retest
dilakukan secara terstruktur.
Training Pentest untuk Perusahaan bersama NEMA Academy
Studi kasus seperti di atas menunjukkan bahwa pentest melibatkan lebih dari sekadar penggunaan tools.
Dibutuhkan pemahaman mengenai:
Security Concept
Technology
Testing Methodology
Risk
Business Context
NEMA Academy dapat membantu perusahaan meningkatkan kompetensi SDM melalui program Training Pentest dan Cybersecurity yang dapat disesuaikan dengan kebutuhan organisasi.
Materi training dapat diarahkan untuk berbagai level:
Basic
Memahami fundamental cybersecurity dan penetration testing.
Intermediate
Memahami methodology, vulnerability assessment, dan security testing.
Advanced
Mendalami penetration testing dan analisis keamanan sesuai kebutuhan peserta dan scope training.
Training juga dapat menggunakan pendekatan:
Concept → Demonstration → Practice → Case Study → Review
Sehingga peserta tidak hanya belajar teori, tetapi memahami bagaimana sebuah security finding dapat dianalisis dan ditindaklanjuti.
Kesimpulan
Studi kasus pentest pada aplikasi perusahaan menunjukkan bahwa sistem yang terlihat berjalan normal belum tentu bebas dari risiko keamanan.
Dalam contoh kasus ini, pengujian menemukan beberapa area yang perlu diperhatikan, seperti:
- access control;
- authentication;
- API authorization;
- business logic.
Namun menemukan vulnerability hanyalah satu bagian dari proses.
Nilai sebenarnya dari pentest muncul ketika perusahaan melakukan:
Identify → Validate → Understand → Prioritize → Remediate → Retest
Dengan demikian, pentest bukan sekadar aktivitas untuk:
“Mencari celah.”
Tetapi menjadi proses untuk:
“Memahami risiko keamanan dan membantu perusahaan meningkatkan security posture.”
Semakin penting sebuah aplikasi bagi bisnis, semakin penting pula perusahaan memiliki proses security testing yang terstruktur.
Karena cybersecurity bukan hanya tentang teknologi.
Cybersecurity juga tentang:
People + Process + Technology + Continuous Improvement.
Butuh training IT untuk tim Anda?
NEMA Academy merancang in-house training dan pendampingan yang disesuaikan dengan kebutuhan organisasi Anda. Konsultasikan kebutuhan tim Anda langsung dengan kami.