Web Application Security Fundamentals #01: Apa Itu Web Application Security?

Web application security adalah praktik melindungi aplikasi web dari attack yang memanfaatkan design flaws, implementation bugs, atau misconfigurations. Tujuannya: ensure confidentiality, integrity, dan availability data & functionality.

Mengapa Web Security Penting?

Data at Risk:

• Customer PII (personal identifiable information)
• Payment/financial data
• Proprietary business logic
• User credentials

Threat Vectors:

• External attackers (cybercriminals)
• Disgruntled employees (insider threats)
• Supply chain compromises
• Unpatched dependencies

Tujuan Pembelajaran

Setelah modul ini, Anda dapat:

• Menjelaskan konsep fundamental security (assets, threats, vulnerabilities, risk)
• Memahami trust boundaries dalam aplikasi
• Design security dengan mindset "defense in depth"
• Identify potential threats menggunakan threat scenarios

Konsep Fundamental

1. Asset

Asset = sesuatu yang bernilai dan perlu diproteksi.

Customer database → Bernilai tinggi (PII, financial data)
Admin panel → Bernilai tinggi (dapat manipulate sistem)
Public documentation → Bernilai rendah (already public)

2. Threat & Threat Actor

Threat = potential danger atau negative event.
Threat Actor = siapa/apa yang menjalankan threat.

Threat: SQL Injection attack → extract customer data
Threat Actor: External hacker (motivated by profit/curiosity)

Threat: Insider steals data
Threat Actor: Disgruntled employee (motivated by revenge)

Threat: Ransomware shutdown service
Threat Actor: Organized cybercrime group (motivated by ransom payment)

3. Vulnerability

Vulnerability = weakness dalam sistem yang dapat diexploit.

Vulnerability: No input validation → SQL Injection possible
Vulnerability: Hardcoded credentials → Authentication bypass
Vulnerability: Weak password policy → Brute force possible

4. Risk

Risk = combination of threat, vulnerability, dan impact.

Risk = (Likelihood × Impact)

Example:
- Threat: SQL Injection attack
- Vulnerability: Query concatenation (no parameterization)
- Likelihood: High (easy to exploit, publicly known)
- Impact: High (10K customer records exposed)
- Risk Score: High × High = CRITICAL

To reduce risk:
- Eliminate vulnerability (use parameterized queries)
- Reduce likelihood (add WAF, rate limiting)
- Reduce impact (encrypt data, minimize data exposure)

Trust Boundaries

Trust Boundary = imaginary line dimana trust properties berubah.

Trusted Zone (inside network)
    ↓ Trust Boundary ↓
Untrusted Zone (internet)

Example Flow:
User Input (UNTRUSTED)
    ↓
Web Server (TRUSTED - we control)
    ↓
Database (TRUSTED - we control)

Principle: Treat everything outside trust boundary sebagai untrusted.
Never assume input from user adalah safe, even if from authenticated user.

Visual Trust Boundary Diagram:

┌─────────────────────────────────┐
│   OUR APPLICATION (Trusted)     │
│                                 │
│  ┌──────────────┐               │
│  │ Web Server   │               │
│  └──────────────┘               │
│         ↑                       │
│ ════════════════════════════    │ ← TRUST BOUNDARY
│         ↓                       │
└─────────────────────────────────┘
         ↑
    USER INPUT (Untrusted)
    Browser
    Mobile App
    Third-party API

Defense in Depth

Bukan satu control yang sempurna, tetapi multiple overlapping controls.

Layer 1: Input Validation (reject invalid data early)
         ↓
Layer 2: Parameterized Queries (prevent injection)
         ↓
Layer 3: Output Encoding (prevent XSS)
         ↓
Layer 4: Security Headers (browser-level defense)
         ↓
Layer 5: WAF (Web Application Firewall)
         ↓
Layer 6: Logging & Monitoring (detect breaches)
         ↓
Layer 7: Incident Response (contain damage)

Jika Layer 2 gagal, Layer 3-7 masih protect.

Threat Scenarios

Gunakan threat scenarios untuk identify potential attacks.

Example Scenario 1: IDOR (Insecure Direct Object Reference)

Threat Actor: Authenticated user
Objective: Access data milik user lain
Attack Path:
  1. User A login
  2. User A visit /api/invoices/123 (miliknya)
  3. User A ubah URL ke /api/invoices/999 (milik User B)
  4. Server return User B's invoice (VULNERABLE!)

Risk: High (easy to exploit, high impact - financial data exposed)
Mitigation: Always verify user owns the resource

Example Scenario 2: SQL Injection

Threat Actor: Unauthenticated attacker
Objective: Extract customer database
Attack Path:
  1. Attacker visit /search?q=test' OR '1'='1
  2. Query becomes: SELECT * FROM products WHERE name = 'test' OR '1'='1'
  3. '1'='1' always true → return all products
  4. Attacker extract all data (VULNERABLE!)

Risk: CRITICAL (easy to exploit, extremely high impact)
Mitigation: Use parameterized queries

Example Scenario 3: Account Takeover via Session Hijacking

Threat Actor: Network attacker (same WiFi network)
Objective: Hijack user session
Attack Path:
  1. User login di coffee shop (unencrypted WiFi)
  2. Attacker sniff traffic (packet capture)
  3. Attacker extract session cookie (VULNERABLE!)
  4. Attacker use cookie to impersonate user
  5. Attacker change password, access sensitive data

Risk: HIGH (moderate effort, very high impact)
Mitigation: HTTPS + HttpOnly cookie + Secure flag

Baseline Security Checklist (30+ items)

Gunakan ini sebagai starting point untuk audit:

• [ ] Input validation implemented server-side
• [ ] Parameterized queries used (no string concatenation)
• [ ] Output encoding done (context-aware)
• [ ] HTTPS enabled for all endpoints
• [ ] Security headers present (HSTS, CSP, X-Frame-Options)
• [ ] Authentication required untuk sensitive functions
• [ ] Authorization checked every request
• [ ] Session tokens generated securely (256+ bit random)
• [ ] Cookies have HttpOnly, Secure, SameSite flags
• [ ] Rate limiting implemented (brute force defense)
• [ ] File uploads validated (type, size, content)
• [ ] Error messages don't leak internals
• [ ] Passwords hashed with strong algorithms (Argon2id/bcrypt)
• [ ] Logging captures security events
• [ ] Logs don't contain sensitive data (passwords, tokens)
• [ ] Dependencies scanned untuk known vulnerabilities
• [ ] No hardcoded secrets (API keys, credentials)
• [ ] Database access uses least privilege accounts
• [ ] Admin panel requires MFA
• [ ] Account lockout after N failed login attempts
• [ ] Session timeout implemented
• [ ] Logout invalidates session
• [ ] CSRF tokens implemented untuk state-changing operations
• [ ] Clickjacking defense (X-Frame-Options header)
• [ ] XXE prevention (disable XML entity expansion)
• [ ] Insecure deserialization prevention
• [ ] SSRF mitigation (validate URLs)
• [ ] API endpoints documented & versioned
• [ ] Incident response plan exists
• [ ] Regular security training conducted
• [ ] Penetration testing scheduled
• [ ] Bug bounty program available

Kesalahan Umum dalam Security

❌ "Kami tidak perlu security, kami aplikasi kecil saja"
Ukuran aplikasi tidak matter. Attackers target semua ukuran. Bahkan kecil bisa jadi stepping stone untuk attack besar.

❌ "Security = firewall + antivirus"
Network security penting, tapi aplikasi-level security lebih penting. Bad code akan tetap bad di balik firewall.

❌ "Kami akan fix security nanti"
Security debt terakumulasi dan menjadi mahal untuk fix. Fix dari awal jauh lebih murah.

❌ "Obscurity = Security"
Hiding implementation details bukan security. Security through obscurity selalu gagal. Gunakan proven best practices.

Kesimpulan

Web application security bukan optional — ini foundational untuk trust. Dengan memahami assets, threats, vulnerabilities, dan risks, Anda dapat design & build aplikasi yang defensible.

Modul berikutnya membahas CIA Triad dan security objectives secara detail.

Referensi

• OWASP: Threat Modeling
• OWASP: Top 10 Vulnerabilities
• Microsoft: Threat Modeling Security Fundamentals

Baca Berikutnya: #02 - Tujuan Utama Web Security: CIA, Authenticity, & Non-Repudiation