Hari 13: Threat Modeling STRIDE & DREAD untuk API Perbankan

Scanner Hijau, Tapi Apakah Anda Aman?

Day 11 kemarin kita temuin 5 bug yang Trivy dan Semgrep lewati. Hari ini kita naik level: dari "apa yang scanner lihat" ke "apa yang attacker pikirkan".

Threat modeling itu proses berpikir seperti attacker. Bukan "tool apa yang bisa scan ini?" tapi "kalau aku jadi attacker, serangan apa yang aku coba?"

Metodologi: STRIDE + DREAD

STRIDE itu framework buat mengidentifikasi ancaman dari 6 kategori:

Kategori	Pertanyaan
Spoofing	Bisakah attacker berpura-pura jadi orang lain?
Tampering	Bisakah attacker modify data yang bukan haknya?
Repudiation	Bisakah user menyangkal aksi yang dilakukan?
Info Disclosure	Bisakah data sensitive bocor ke yang tidak berhak?
Denial of Service	Bisakah attacker bikin service unavailable?
Elevation of Privilege	Bisakah user biasa mendapat akses admin?

Lalu DREAD buat scoring setiap ancaman:

• Damage: Seberapa besar kerusakannya?
• Reproducibility: Seberapa mudah di-reproduce?
• Exploitability: Seberapa mudah di-exploit?
• Affected users: Berapa banyak user yang terdampak?
• Discoverability: Seberapa mudah attacker menemukan celah ini?

Score 0-10 per kategori, dirata-rata. Semua diatas 8 = Critical.

Hasil: 18 Ancaman, 12 Scored

Dari STRIDE analysis, kita nemuin 18 ancaman. 6 udah di-mitigasi (dari Day 11), 4 partially mitigated, 8 belum di-handle.

Yang paling kritis:

🔴 Critical (DREAD 8+)

Ancaman	DREAD	Kenapa Kritis
No rate limiting	9.6	Bot bisa flood API 1000 req/detik
Balance exposure	8.4	Siapa saja bisa lihat saldo siapa saja
Account ID manipulation	8.0	Bisa transfer dari akun orang lain

🟠 High (DREAD 6-7)

Ancaman	DREAD	Kenapa High
Hardcoded accounts	7.8	Hanya 2 akun, tanpa mekanisme registration
No connection limit	7.2	Server bisa kewalahan
No RBAC	6.6	Semua authenticated user punya akses yang sama
Default JWT secret	6.2	dev-secret-change-in-production bisa di-brute-force

Yang Sudah ✅ Mitigated

• JWT token forgery → HMAC-SHA256 signing
• Negative/zero amount transfer → Input validation
• JWT payload manipulation → Signature verification
• Large request body → LimitBodySize middleware
• Generic error messages → No stack trace leakage
• Security headers → 5 headers implemented

Attack Tree: Easiest Path

OR: Steal money from another account
├── Forge JWT token (hard — need secret)
├── Access balance of any account (EASY — just change ?id= parameter!)
└── Transfer from any account (EASY — just change "from" field!)

Attack path termudah: punya JWT valid → query /balance?id=ACC002 → lihat saldo siapa saja → kirim request ke /transfer dengan from: "ACC002". Tanpa authorization per user, API gak punya cara untuk ngecek bahwa pemilik token sebenarnya berhak akses akun ACC002.

Ini bedanya authentication (siapa kamu?) dan authorization (apa yang boleh kamu lakukan?). Day 11 kita implementasi auth, tapi belum authz.

Mitigation Roadmap

#	Mitigasi	DREAD	Target
1	Rate limiter (100 req/min/IP)	9.6	Fase 1
2	User-scoped authorization (JWT sub claim)	8.4	Fase 1-2
3	Persistent audit logging (JSON log ke file)	6.0	Fase 1-2

Yang lain (RBAC, connection limit, database, mandatory JWT_SECRET, HTTPS) schedule di Fase 2-3.

Lesson Learned

1. STRIDE itu systematic, bukan creative. Gak perlu mikir "apa serangan yang mungkin?" — cukup ikuti 6 kategori dan isinya otomatis keluar.

2. DREAD bikin prioritas objektif. Daripada bilang "ini bahaya," kita punya angka. No rate limiting (9.6) jelas lebih kritis daripada JWT_SECRET di env var (4.0).

3. Authentication ≠ Authorization. Kita udah punya auth (JWT), tapi belum authz (siapa boleh akses apa). Ini gap paling kritis yang STRIDE expose.

4. Attack tree visualisasi ini powerful. Dari tree jelas bahwa path termudah buat attacker adalah authorization bypass — bukan JWT forgery atau crypto attack.

5. Threat model itu living document. Versi 1.0 ini di-tag sekarang. Setiap kali ada fitur baru (database, RBAC, rate limiter), threat model harus di-update dan DREAD score di-re-calculate.

Lanjut ke Hari 14

Besok eksperimen yang seru: Intentional Vulnerability Test — commit fake secret ke branch baru, biarkan Gitleaks block PR, lalu revert. Ini validasi bahwa defense layer kita benar-benar bekerja.

Repo: github.com/stayrelevantid/chalange-devsecops