DevOps
Dasar-Dasar Penetration Testing untuk Developer: Yang Saya Pelajari dari PwC CTF
Mei 202610 menit baca
DevOps
Saya berkompetisi dalam kompetisi Capture the Flag (CTF) PwC pada tahun 2023 sebagai bagian dari tim, dan itu secara fundamental mengubah cara saya berpikir tentang keamanan aplikasi. Kompetisi CTF memampatkan kurva belajar penyerang — Anda menghabiskan berjam-jam mencoba mengeksploitasi sistem yang sengaja dibuat rentan, yang memberi Anda perspektif adversarial yang tidak dapat direplikasi oleh daftar periksa keamanan mana pun. Saya bukan seorang penetration tester. Saya adalah developer yang sekarang berpikir seperti penyerang saat menulis kode.
Hal paling berharga yang CTF ajarkan kepada saya bukan alat tertentu — melainkan pertanyaan: 'Apa yang diasumsikan developer yang bisa saya langgar?' Setiap kerentanan keamanan ada karena developer membuat asumsi yang bisa dipecahkan penyerang. Diasumsikan hanya admin yang dapat mengakses /admin? Coba tanpa auth. Diasumsikan harganya selalu positif? Kirim -1. Diasumsikan ekstensi file memberi tahu Anda jenis file? Unggah file PHP sebagai avatar.jpg. Pertanyaan adversarial ini adalah apa yang perlu diinternalisasi developer.
Sebelum mengeksploitasi apa pun, penyerang menghitung apa yang ada. Alat yang saya gunakan untuk recon pada aplikasi saya sendiri: nmap untuk pemindaian port (layanan apa yang terekspos), nmap --script untuk deteksi versi layanan, gobuster atau ffuf untuk enumerasi direktori/endpoint (path apa yang ada di luar yang ditampilkan UI), curl untuk analisis respons HTTP manual, dan theHarvester untuk OSINT (email dan subdomain apa yang terlihat publik).
# Developer security testing toolkit
# ONLY run against systems you own or have written authorization to test
# 1. Port scanning — what services are exposed?
nmap -sV -sC -p- yourdomain.com
# -sV: service version detection
# -sC: default scripts (identifies common misconfigs)
# -p-: all 65535 ports (slower but thorough)
# 2. Directory/endpoint enumeration
gobuster dir -u https://yourdomain.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
# or ffuf (faster):
ffuf -u https://yourdomain.com/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,302
# 3. Web server vulnerability scan
nikto -h https://yourdomain.com
# 4. OWASP ZAP automated scan (GUI or CLI)
docker run -t owasp/zap2docker-stable zap-baseline.py -t https://yourdomain.com
# 5. SQL injection test (against your own staging API)
sqlmap -u "https://staging.api.com/invoices?id=1" --cookie="Authorization=Bearer YOUR_TEST_TOKEN" --level=3 --risk=2 --batch --dbs
# 6. Check security headers
curl -I https://yourdomain.com | grep -E "X-Frame|X-Content|Strict|Content-Security|Referrer"
# 7. Test for common misconfigurations
curl -s https://yourdomain.com/.env # should be 404 or 403
curl -s https://yourdomain.com/.git/config # should be 404 or 403
curl -s https://yourdomain.com/admin # should require auth
curl -s https://yourdomain.com/api-docs # check if Swagger is exposed in prodDari pengalaman PwC CTF saya: kerentanan dalam tantangan CTF selalu jelas dalam retrospeksi — tetapi tidak terlihat saat Anda dalam mode developer. Berlatihlah beralih antara mode developer (membangun fitur) dan mode penyerang (mempertanyakan setiap asumsi). Saya melakukan tinjauan singkat mode penyerang untuk setiap fitur sebelum merge: apa yang bisa dikirim pengguna yang berbeda dari apa yang biasanya dikirim UI?
Anda tidak perlu menjadi penetration tester untuk menggunakan alat pengujian keamanan. Ini yang saya gunakan secara reguler untuk validasi keamanan tingkat developer: Burp Suite Community Edition (gratis) untuk memotong dan memodifikasi permintaan HTTP. OWASP ZAP untuk pemindaian aplikasi web otomatis. sqlmap untuk pengujian SQL injection. nikto untuk pemindaian kerentanan web server.
Burp Suite adalah alat paling kuat untuk menguji keamanan API secara manual. Konfigurasikan browser atau klien API Anda untuk proxy melalui Burp (127.0.0.1:8080), jelajahi aplikasi Anda secara normal, dan Burp menangkap semua lalu lintas HTTP dalam Proxy History-nya. Dari sana, Anda dapat: mengirim permintaan ke Repeater untuk memodifikasi dan mengirim ulang, menggunakan Intruder untuk fuzzing input secara sistematis.
┌─────────────────────────────────────────────────────────────┐
│ Developer Security Testing Workflow │
│ │
│ Pre-release checklist for every significant feature: │
│ │
│ 1. Port scan (nmap) → verify only expected ports open │
│ └── Should see: 22 (SSH), 80 (HTTP), 443 (HTTPS) only │
│ │
│ 2. Directory enum (gobuster) → find exposed paths │
│ └── Check: /.env, /.git, /admin, /swagger, /api-docs │
│ │
│ 3. Burp Suite manual review → new API endpoints │
│ └── Test: IDOR (change resource IDs) │
│ └── Test: Auth bypass (remove Authorization header) │
│ └── Test: Mass assignment (add extra JSON fields) │
│ │
│ 4. sqlmap → endpoints with DB interaction │
│ └── Confirm: parameterized queries only │
│ │
│ 5. Security headers check (securityheaders.com) │
│ └── Target: A or A+ rating │
│ │
│ 6. SSL Labs scan (ssllabs.com) │
│ └── Target: A+ rating │
└─────────────────────────────────────────────────────────────┘Alat pengujian keamanan kuat dan dapat menyebabkan kerusakan. Hanya jalankan alat penetration testing terhadap sistem yang Anda miliki atau memiliki otorisasi tertulis eksplisit untuk diuji. Menjalankan pemindaian nmap atau Burp Suite terhadap sistem tanpa izin adalah ilegal di sebagian besar yurisdiksi — bahkan jika Anda menemukan kerentanan dan melaporkannya secara bertanggung jawab. Sebelum menguji sistem pihak ketiga apa pun, verifikasi ia memiliki program bug bounty atau vulnerability disclosure.
Alur kerja pengujian keamanan pra-rilis saya untuk setiap fitur atau perubahan API signifikan: (1) pemindaian nmap terhadap staging untuk memverifikasi hanya port yang diharapkan yang terbuka. (2) pemindaian gobuster untuk menemukan path yang terekspos yang tidak dimaksudkan untuk publik. (3) tinjauan manual Burp Suite atas endpoint API baru — menguji IDOR, bypass autentikasi, dan validasi input. (4) sqlmap terhadap endpoint mana pun dengan interaksi database. (5) pemindaian otomatis OWASP ZAP.
Tantangan CTF yang paling sering muncul dalam code review setelah kompetisi: JWT dengan algorithm confusion (menerima algoritma apa pun, termasuk none), IDOR melalui ID numerik berurutan (gunakan UUID sebagai gantinya), path traversal dalam endpoint upload/download file (jangan pernah gunakan nama file yang disediakan pengguna dalam path filesystem), SSRF melalui fitur URL fetch (validasi dan batasi URL keluar), race condition dalam operasi penurunan saldo/inventaris, dan pengungkapan informasi dalam pesan error.
Kontrol teknis hanya sejauh itu — budaya keamanan adalah yang membuatnya bertahan. Yang saya lakukan: tinjauan keamanan sebagai item daftar periksa yang diperlukan dalam setiap template PR, sesi tim bulanan meninjau CVE terbaru dan laporan pelanggaran, saluran Slack 'keamanan menarik' bersama untuk berbagi temuan dari kompetisi CTF dan penelitian keamanan, dan proses post-mortem tanpa menyalahkan untuk insiden keamanan.