Pembahasan ujian Registered Information Security Specialist musim semi Reiwa 6, soal 1 sesi sore — JWT alg=none, otorisasi API, dan tindakan WAF sementara

“Tanda tangan JWT diverifikasi, jadi ID pengguna dapat dipercaya.”

Ungkapan itu hanya setengah benar.

Soal 1 sesi sore ujian Registered Information Security Specialist musim semi tahun anggaran Reiwa 6 memakai API yang dipanggil dari ponsel sebagai bahan.¹ Setelah autentikasi berhasil, JWT diterbitkan, lalu JWT itu dilampirkan untuk memanggil API pengambilan dan pembaruan informasi pengguna. Sekilas, susunannya biasa.

Namun, asesmen menemukan empat hal berikut.

1. Mengubah alg pada header JWT menjadi none membuat JWT tanpa tanda tangan lolos
2. Tetap memakai JWT yang sah, lalu mengubah mid ke ID pengguna lain, memungkinkan informasi orang lain diambil dan diperbarui
3. Menambahkan status=paid yang tidak ada di spesifikasi mengubah pengguna gratis menjadi pengguna berbayar
4. Kode autentikasi 4 digit yang dikirim lewat email dapat di-brute-force tanpa batas

Keempatnya tampak seperti “kerentanan di sekitar autentikasi”, tetapi penyebabnya tidak sama. Yang dilanggar adalah batas-batas yang terpisah: integritas token, otorisasi tingkat objek, otorisasi tingkat properti, dan batas jumlah percobaan.

Di bagian belakang, topik lain lagi ditambahkan. Pada pustaka sumber terbuka yang dipakai luas, diumumkan kerentanan serius yang memungkinkan eksekusi kode dari luar dengan menyalahgunakan JNDI Lookup. Belum ada versi perbaikan maupun aturan WAF yang selesai. Sementara itu, yang ditanyakan adalah bagaimana mengonfirmasi dampak, di mana WAF harus melihat, dan mengapa pada awalnya dipilih “deteksi” bukan “pemblokiran”.

Artikel ini bertumpu pada contoh jawaban resmi² dan komentar penilaian³, lalu merapikan bukan hanya jawaban tiap soal, melainkan mengapa itu menjadi jawaban, dan seberapa ketat rancangan praktisnya.

flowchart TB
    accTitle: Gambaran keseluruhan soal
    accDescr: Menunjukkan batas kepercayaan yang dilanggar pada tiap tahap kode autentikasi, JWT, otorisasi API, dan kerentanan pustaka
    user[Aplikasi pengguna]
    auth[Kode autentikasi 4 digit]
    jwt[Penerbitan JWT]
    api[API pengguna]
    log[Keluaran log]
    vuln[Pustaka yang rentan]
    ext[Eksekusi kode eksternal]
    user --> auth
    auth -->|tanpa batas jumlah percobaan| jwt
    jwt -->|mengizinkan alg=none| api
    api -->|mempercayai mid| db1[Ambil/perbarui data orang lain]
    api -->|status=paid| db2[Ubah status penagihan]
    api --> log
    log --> vuln
    vuln -->|JNDI/LDAP/HTTP| ext

Gambar 1: Gambaran keseluruhan soal. Pada tiap tahap, batas kepercayaan yang berbeda dilanggar.

1. Kesimpulan lebih dulu

• Sifat RESTful API yang tidak memegang sesi adalah stateless. Namun, itu tidak berarti server sama sekali tidak memegang basis data atau keadaan pengguna
• Kode autentikasi 4 digit ada 10.000 kemungkinan. Pada 10 kali per detik, rata-rata 5.000 percobaan, berhasil dalam 500 detik. Itu lebih pendek dari masa berlaku 10 menit, jadi waktu kedaluwarsa saja tidak cukup
• Tindakan minimum terhadap alg=none adalah memastikan alg pada header JWT bukan NONE. Namun dalam praktik, tetapkan algoritme yang diizinkan di sisi server
• Meski JWT benar, mid pada permintaan tidak boleh dipercaya. Cocokkan ID pengguna di dalam JWT dengan mid, atau lebih aman: jangan menerima mid dan tentukan sasaran dari JWT
• Penambahan status=paid adalah masalah Mass Assignment yang mengikat properti di luar spesifikasi ke objek internal. Pakai DTO pembaruan sebagai daftar izinkan, dan jangan biarkan pengguna mengubah status penagihan
• Jawaban untuk tindakan brute-force adalah pemrosesan yang mengunci akun jika jumlah kegagalan beruntun melebihi ambang. Dalam praktik, tumpuk juga penundaan bertahap dan pengendalian per sumber
• Pada konfirmasi dampak kerentanan serius yang baru, jangan memakai perintah merusak; catat akses ke index.html pada server uji untuk mengonfirmasi bahwa rantai eksekusi kode eksternal sampai
• String serangan masuk ke header HTTP, jadi sasaran pemeriksaan WAF adalah Header. Sebagai regex yang menangani pertukaran huruf besar/kecil, misalnya \W[jJ][nN][dD][iI]\W
• Keuntungan mengatur WAF ke “deteksi” lebih dulu adalah dapat mencegah pemblokiran komunikasi bisnis akibat deteksi keliru. Setelah peringatan diterima, telaah apakah itu serangan, lalu pindah ke pemblokiran setelah penyesuaian
• WAF adalah tindakan sementara; tindakan akarnya adalah memperbarui pustaka yang terdampak ke versi perbaikan

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 18, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Korespondensi bahan dan soal

Panggung soalnya adalah perusahaan G yang akan mulai menyediakan layanan kesehatan. Pengguna memasukkan makanan, berat badan, dan data lain dari aplikasi ponsel, lalu menerima penilaian risiko kesehatan dan saran menu. Sistem dibangun di cloud, dengan kombinasi API gateway, pemrosesan berbasis peristiwa, dan basis data terkelola.

Nama produk dan nama layanan dalam naskah soal diabstraksikan. Artikel ini juga tidak menyalin tabel atau kalimat IPA; hanya struktur yang perlu untuk memahami soal yang diungkapkan kembali.

Menurut komentar penilaian, tingkat jawaban benar keseluruhan rata-rata. Di sisi lain, tindakan pemalsuan JWT pada soal 2(2) dan mekanisme yang diperlukan pada server uji pada soal 3(1) dinilai tingkat jawaban benarnya agak rendah. Keduanya tidak bisa dijawab hanya dengan mengetahui istilah. Perlu menelusuri nilai mana yang diubah penyerang, ke pemrosesan mana nilai itu mengalir, dan di mana nilai itu dipercaya.

3. Soal ini bukan satu “masalah autentikasi”

Jika seluruh soal disusun menurut batas kepercayaan, hasilnya seperti berikut.

[ID pengguna · kata sandi]
          |
          v
[Konfirmasi kode 4 digit] ---- tanpa batas jumlah percobaan ----> brute-force
          |
          v
[Menerbitkan JWT]
          |
          v
[Pustaka JWT] ------- mengizinkan alg=none ------> pemalsuan ID pengguna
          |
          v
[API pengguna]
    |             |
    |             +-- meneruskan status utuh ----> celah otorisasi tingkat properti
    |
    +-- mempercayai mid -----------------------> celah otorisasi tingkat objek

[Mencatat masukan eksternal ke log]
          |
          v
[Pustaka yang rentan] ---- JNDI/LDAP/HTTP ------> eksekusi kode eksternal

Yang paling penting di sini adalah pembedaan berikut.

Keberhasilan pemeriksaan sebelumnya bukan alasan untuk melewatkan pemeriksaan berikutnya. Pengguna yang memegang JWT yang sah pun tidak otomatis boleh membaca data orang lain. Pengguna yang boleh memperbarui datanya sendiri pun tidak otomatis boleh mengubah status penagihan.

Jika pemisahan tahap ini bisa dilakukan, jawaban tiap soal tidak lagi hafalan.

flowchart LR
    accTitle: Perbedaan autentikasi dan otorisasi
    accDescr: Autentikasi mengonfirmasi subjek, otorisasi mengonfirmasi operasi yang diizinkan bagi subjek itu
    auth[Autentikasi<br/>siapa]
    authz[Otorisasi<br/>apa yang boleh dilakukan]
    auth --> authz

Gambar 2: Perbedaan autentikasi dan otorisasi. Autentikasi lebih dulu, otorisasi adalah pemeriksaan terpisah.

4. Soal 1 — apa itu stateless

Soal 1 menanyakan salah satu prinsip rancangan RESTful API, yaitu sifat tidak melakukan pengelolaan sesi.

Jawabannya adalah stateless.

Stateless berarti, tanpa server mengingat keadaan percakapan permintaan sebelumnya, informasi yang diperlukan untuk pemrosesan sudah lengkap pada tiap permintaan. Dalam soal ini, aplikasi ponsel menempelkan JWT ke header Authorization pada setiap permintaan. Server memverifikasi JWT itu dan mengidentifikasi pengguna permintaan tersebut.

Yang mudah disalahartikan adalah membaca stateless sebagai “server tidak memegang keadaan apa pun”. Pada kenyataannya, keadaan berikut biasa dipegang.

• Basis data yang menyimpan informasi pengguna dan data kesehatan
• Status penagihan
• Nilai kode autentikasi, masa berlaku, jumlah kegagalan
• Kunci tanda tangan JWT
• Jika rancangannya memakai daftar pencabutan, informasi pencabutan itu
• Log dan catatan audit

Yang tidak dipegang adalah tidak menjadikan keadaan sesi sisi server yang hanya untuk melanjutkan percakapan sebagai prasyarat tiap pemanggilan API.

Selain itu, bersifat stateless tidak secara otomatis meningkatkan keamanan. Mengirim JWT setiap kali memudahkan penskalaan horizontal, tetapi jika verifikasi JWT salah, kesalahan itu juga menyebar merata ke semua node. Sifat arsitektur dan kebenaran keamanan adalah hal yang berbeda.

5. Soal 2(1) — kode 4 digit mengenai rata-rata dalam 500 detik

API autentikasi, jika ID pengguna dan kata sandi cocok, mengirim angka 4 digit ke email. Setelah itu, jika ID pengguna dan kode 4 digit cocok, JWT diterbitkan. Kode berlaku 10 menit sejak dibuat.

Dalam asesmen, 10 percobaan per detik memungkinkan. Yang diminta adalah berapa detik rata-rata sampai tembus.

Perhitungannya adalah “setengah jumlah kandidat”

Angka 4 digit, termasuk 0 di depan, adalah 10.000 kemungkinan berikut.

0000, 0001, 0002, ... , 9999

Jika jawaban dipilih seragam, rata-rata jumlah percobaan sampai penyerang yang mencoba berurutan tanpa duplikat mengenai jawaban adalah setengah jumlah kandidat.

rata-rata jumlah percobaan = 10.000 ÷ 2 = 5.000 kali
rata-rata waktu             = 5.000 ÷ 10 kali/detik = 500 detik

Karena itu, isian b adalah 500.

Maksimum memakan 1.000 detik, tetapi yang ditanyakan soal adalah rata-rata. Masa berlaku kode adalah 600 detik, lebih panjang dari 500 detik waktu tembus rata-rata. Itulah alasan dinilai “kemungkinan tembus tinggi”.

flowchart LR
    accTitle: Skala waktu kode autentikasi 4 digit
    accDescr: 10.000 kemungkinan pada 10 kali per detik berarti rata-rata 5.000 percobaan, 500 detik, lebih pendek dari masa berlaku 600 detik
    A[Jumlah kandidat 10.000] -->|rata-rata 10.000 / 2 = 5.000 kali| B[Waktu tembus rata-rata 500 detik]
    C[Masa berlaku 600 detik] -->|500 detik < 600 detik| D[Dapat tembus dalam masa berlaku]

Gambar 9: Skala waktu kode autentikasi 4 digit. Mencoba rata-rata setengah jumlah kandidat mengenai dalam masa berlaku.

Memendekkan waktu kedaluwarsa saja kalah jika kandidat sedikit

Kekuatan kode autentikasi tidak ditentukan hanya oleh jumlah digit atau hanya oleh masa berlaku.

jumlah percobaan dalam masa berlaku
= percobaan per detik × masa berlaku
= 10 × 600
= 6,000 kali

Jika nilai tanpa duplikat dicoba berurutan, 60% dari 10.000 dapat diperiksa dalam masa berlaku. Meski ada waktu kedaluwarsa, tanpa batas jumlah percobaan itu tidak cukup.

NIST SP 800-63B yang berlaku menuntut setidaknya 6 digit untuk rahasia jangka pendek pada autentikasi out-of-band, dan mewajibkan batas jumlah percobaan jika kurang dari 64 bit. Selain itu, email tidak boleh dipakai untuk autentikasi out-of-band.⁴ Dalam ujian, jawaban disusun di dalam spesifikasi 4 digit dan pengiriman email yang diberikan, tetapi pada rancangan baru di praktik, prasyarat itu sendiri juga perlu ditinjau.

6. Soal 2(2) — alg=none adalah masalah “membiarkan penyerang memilih cara verifikasi”

JWT dalam soal terdiri dari tiga bagian: header, payload, dan tanda tangan.

base64url(header).base64url(payload).base64url(signature)

Pada header tercatat RS256 sebagai algoritme tanda tangan. Pada payload ada ID pengguna, waktu penerbitan, dan masa berlaku.

Asesor mengubah dua hal berikut.

1. Mengubah alg pada header dari RS256 menjadi NONE
2. Mengubah ID pengguna pada payload ke pengguna lain

JWT itu dikirim, verifikasi berhasil, dan penyamaran sebagai orang lain berhasil.

flowchart LR
    accTitle: Alur serangan JWT alg=none
    accDescr: Mengubah alg menjadi none dari JWT yang sah, menulis ulang ID pengguna, lalu lolos
    A[JWT sah<br/>alg=RS256<br/>user=user01] -->|alg header ke none| B[JWT dipalsukan<br/>alg=none<br/>user=user02]
    B -->|melewati verifikasi tanda tangan| C[Server menerima<br/>sebagai user02]

Gambar 3: Alur serangan JWT alg=none. Penyerang yang memilih algoritme verifikasi.

none bukan salah eja string

RFC 7519 mendefinisikan “Unsecured JWT” dengan alg bernilai none sebagai JWT tanpa tanda tangan maupun enkripsi.⁵ Jadi nilai none bukan sesuatu yang sama sekali tidak ada dalam spesifikasi.

Masalahnya adalah API yang seharusnya hanya menerima JWT bertanda tangan justru menerima none yang ditentukan penyerang.

Pemrosesan yang rentan, secara konseptual, seperti berikut.

1. Membaca header JWT
2. Melihat alg yang tertulis di header, lalu memilih cara verifikasi
3. Jika alg adalah none, tidak melakukan verifikasi tanda tangan
4. Mempercayai ID pengguna pada payload

Kekuatan keamanan itu sendiri dipilih dari masukan yang dikendalikan penyerang.

Jawaban ujian

Soal menanyakan, masing-masing dalam 20 karakter atau kurang, data mana yang diverifikasi pustaka Q setelah perbaikan, dan verifikasi seperti apa yang dilakukan.

Contoh jawaban sebagai berikut.

Sebagai perbaikan langsung terhadap kerentanan dalam naskah soal, ini benar.

Dalam praktik, jangan berhenti di “asal bukan NONE”

Di sini perlu memisahkan jawaban ujian dan rekomendasi praktis.

RFC 8725 menyatakan bahwa pustaka JWT harus meminta pemanggil menentukan himpunan algoritme yang diizinkan, dan tidak boleh memakai yang di luar himpunan itu.⁶ Artinya, cara pikir seperti berikut.

cara pikir buruk:
  terima jika token.header.alg != "none"

cara pikir baik:
  terima hanya jika termasuk dalam serverConfig.allowedAlgorithms
  contoh: allowedAlgorithms = ["RS256"]

Meski hanya none yang ditolak, algoritme lemah lain, atau kebingungan algoritme yang mencampur skema kunci publik dan kunci simetris, masih mungkin tersisa. Prinsipnya adalah bukan menambah syarat penerimaan dalam bentuk negatif, melainkan mempersempit dan menetapkan syarat yang diizinkan.

Pada verifikasi JWT, selain algoritme, setidaknya butir berikut dikonfirmasi sesuai penggunaan.

Dalam soal ini nama kunci payload adalah user, tetapi dalam praktik pakai sub standar, atau definisikan dengan jelas makna klaim kustom.

flowchart TB
    accTitle: Verifikasi JWT yang aman dan yang berbahaya
    accDescr: Verifikasi berbahaya bergantung pada alg; verifikasi aman memakai daftar izinkan sisi server
    subgraph "Verifikasi berbahaya"
        D1[Membaca alg header JWT]
        D2[Terima jika alg adalah none]
        D1 --> D2
    end
    subgraph "Verifikasi aman"
        S1[Algoritme yang diizinkan di konfigurasi server<br/>contoh: RS256]
        S2[Konfirmasi apakah alg header JWT<br/>termasuk daftar izinkan]
        S3[Verifikasi tanda tangan, iss, aud, exp]
        S1 --> S2 --> S3
    end

Gambar 4: Verifikasi aman dan berbahaya. Dalam praktik, tetapkan sempit algoritme yang diizinkan.

Base64url bukan enkripsi

Ada satu lagi salah paham yang sering terjadi pada JWT. Header dan payload dinyatakan dalam base64url, tetapi itu bukan enkripsi. Siapa pun dapat mendekode dan membacanya.

Yang dijamin tanda tangan, hanya jika verifikasi berhasil, adalah bahwa isi tidak dipalsukan setelah penerbitan. Itu tidak berarti informasi pribadi yang harus dirahasiakan boleh dimasukkan ke payload JWT bertanda tangan.

7. Soal 2(3) — meski JWT benar, mengubah mid cukup untuk membaca orang lain

Berikutnya adalah serangan yang tidak memalsukan JWT itu sendiri.

API pengguna menerima ID pengguna bernama mid lewat GET atau PUT. Modul bersama P mengambil dan memperbarui informasi pengguna yang terikat pada mid itu dari basis data.

Skema serangannya sederhana.

ID pengguna di JWT: user01    ← JWT yang ditandatangani dengan benar
mid permintaan: user02        ← diubah penyerang

Tanda tangan JWT benar, jadi autentikasi berhasil. Namun API mempercayai mid=user02 apa adanya, dan mengembalikan informasi user02.

Ini contoh khas Broken Object Level Authorization (BOLA) dalam OWASP API Security Top 10 2023. Ketika data diakses memakai ID objek yang ditentukan pengguna, otorisasi ke objek itu harus dikonfirmasi setiap kali.⁷

flowchart LR
    accTitle: Serangan BOLA
    accDescr: Tetap memakai JWT yang sah, lalu mengubah mid permintaan ke ID pengguna lain
    A[Penyerang] -->|JWT: user01<br/>mid: user02| B[API pengguna]
    B -->|mempercayai mid| C[Mengembalikan info user02 dari DB]

Gambar 5: Serangan BOLA. Autentikasi lolos, tetapi otorisasi tidak dikonfirmasi.

Jawaban soal

Garis bawah ② pada tabel 5 menanyakan pemrosesan yang ditambahkan ke pemanggilan modul bersama P, dalam 40 karakter atau kurang.

Contoh jawabannya sebagai berikut.

Pemrosesan yang memverifikasi apakah ID pengguna di dalam JWT cocok dengan nilai mid

Keuntungan memverifikasi di modul bersama P adalah otorisasi yang sama mudah diterapkan pada GET dan PUT, serta pada API lain yang kelak memakai P. Jika perbandingan yang sama disalin ke tiap layar atau endpoint, salah satu akan terlewat.

Rancangan yang lebih aman: jangan menerima mid

Jika API hanya mengambil dan memperbarui informasi diri sendiri, tidak perlu menerima ID pengguna dari klien.

GET /users/me
Authorization: Bearer <JWT>

Di sisi server, subjek diambil dari JWT yang sudah diverifikasi.

principal = validateJwt(request.authorization)
userId = principal.subject
return repository.getUser(userId)

Pembaruan sama.

principal = validateJwt(request.authorization)
input = validateProfileUpdate(request.body)
repository.updateProfile(
    userId = principal.subject,
    name = input.name,
    age = input.age
)

Pemrosesan perbandingan, jika ditulis, dapat melindungi. Namun jika rancangannya tidak menerima ID sasaran dari luar, jenis bug karena lupa menulis perbandingan itu sendiri berkurang.

Jika administrator perlu mengoperasikan informasi pengguna lain, pisahkan seperti berikut.

PUT /users/me                  untuk pengguna umum
PUT /admin/users/{userId}      untuk administrator

Untuk administrator, minta wewenang terpisah, log audit, dan jika perlu autentikasi ulang. Batas kebijakan otorisasi lebih terlihat daripada “menambah pengecualian hanya jika administrator pada API pengguna umum”.

flowchart LR
    accTitle: Cara mencegah BOLA
    accDescr: Jangan memakai mid permintaan; tentukan sasaran dari subjek JWT, atau cocokkan
    A[Pengguna] -->|GET /users/me + JWT| B[API]
    B -->|ambil sub JWT| C{jika ada mid,<br/>apakah cocok dengan sub}
    C -->|cocok| D[Kembalikan data sendiri]
    C -->|tidak cocok| E[Tolak 403]
    B -->|tanpa mid| F[Cari DB dengan sub JWT]

Gambar 6: Cara mencegah BOLA. Jangan menerima mid, atau cocokkan dengan subjek JWT.

Membedakan autentikasi dan otorisasi dalam satu kalimat

Baik di ujian maupun praktik, rumusan berikut berguna.

• Autentikasi: siapa
• Otorisasi: apa yang boleh dilakukan orang itu

Berhasilnya verifikasi tanda tangan JWT hanya sampai “subjek yang diwakili token ini dapat dipercaya”. “Subjek itu boleh membaca user02” harus dikonfirmasi secara terpisah.

8. Soal 2(4) — status=paid adalah celah otorisasi tingkat properti

Pada spesifikasi API pengguna, parameter pembaruan yang didefinisikan adalah sebagai berikut.

mid   ID pengguna
name  nama
age   usia

Namun asesor menambahkan nilai berikut yang tidak ada di spesifikasi.

status=paid

Akibatnya, status pengguna gratis berubah menjadi pengguna berbayar.

Menurut naskah soal, layanan L tidak memverifikasi parameter yang diterima, lalu meneruskan semuanya ke modul bersama P. P dibuat agar dapat memperbarui basis data apa adanya.

Jawaban isian c adalah modul bersama P.

flowchart TB
    accTitle: Mass Assignment
    accDescr: status=paid di luar spesifikasi ditambahkan dan diterapkan utuh ke objek internal
    A[Spesifikasi API<br/>mid / name / age] -->|penyerang menambah status=paid| B[Body permintaan]
    B -->|ikatan otomatis| C[Modul bersama P]
    C -->|simpan DB| D[Status penagihan berubah jadi paid]

Gambar 7: Mass Assignment. Properti di luar spesifikasi diterapkan utuh ke objek internal.

Perbedaan dengan BOLA

Penukaran mid di bab sebelumnya dan penambahan status kali ini mirip, tetapi granularitas yang dilindungi berbeda.

OWASP API Security Top 10 2023 menempatkan yang terakhir sebagai Broken Object Property Level Authorization, dan memasukkan Mass Assignment sebelumnya ke klasifikasi ini.⁸

Bahaya “memasukkan JSON apa adanya ke entitas”

Implementasi yang rentan, secara konseptual, seperti berikut.

entity = repository.find(body.mid)
bindAllProperties(entity, body)
repository.save(entity)

Meski layar hanya punya kolom name dan age, penyerang dapat membuat permintaan HTTP secara langsung. Item yang tidak ada di UI bukan batas keamanan.

Implementasi yang aman menyatakan secara eksplisit item yang boleh diperbarui.

input = parseExactSchema(body, fields = ["name", "age"])

entity = repository.find(authenticatedUserId)
entity.name = input.name
entity.age  = input.age
repository.save(entity)

Di sini ada dua hal penting.

1. Pada tipe masukan pembaruan, letakkan hanya item yang boleh diubah pengguna
2. Item tidak dikenal di luar spesifikasi jangan diabaikan; sebisa mungkin ditolak sebagai galat

Mengabaikan item tidak dikenal secara diam-diam dapat menyembunyikan bahwa serangan gagal, tetapi juga membuat kelalaian implementasi klien dan tanda serangan terlewat. Jika tidak ada alasan kompatibilitas, menolak dengan skema ketat lebih mudah diselidiki.

flowchart TB
    accTitle: Otorisasi tingkat item
    accDescr: DTO pembaruan hanya memegang daftar izinkan, dan properti tidak dikenal ditolak
    subgraph "DTO pembaruan (daftar izinkan)"
        D1["name"]
        D2["age"]
    end
    A[Body permintaan] -->|validasi skema| B{hanya item<br/>yang diizinkan?}
    B -->|ya| C[Perbarui name/age entitas]
    B -->|tidak| D[Kembalikan galat]
    E[Layanan pembayaran<br/>notifikasi terverifikasi] -->|jalur khusus| F[Perbarui status=paid]

Gambar 8: Otorisasi tingkat item. Batasi item yang boleh diperbarui dengan daftar izinkan, dan ubah status penagihan lewat jalur lain.

status hanya diubah dari hasil pembayaran

status=paid bukan bagian profil pengguna. Itu keadaan yang diturunkan dari fakta sisi server bahwa pembayaran berhasil.

pembaruan profil pengguna
  -> hanya name / age yang boleh diubah

notifikasi terverifikasi dari layanan pembayaran
  -> cocokkan paymentId
  -> cegah pemrosesan ganda
  -> ubah status menjadi paid

Meski disimpan di kolom basis data yang sama, wewenang dan jalur perubahan terpisah. Jika entitas internal dipakai apa adanya sebagai tipe masukan API eksternal, batas ini hilang.

9. Soal 2(5) — tindakan brute-force adalah memegang jumlah kegagalan sebagai keadaan

Terhadap brute-force kode 4 digit, jawab pemrosesan yang masuk ke isian d pada tabel 5 dalam 30 karakter atau kurang. Ambangnya adalah 10.

Contoh jawabannya sebagai berikut.

Pemrosesan yang mengunci akun jika jumlah kegagalan beruntun melebihi ambang

Ini tidak bertentangan dengan stateless pada soal 1. Tidak memegang keadaan percakapan pemanggilan API sebagai sesi server, dan mengekalkan jumlah kegagalan yang diperlukan untuk keputusan keamanan, adalah hal yang berbeda.

flowchart LR
    accTitle: Ada atau tidaknya batas jumlah percobaan
    accDescr: Tanpa batas, tembus rata-rata dalam 500 detik; batas jumlah kegagalan menekan kecepatan serangan
    subgraph "Tanpa batas"
        A1[10 percobaan per detik] -->|sekitar 500 detik| B1[Autentikasi berhasil]
    end
    subgraph "Ada batas"
        A2[Kunci setelah 10 kegagalan] -->|kecepatan serangan jatuh tajam| B2[Akun terkunci]
        C2[Penundaan bertahap] --> B2
    end

Gambar 10: Ada atau tidaknya batas jumlah. Batas jumlah kegagalan membuat brute-force praktis terhenti.

Dalam praktik, jangan hanya “kunci permanen”

Batas jumlah per akun diperlukan, tetapi jika penyerang mengetahui ID pengguna orang lain, 10 kegagalan sengaja dapat mengunci pengguna sah. Karena itu, dalam praktik gabungkan hal berikut.

Selain itu, jangan mengembalikan jumlah kegagalan ke 0 saat kode dikirim ulang. Jika tidak, setiap kali penyerang memanggil API kirim ulang, kuota percobaan hidup kembali. NIST SP 800-63B yang berlaku juga menuntut agar jumlah kegagalan tidak direset meski rahasia autentikasi baru dibuat.⁴

Buat kode autentikasi hanya dapat dipakai sekali

Dalam naskah soal, yang menjadi pusat adalah masa berlaku, tetapi dalam praktik hal berikut juga diperlukan.

• Invalidasi segera kode yang berhasil
• Tolak pemakaian ulang kode yang sama
• Jangan menyisakan kode itu sendiri di log
• Buat respons yang tidak memungkinkan menebak ada tidaknya pengguna dari berhasil/gagalnya pencocokan kode
• Pasang juga batas jumlah pada API pengiriman kode

Selama rahasia pendek dipakai, keamanan tidak bisa diserahkan hanya pada pembangkitan acak.

flowchart TB
    accTitle: Tindakan kode autentikasi
    accDescr: Selain jumlah digit dan waktu kedaluwarsa, lindungi dengan batas percobaan, tolak pemakaian ulang, notifikasi, dan sejenisnya
    A[Kode autentikasi] --> B[Tambah jumlah digit]
    A --> C[Perpendek masa berlaku]
    A --> D[Batas jumlah percobaan]
    A --> E[Invalidasi setelah berhasil]
    A --> F[Jangan reset jumlah kegagalan saat kirim ulang]
    A --> G[Jangan sisakan kode di log]
    A --> H[Pengendalian per sumber]

Gambar 11: Tindakan kode autentikasi. Gabungkan pengendalian percobaan dan operasional, bukan hanya jumlah digit dan waktu kedaluwarsa.

10. Membedakan empat butir soal 2 dalam satu lembar

Argumen yang mudah tertukar pada soal 2 disusun menurut nilai yang dikendalikan penyerang.

Penting untuk tidak merangkum semuanya sebagai “validasi nilai masukan”.

• alg adalah kebijakan pemrosesan kriptografi
• mid adalah otorisasi tingkat objek
• status adalah otorisasi tingkat properti
• otp adalah ketahanan terhadap tebakan daring

Meski ada dalam permintaan HTTP yang sama, alasan melindunginya berbeda.

11. Soal 3(1) — mengonfirmasi eksekusi kode eksternal tanpa merusak

Setelah layanan dimulai, kerentanan serius V diumumkan pada pustaka sumber terbuka H yang dipakai luas. Alur naskah soal sebagai berikut.

1. Penyerang mengirim string yang berisi JNDI Lookup di header HTTP
2. Server sasaran menuliskan nilai itu ke log
3. Pustaka yang rentan mengevaluasi JNDI Lookup dan menanyakan server LDAP penyerang
4. Respons LDAP mengembalikan URL server HTTP penyerang
5. Server sasaran mengambil berkas kelas dan mengeksekusi perintah

Ini dapat dibaca sebagai serangan tipe Log4Shell (CVE-2021-44228) dengan nama produk disembunyikan. Penjelasan Apache juga menyebutnya kerentanan yang, jika penyerang dapat mengendalikan pesan log atau parameter, memungkinkan eksekusi kode sembarang yang dimuat dari server LDAP.⁹

flowchart LR
    accTitle: Alur konfirmasi kerentanan tipe Log4Shell
    accDescr: Mengonfirmasi apakah rantai dari JNDI sampai eksekusi kode eksternal tembus dengan callback yang tidak merusak
    A[Penyerang] -->|suntik jndi:ldap://...<br/>ke x-api-version| B[Server yang rentan]
    B --> C[Pemrosesan log]
    C -->|JNDI Lookup| D[Server LDAP yang disalahgunakan]
    D -->|respons URL HTTP| E[Server HTTP yang disalahgunakan<br/>index.html]
    E -->|catat GET| F[Log akses<br/>server uji]
    F -->|konfirmasi sampai| G[Konfirmasi kerentanan]

Gambar 12: Alur konfirmasi kerentanan tipe Log4Shell. Bukan perintah merusak, melainkan konfirmasi sampai lewat catatan akses HTTP.

Kode verifikasi hanya memicu akses HTTP yang tidak merusak

Perusahaan G menjalankan kode verifikasi yang tidak memengaruhi sistem, untuk mengonfirmasi apakah kerentanan V dapat disalahgunakan dari luar. Perintah yang dilakukan kode verifikasi hanyalah mengambil index.html pada server uji.

Soal 3(1) menanyakan apa yang harus diimplementasikan pada server uji agar dapat dikonfirmasi bahwa perintah telah dieksekusi.

Contoh jawabannya sebagai berikut.

Mekanisme yang mencatat dan mengonfirmasi akses ke index.html pada server uji

Jika GET dari server sasaran tersisa di log akses server web, setidaknya rantai berikut dapat dikonfirmasi sudah tembus.

permintaan HTTP eksternal
  -> pemrosesan log
  -> JNDI Lookup
  -> respons LDAP
  -> pengambilan kelas
  -> eksekusi perintah verifikasi
  -> akses HTTP ke server uji

Mengapa “menampilkan teks di layar” tidak cukup

Sasarannya adalah server. Perubahan pada layar peramban pengguna tidak selalu muncul. Selain itu, meski kerentanan ada, komunikasi keluar di tengah jalan dapat terhenti di firewall.

Mencatat akses di sisi server uji menjadi bukti yang dapat diamati bahwa server sasaran mencapai luar.

Ketika verifikasi sejenis dilakukan dalam praktik, selalu patuhi hal berikut.

• Dapatkan persetujuan eksplisit dari pemilik sistem sasaran
• Jadikan metode verifikasi yang tidak memengaruhi produksi, atau yang dampaknya dapat diterima
• Jangan memakai perintah merusak seperti tulis, hapus, atau ubah konfigurasi
• Kelola domain dan server verifikasi di perusahaan sendiri
• Catat waktu verifikasi, sumber, sasaran, dan callback yang diharapkan
• Setelah verifikasi, cabut server LDAP/HTTP sementara dan kredensial

“Mengonfirmasi eksekusi kode sembarang” dan “mengeksekusi kode berbahaya sembarang” tidak sama. Jadikan efek samping seminimal mungkin yang memenuhi tujuan.

12. Soal 3(2)(3) — WAF memeriksa header HTTP

WAF layanan N dapat memilih sasaran pemeriksaan GET, POST, PUT, ANY, Header, COOKIE, Multipart.

Kode serangan masuk ke nilai header HTTP bernama x-api-version. Karena itu, isian e dan f pada tabel 6 keduanya Header.

Pasangkan tempat yang tertulis di naskah langsung ke sasaran pemeriksaan WAF

Ini soal membaca alur data naskah, bukan pengetahuan umum.

tempat string serangan:
  header x-api-version
          |
          v
sasaran pemeriksaan WAF:
  Header

Bukan parameter GET maupun body POST. Jangan melihat daftar kemampuan WAF lalu memilih “ANY karena terasa seperti serangan”; jawab tempat penyerang memasukkan nilai dalam naskah soal.

Menangani pertukaran huruf besar dan kecil

Rancangan awal, secara konseptual, adalah aturan berikut.

Header  \Wjndi\W  blokir
Header  \Wldap\W  blokir

Namun, menukar huruf besar/kecil seperti jNdI dapat menghindari pola huruf kecil saja.

Contoh jawaban soal 3(3) adalah salah satu dari berikut.

\W[jJ][nN][dD][iI]\W

\W(j|J)(n|N)(d|D)(i|I)\W

Pada buku soal, backslash kadang tampak seperti tanda yen pada bentuk huruf lingkungan Jepang, tetapi sebagai regex itu \W. \W cocok dengan karakter selain alfanumerik dan garis bawah. Pada sintaksis JNDI Lookup, karakter non-kata seperti ${ atau : muncul sebelum dan sesudah jndi, jadi itu ikut dilihat.

Dengan cara pikir yang sama, sisi ldap juga dapat diubah agar mengabaikan huruf besar/kecil.

\W[lL][dD][aA][pP]\W

Jangan menganggap regex ini “tindakan Log4Shell yang lengkap”

Ujian meminta regex yang menangani cara penghindaran yang ditunjukkan naskah. Dalam serangan nyata, pemisahan string, Lookup lain, pengodean, protokol lain, dan sejenisnya dapat muncul dalam bentuk yang sulit diliput hanya dengan tanda tangan.

Karena itu, posisi dalam praktik adalah sebagai berikut.

1. Hentikan sementara pola serangan yang sudah diketahui dengan WAF
2. Periksa apakah pustaka yang terdampak benar-benar termasuk
3. Batasi komunikasi LDAP, RMI, dan HTTP keluar yang tidak perlu
4. Perbarui ke versi perbaikan
5. Setelah pembaruan, periksa log dan selidiki ada tidaknya pelanggaran

WAF adalah lapisan untuk membeli waktu sampai versi perbaikan terbit.

flowchart TB
    accTitle: Posisi WAF
    accDescr: WAF adalah lapisan mitigasi sementara; tindakan akar adalah memperbarui pustaka ke versi perbaikan
    A[Pengumuman kerentanan serius] --> B[Konfirmasi dampak]
    B --> C[Mitigasi sementara]
    C -->|aturan WAF<br/>deteksi/pemblokiran| D[Hentikan sementara pola serangan]
    C -->|batas komunikasi keluar| E[Tutup jalur penyalahgunaan]
    D --> F[Perbarui ke pustaka versi perbaikan]
    E --> F
    F --> G[Konfirmasi pasca-insiden dan pencegahan berulang]

Gambar 13: Posisi WAF. WAF membeli waktu sampai versi perbaikan terbit; tindakan akar adalah pembaruan.

13. Soal 3(4) — alasan memakai “deteksi” lebih dulu

Tentang aturan WAF setelah perubahan, Z, spesialis keamanan terdaftar, menyarankan agar selama jangka waktu tertentu setelah operasi produksi dimulai, operasi diatur ke “deteksi” bukan “pemblokiran”.

Soal menanyakan keuntungan mengatur ke deteksi, dan isi yang harus dilakukan untuk meminimalkan kerugian, masing-masing dalam 25 karakter atau kurang.

Contoh jawaban sebagai berikut.

Mode deteksi bukan “mode tidak berbuat apa-apa”

Pada mode deteksi, komunikasi yang cocok dengan aturan tetap dilewatkan, sambil dicatat ke log dan mengeluarkan peringatan. Meski string jndi atau ldap kebetulan masuk ke pemanggilan API yang sah, bisnis tidak langsung dihentikan.

Sebagai gantinya, sisi operasi memerlukan hal berikut.

peringatan diterima
   |
   v
konfirmasi permintaan sasaran
   |
   +-- komunikasi sah -> persempit aturan, pertimbangkan syarat pengecualian
   |
   +-- serangan     -> isolasi sasaran, amankan log, selidiki dampak, ke pemblokiran

Jika tidak ada yang melihat peringatan, mode deteksi tidak punya efek pertahanan. Deteksi adalah satu paket dengan operasi mengamati lalu memutuskan.

Alur pindah dari deteksi ke pemblokiran

Langkah pengenalan umum sebagai berikut.

1. Terapkan ke lalu lintas nyata dalam mode deteksi
2. Klasifikasikan deteksi keliru dan deteksi benar
3. Sesuaikan header sasaran, jalur, API, batas karakter, dan sejenisnya
4. Konfirmasi bahwa dampak pada komunikasi sah dapat diterima
5. Pindah ke mode pemblokiran
6. Pantau jumlah pemblokiran dan dampak bisnis

Namun, ini prinsip pada masa damai. Jika kerentanannya serius, sedang disalahgunakan, dan tidak ada sarana pengganti, ada juga keputusan untuk memblokir dari awal karena kerugian pelanggaran dinilai lebih besar daripada henti akibat deteksi keliru. Dalam situasi ujian, deteksi dipilih lebih dulu untuk mengonfirmasi apakah layanan dapat dipakai seperti sebelumnya.

flowchart LR
    accTitle: Dari deteksi WAF ke pemblokiran
    accDescr: Amati peringatan pada mode deteksi, sesuaikan deteksi keliru, lalu pindah ke mode pemblokiran
    A[Mode deteksi] -->|lalu lintas nyata| B[Peringatan terjadi]
    B --> C{serangan atau<br/>deteksi keliru?}
    C -->|deteksi keliru| D[Sesuaikan aturan]
    D --> A
    C -->|serangan| E[Ke mode pemblokiran]
    E --> F[Pantau jumlah pemblokiran dan dampak bisnis]

Gambar 14: Dari deteksi ke pemblokiran. Amati dan sesuaikan lebih dulu, konfirmasi dampak dapat diterima, lalu pindah ke pemblokiran.

14. WAF adalah tindakan sementara, pembaruan adalah tindakan akar

Dalam naskah soal, situs resmi pustaka H belum punya versi perbaikan maupun tindakan sementara, dan aturan WAF menyeluruh dari penyedia cloud memakan waktu hingga 72 jam. Karena itu perusahaan G sendiri mengonfirmasi dampak, dan setidaknya menahan sementara pola yang sudah diketahui.

Urutan ini adalah bentuk dasar penanganan insiden.

“Tidak tahu apakah dipakai” menjadi penundaan terbesar

Dalam naskah soal, meski perusahaan G menanyakan perusahaan F apakah pustaka H dipakai, analisis konfigurasi rinci diperlukan sehingga jawaban memakan waktu.

Dalam praktik, jika pencarian berkas JAR baru dimulai setelah pengumuman kerentanan serius, penanganan terlambat. Setidaknya hal berikut harus dimiliki sejak masa damai.

• Daftar dependensi langsung dan transitif
• Komponen dan versi yang benar-benar termasuk dalam artefak distribusi
• Layanan, kontainer, atau perangkat mana yang dideploy
• Prosedur memperbarui pustaka dependen lalu membangun dan mendistribusikan ulang
• Jalur kontak untuk menyetujui perubahan darurat
• Tujuan komunikasi keluar yang diizinkan, dan dampak jika dihentikan
• Tempat penyimpanan log dan cara pencarian

SBOM bukan tujuan. Itu indeks untuk menjawab dalam waktu singkat: kerentanan ini memengaruhi sistem berjalan yang mana.

Jangan mengakhiri penyelidikan hanya karena sudah diperbarui

Ada kemungkinan serangan sudah terjadi sebelum dan sesudah pengumuman kerentanan. Memperbarui ke versi perbaikan menghentikan penyalahgunaan ke depan, tetapi kredensial yang sudah dilanggar atau backdoor yang dipasang tidak hilang.

Untuk tipe Log4Shell, setidaknya selidiki sudut pandang berikut.

• Permintaan HTTP yang berisi string mencurigakan yang menunjukkan JNDI atau LDAP
• Komunikasi dari server aplikasi ke LDAP, RMI, HTTP eksternal
• Peluncuran proses anak yang tidak biasa
• Pembuatan JAR, class, skrip, atau berkas eksekusi yang mencurigakan
• Akses ke kredensial cloud atau variabel lingkungan
• Perubahan autentikasi/wewenang dan pengiriman ke luar sebelum dan sesudah pembaruan

Penting untuk tidak menyatakan “tidak diserang” hanya dari log WAF. Ada jalur internal yang tidak lewat WAF, dan log yang tidak tersimpan di masa lalu.

15. Cara membaca agar lebih mudah mendapat nilai di ujian

Soal ini lebih merupakan soal membaca selisih spesifikasi dan implementasi, bukan soal pengetahuan.

15.1 Pisahkan “spesifikasi” dan “implementasi” pada tabel

Pada masalah status, nilai yang tidak ada di spesifikasi API lolos di implementasi.

spesifikasi:
  mid / name / age

implementasi:
  semua parameter yang diterima dikirim ke P

Jika selisih ini terlihat, isian c terlihat sebagai modul bersama P.

15.2 Garis bawahi nilai yang diubah penyerang

Nilai yang diubah pada tiap serangan adalah sebagai berikut.

• alg pada header JWT
• ID pengguna pada payload JWT
• mid pada parameter API
• status di luar spesifikasi
• otp pada API autentikasi
• x-api-version pada header HTTP

Hampir semua soal menanyakan “di mana nilai itu seharusnya diverifikasi”.

15.3 Kembalikan jawaban ke istilah naskah soal

Dalam praktik boleh menyebut “BOLA”, “Mass Assignment”, “rate limiting”. Namun yang diminta soal adalah pemrosesan konkret yang selaras dengan susunan naskah.

Contoh buruk:

Melakukan otorisasi dengan tepat.

Contoh baik:

Memverifikasi apakah ID pengguna di dalam JWT cocok dengan nilai mid.

Contoh buruk:

Melakukan tindakan brute-force.

Contoh baik:

Mengunci akun jika jumlah kegagalan beruntun melebihi ambang.

Hanya mengetahui nama abstrak tidak menjadi jawaban yang dapat dinilai dalam batas karakter.

15.4 WAF: telusuri “ke mana dimasukkan”

Sasaran pemeriksaan WAF ditentukan dari tempat penyimpanan string serangan, bukan ditebak dari jenis serangan.

dimasukkan ke header x-api-version
        ↓
sasaran pemeriksaan adalah Header

Tingkat jawaban benar soal 3(1) agak rendah di komentar penilaian juga karena banyak jawaban yang tidak cocok dengan alur serangan pada gambar 6. Hanya menulis ulang prosedur serangan dengan panah sudah membuat terlihat apa yang harus diamati.

16. Daftar periksa yang dapat dipakai pada tinjauan API praktis

Daftar periksa untuk membawa soal ini ke tinjauan rancangan dan kode yang nyata.

Verifikasi JWT

• Algoritme tanda tangan yang diizinkan ditetapkan di konfigurasi server
• none dan algoritme di luar harapan ditolak
• Tanda tangan, iss, aud, exp, nbf diverifikasi sesuai penggunaan
• ID token, access token, dan refresh token tidak tertukar
• Ada prosedur rotasi kunci dan pencabutan
• Informasi yang harus dirahasiakan tidak dimasukkan ke payload JWT

Otorisasi tingkat objek

• Mengubah ID dalam permintaan tidak sampai ke data orang lain
• Otorisasi dilakukan pada daftar, rincian, pembaruan, penghapusan, dan unduhan
• Otorisasi dilaksanakan di lapisan bersama yang mencapai data, bukan di layar
• Pada API khusus diri sendiri, sudah dipertimbangkan apakah ID sasaran dapat diturunkan dari token
• Operasi administrator dipisah kebijakannya dari API pengguna umum

Otorisasi tingkat properti

• Tipe masukan eksternal dan entitas basis data dipisah
• Item yang boleh diperbarui dienumerasi dengan daftar izinkan
• Properti di luar spesifikasi ditolak atau diaudit
• Keadaan seperti wewenang, penagihan, persetujuan, pemilik tidak dapat diubah dari masukan pengguna
• Respons tidak menyertakan properti rahasia yang tidak perlu

Percobaan autentikasi

• Ada batas jumlah kegagalan per akun
• Ada penundaan bertahap atau pengendalian per sumber
• Jumlah kegagalan tidak direset saat kode diterbitkan ulang
• Kode autentikasi hanya dapat dipakai sekali
• Kode autentikasi atau kata sandi tidak disisakan di log
• Prosedur buka kunci dan pemulihan tidak menjadi jalur autentikasi lemah lain

Kerentanan pustaka dependen yang serius

• Layanan yang berjalan dapat dipasangkan dengan versi dependen
• Ada prosedur memverifikasi dampak dengan cara yang tidak merusak
• Tindakan sementara seperti WAF atau batas komunikasi keluar dapat diterapkan
• Ada operasi petugas yang mengonfirmasi peringatan deteksi
• Ada jalur rilis darurat untuk memperbarui ke versi perbaikan
• Kemungkinan penyalahgunaan sebelum pembaruan diselidiki dari log

17. Dua sisi komponen bersama yang terlihat dari soal ini

Dalam soal ini muncul dua komponen bersama: pustaka pengelolaan JWT Q dan modul bersama P.

Komponen bersama punya keuntungan besar.

• Memperbaiki satu tempat dapat menerapkan perbaikan ke semua API yang memakainya
• Implementasi otorisasi dan verifikasi tidak perlu diduplikasi ke tiap fitur
• Sasaran pengujian dapat dikumpulkan
• Format log dan audit dapat diseragamkan

Di sisi lain, kesalahan juga menyebar ke seluruhnya.

• Jika pustaka Q menerima alg=none, semua API yang memakai JWT menjadi berbahaya
• Jika modul bersama P menerima mid atau status sembarang, GET dan PUT keduanya menjadi berbahaya
• Jika pustaka H yang rentan dipakai di fondasi, beberapa jalur yang menuliskan header HTTP ke log menjadi permukaan serangan

Karena itu, yang harus dikumpulkan bukan sekadar akses data. Kumpulkan invarians keamanan, dan verifikasi komponen bersama itu secara ketat secara terpisah.

Misalnya, buat kontrak P sebagai berikut.

P.getOwnUser(authenticatedSubject)
P.updateOwnProfile(authenticatedSubject, ProfileUpdate{name, age})

Lebih aman untuk tidak mengekspos API tingkat rendah seperti berikut apa adanya ke pemanggil umum.

P.getUser(arbitraryMid)
P.updateUser(arbitraryMap)

Yang terakhir hanya diperlukan pada jalur terbatas seperti pemrosesan administratif. Jika kebebasan tingkat rendah dibagikan ke semua API, rancangannya mengharapkan tiap pemanggil memakainya dengan benar setiap kali.

18. Ringkasan

Soal 1 sesi sore musim semi tahun anggaran Reiwa 6 adalah soal yang membaca topik keamanan API dengan memisahkannya satu per satu.

Memakai JWT tidak berarti autentikasi yang aman. Jika algoritme tanda tangan dibiarkan dipilih penyerang, ID pengguna dapat ditulis ulang.

Tanda tangan JWT yang benar tidak berarti otorisasi yang benar. Jika mid permintaan dipercaya, pengguna sah dapat mengakses informasi orang lain.

Bisa memperbarui objek sendiri tidak berarti semua properti boleh diubah. Jika keadaan internal seperti status diikat otomatis, wewenang atau status penagihan dapat ditulis ulang.

Adanya masa berlaku pada kode autentikasi tidak berarti tahan brute-force. Hitung jumlah kandidat dan kecepatan percobaan, lalu batasi jumlah kegagalan.

Memasukkan aturan ke WAF tidak berarti kerentanan sudah diperbaiki. Beli waktu dengan deteksi dan pemblokiran, konfirmasi dampak, dan pada akhirnya perbarui pustaka.

flowchart TB
    accTitle: Tabel korespondensi kerentanan dan tindakan
    accDescr: Memasangkan tiap kerentanan dengan batas kepercayaan dan tindakannya
    A[Pemalsuan JWT] -->|verifikasi token| B[Tetapkan algoritme yang diizinkan]
    C[Penukaran mid] -->|otorisasi tingkat objek| D[Cocokkan subjek JWT / mid tidak perlu]
    E[status=paid] -->|otorisasi tingkat properti| F[Jadikan DTO pembaruan daftar izinkan]
    G[Brute-force kode 4 digit] -->|pengendalian percobaan autentikasi| H[Batas jumlah kegagalan / penundaan]
    I[Kerentanan tipe Log4Shell] -->|dari masukan ke eksekusi| J[Pembaruan pustaka / WAF]

Gambar 15: Tabel korespondensi kerentanan dan tindakan. Pisahkan tindakan menurut batas yang dilanggar.

Prinsip yang menembus soal ini hanya satu.

Jangan menjadikan keberhasilan verifikasi sebelumnya sebagai alasan untuk melewatkan batas kepercayaan berikutnya.

Artikel sebelumnya dalam seri ini membahas XSS tersimpan pada soal 1 sesi sore musim gugur Reiwa 5 dan pembawaan informasi dari Wi-Fi tamu pada soal 2 sesi sore musim gugur Reiwa 5. Untuk sudut pandang konfirmasi seluruh situs web, lihat juga Memakai “Cara membuat situs web yang aman” IPA sebagai daftar periksa.

flowchart TB
    accTitle: Ringkasan akhir
    accDescr: Menunjukkan bahwa keberhasilan verifikasi sebelumnya tidak boleh menjadi alasan untuk melewatkan batas kepercayaan berikutnya
    A[Autentikasi berhasil] --> B[Verifikasi tanda tangan JWT]
    B --> C[Otorisasi tingkat objek]
    C --> D[Otorisasi tingkat properti]
    D --> E[Batas jumlah percobaan]
    E --> F[Batas dari masukan ke eksekusi]
    F --> G[WAF / pembaruan pustaka]

Gambar 16: Ringkasan akhir. Batas kepercayaan dikonfirmasi bertahap, dan tidak satu pun boleh dilewatkan.

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Mengapa bisa menyamar sebagai orang lain padahal verifikasi tanda tangan JWT berhasil?

Dalam soal ini, pustaka pengelolaan JWT menerima alg pada header JWT persis seperti yang ditentukan penyerang, dan memperlakukan JWT dengan alg=none sebagai sah tanpa tanda tangan. Karena itu, menulis ulang ID pengguna di payload tetap lolos verifikasi. Jawaban ujian: objek verifikasi adalah alg pada header JWT, dan isinya adalah memastikan nilainya bukan NONE. Namun dalam praktik, menolak hanya NONE tidak cukup. Di konfigurasi sisi server, tetapkan algoritme yang diizinkan — misalnya RS256 — dan jangan memakai algoritme yang dideklarasikan token untuk memilih metode verifikasi. Selain itu, verifikasi juga issuer, audience, masa berlaku, subject, dan klaim lain sesuai penggunaan.

Apakah membandingkan ID pengguna di dalam JWT dengan mid permintaan sudah cukup sebagai tindakan otorisasi?

Sebagai jawaban soal ini, itu cukup. Jika modul bersama P memverifikasi bahwa ID pengguna di JWT cocok dengan mid, serangan yang menyebutkan mid orang lain dapat dihentikan. Namun, untuk API yang hanya menangani informasi diri sendiri, lebih aman dalam praktik untuk tidak menerima mid dari klien sama sekali, dan menentukan ID pengguna dari subject JWT yang sudah diverifikasi. Misalnya GET /users/me atau PUT /users/me membuat kelalaian implementasi perbandingan itu sendiri lebih sulit terjadi. API tempat administrator mengoperasikan pengguna lain dipisah ke endpoint dan kebijakan otorisasi tersendiri.

Mengapa serangan yang menambahkan status tidak bisa dicegah hanya dengan validasi nilai masukan biasa?

Karena meski panjang name atau rentang age divalidasi, itu tidak menolong jika status — yang seharusnya tidak diterima — diikat otomatis dan diteruskan ke objek internal. Masalahnya bukan format nilai, melainkan otorisasi tingkat properti: apakah pengguna boleh mengubah properti itu. Pada tipe masukan untuk pembaruan, definisikan hanya name dan age, dan tolak properti yang tidak dikenal. Status penagihan hanya boleh diubah dari peristiwa yang dipercaya server, misalnya hasil sukses dari layanan pembayaran.

Kode autentikasi 4 digit kedaluwarsa dalam 10 menit. Mengapa tetap berbahaya?

Karena kandidat dari 0000 sampai 9999 hanya 10.000, dan jika 10 percobaan per detik, rata-rata 5.000 percobaan — yaitu 500 detik — sudah cukup untuk mengenai. Masa berlaku 10 menit adalah 600 detik, jadi jika kandidat tanpa duplikat dicoba berurutan, 6.000 kandidat dapat diperiksa dalam masa berlaku. Waktu kedaluwarsa saja tidak menghentikan brute-force. Jumlah kandidat, kecepatan percobaan, dan batas jumlah percobaan harus dirancang bersama.

Tindakan pada soal adalah penguncian akun. Apakah dalam praktik cukup mengunci segera saja?

Tidak. Isian soal diisi dengan pemrosesan yang mengunci akun jika jumlah kegagalan beruntun melebihi ambang, tetapi kunci tetap yang permanen saja memungkinkan penyerang sengaja mengunci akun orang lain sebagai gangguan layanan. Dalam praktik, gabungkan hitungan kegagalan per akun, waktu tunggu bertahap, penilaian risiko sumber dan perangkat, notifikasi, dan prosedur pemulihan. Penting juga untuk tidak mengembalikan hitungan kegagalan ke nol saat kode baru diterbitkan.

Apa artinya mengatur WAF ke deteksi, bukan pemblokiran?

Artinya, meski string yang sah keliru dinilai sebagai serangan, komunikasi bisnis tidak perlu dihentikan. Dalam jawaban soal, keuntungannya adalah dapat mencegah pemblokiran akibat deteksi keliru, dan yang harus dilakukan adalah menelaah apakah itu serangan setelah peringatan diterima. Mode deteksi bukan pengaturan untuk dibiarkan. Mode ini dipakai sebagai masa observasi: memeriksa log, membuang deteksi keliru, menyesuaikan aturan, lalu pindah ke pemblokiran. Dalam keadaan darurat ketika kerentanan serius yang sudah diketahui sedang disalahgunakan, ada juga keputusan untuk memblokir lebih dulu setelah membandingkan dengan risiko ketersediaan.

Apakah pustaka H dalam soal ini Log4j?

Naskah soal menyembunyikan nama produk, tetapi alur serangan — JNDI Lookup, server LDAP, pengambilan kelas dari server HTTP, string yang disematkan di header HTTP, dan skor dasar CVSS v3.1 yang tinggi — secara alami dibaca sebagai abstraksi CVE-2021-44228 yang dikenal sebagai Log4Shell. Artikel ini menjelaskan korespondensi itu, tetapi ujian tidak mensyaratkan nama produk. Jawaban dapat disusun dari prosedur serangan dan spesifikasi WAF yang diberikan.

Apa yang harus dibawa ke praktik dari soal ini?

Bahwa autentikasi berhasil, JWT tidak diubah, objek sasaran boleh diakses, dan properti sasaran boleh diubah adalah pemeriksaan yang terpisah. Selain itu, kode autentikasi pendek memerlukan batas jumlah percobaan, dan pada kerentanan pustaka yang serius, konfirmasi dampak, pertahanan sementara, dan perbaikan akar dijalankan secara paralel. Inti praktisnya: mengumpulkan otorisasi ke komponen bersama, menjadikan skema masukan sebagai daftar izinkan, menetapkan syarat verifikasi JWT di sisi server, dan menjaga pustaka dependen dalam keadaan yang dapat diperbarui.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.