Kontrol Akses dan Request Server Side

Empat catatan pada halaman ini berbagi satu pola: server memakai nilai yang dikirim klien untuk menentukan sesuatu di sisi server. Pada IDOR nilai itu adalah identitas objek (id, user_id). Pada SSRF nilai itu adalah tujuan request (urlApi, url). Pada Host Header Injection nilai itu adalah header Host. Pada Mass Assignment nilai itu adalah nama field yang ikut dibaca dari body request. Insecure Direct Object References.md:3-8¹ Server Side Request Forgery.md:3-7² Host Header Injection.md:3-7³ Mass Assignment.md:3-4⁴

Satu pola, empat titik masuk

Diagram berikut memetakan nilai klien yang muncul di catatan ke keputusan server yang dipengaruhinya. Setiap label memakai endpoint dan parameter yang tertulis apa adanya di berkas rujukan.

graph TD
  IDOR["id dan user_id pada /api/get_profile"] --> APP["Aplikasi memproses nilai klien"]
  SSRF["urlApi dan url pada /api/check/products dan /image"] --> APP
  HHI["Host dan X-Forwarded-Host pada /reset"] --> APP
  MA["admin pada /editdata"] --> APP
  APP --> D1["data user lain terbaca atau berubah"]
  APP --> D2["request keluar menuju 192.168.1.1"]
  APP --> D3["tautan email berisi evil-website.com"]
  APP --> D4["isAdmin berubah menjadi true"]
  style IDOR fill:#f59e0b,color:#000
  style SSRF fill:#f59e0b,color:#000
  style HHI fill:#f59e0b,color:#000
  style MA fill:#f59e0b,color:#000
  style APP fill:#8b5cf6,color:#fff
  style D1 fill:#dc2626,color:#fff
  style D2 fill:#dc2626,color:#fff
  style D3 fill:#dc2626,color:#fff
  style D4 fill:#dc2626,color:#fff
%% fig: Nilai klien yang menentukan keputusan server
%% desc: Empat parameter dari catatan masuk ke jalur pemrosesan yang sama, lalu menghasilkan empat dampak berbeda.

Node oranye adalah input yang datang dari klien, node ungu adalah titik pemrosesan di server, dan node merah adalah dampak yang dicatat berkas rujukan.

IDOR: identitas objek yang mudah ditebak

IDOR membuat satu user dapat mengakses atau mengubah data user lain di sistem. Catatan menyarankan dua tempat pencarian: API, dan request yang memuat ID unik seperti user_id atau id Insecure Direct Object References.md:3-8¹. Seluruh varian di bawah bertolak dari endpoint yang sama, yaitu POST /api/get_profile atau GET /api/v1/getuser, lalu mengubah cara identitas objek dikirim.

Baris 10, 12, dan 15 mengubah bentuk request, bukan identitas objeknya, sehingga bersinggungan dengan halaman Teknik Bypass Kontrol. Baris 16 mengarah ke pencarian endpoint, yang dibahas di Reconnaissance dan Pemetaan Scope.

⚠️ Baris 5 dan 6 memakai nama field berbeda dari permintaan normal (id menggantikan user_id). Controller yang membaca id dan controller yang membaca user_id bisa memakai pemeriksaan akses yang berbeda, jadi keduanya perlu dicoba terpisah.

SSRF: memaksa server mengirim request internal

SSRF adalah kerentanan aplikasi web yang memungkinkan penyerang membuat request keluar yang berasal dari server yang rentan Server Side Request Forgery.md:3-4²¹. Titik temunya adalah request yang memuat URL lain. Catatan memberi dua contoh: urlApi=http://192.168.1.1%2fapi%2f&id=1 pada POST /api/check/products, dan GET /image?url=http://192.168.1.1/ Server Side Request Forgery.md:6-23²².

Perhatikan %2f pada urlApi. Path API internal ikut di-encode di dalam nilai parameter, sehingga penyerang mengirim tujuan lengkap sebagai satu nilai, bukan sebagai path request. Urutan kejadiannya digambarkan diagram berikut.

sequenceDiagram
  autonumber
  participant K as Klien
  participant A as Aplikasi
  participant I as Layanan internal
  K->>A: GET /image?url=http://192.168.1.1/
  A->>I: request keluar memakai nilai url
  opt payload pengganti
    A->>I: http://0x7f.0x0.0x0.0x1 lalu http://2130706433
  end
  I-->>A: response layanan internal
  A-->>K: response diteruskan ke klien
%% fig: Perjalanan request SSRF dari klien ke layanan internal
%% desc: Nilai url pada parameter dipakai aplikasi sebagai tujuan request keluar, dan opsinya diisi varian encoding dari catatan.

Alamat yang sama dapat ditulis dalam beberapa bentuk. Semua baris di bawah menuju loopback, hanya penulisannya yang berbeda Server Side Request Forgery.md:25-68²³.

Selain bentuk alamat, catatan juga mendaftar URI scheme. Baris file membaca berkas lokal, sedangkan dict dan ldap menembak loopback pada port 1337 Server Side Request Forgery.md:70-99³². Baris gopher membawa payload yang dipisah %0A di dalam path /_Test%0ASSRF Server Side Request Forgery.md:101-104³³.

⚠️ Request keluar ini tidak selalu terlihat pada response. Payload urlApi di atas hanya menguji apakah server benar-benar melakukan request; akibat yang terlihat bergantung pada layanan internal yang dijangkau.

Host Header Injection: header Host pada tautan yang dikirim server

Host Header Injection muncul ketika server memercayai nilai header Host dan gagal memvalidasi atau meng-escape-nya, sehingga penyerang dapat menyuntikkan payload yang mengubah perilaku sisi server Host Header Injection.md:3-4⁴⁰. Tempat mencarinya adalah fitur yang mengirim email kepada kita, misalnya forgot password atau newsletter Host Header Injection.md:6-7⁴¹. Kelima varian di bawah memakai endpoint GET /index.php sebagai contoh.

Empat header pertama pada baris override di atas berlaku sebagai pengganti Host. Catatan memakai X-Forwarded-For : evil-website.com bersama Host: vulnerable-website.com sebagai contoh pemakaiannya. Alur dampaknya pada fitur reset password digambarkan diagram berikut.

graph LR
  R["POST /reset dengan email korban"] --> H["Server membaca Host dan X-Forwarded-Host"]
  H --> M["tautan reset disusun dari nilai header"]
  M --> V["korban menerima email berisi evil.com"]
  V --> A["korban membuka domain penyerang"]
  style H fill:#f59e0b,color:#000
  style M fill:#8b5cf6,color:#fff
  style V fill:#dc2626,color:#fff
  style A fill:#dc2626,color:#fff
%% fig: Header Host mengubah tautan reset yang dikirim ke korban
%% desc: Nilai header dibaca saat menyusun tautan, sehingga email korban memuat domain penyerang.

Pada Checklist/Forgot Password.md, request POST /reset dengan [email protected] diubah dengan menambahkan X-Forwarded-Host: evil.com, dan korban menerima tautan reset yang memakai evil.com Checklist/Forgot Password.md:25-42⁴⁷. Sisi token dan sesi dari alur reset dibahas di halaman Otentikasi, Sesi, dan Token.

Mass Assignment: field tersembunyi yang dapat ditimpa

Mass Assignment terjadi ketika aplikasi membiarkan user menambahkan parameter sendiri pada HTTP request, lalu memproses nilai parameter itu sehingga memengaruhi response yang dikembalikan. Catatan menyebut Ruby on Rails dan NodeJS sebagai tempat yang sering mengalaminya Mass Assignment.md:3-4⁴.

Endpoint contohnya POST /editdata. Perhatikan bahwa parameter yang dikirim adalah admin, sedangkan field yang berubah pada response adalah isAdmin Mass Assignment.md:6-37⁴⁸.

⚠️ Nama parameter request dan nama field response berbeda (admin versus isAdmin). Penyerang harus menebak nama field internal, jadi daftar field dari response normal adalah titik awal, bukan daftar lengkap yang boleh dicoba.

Status response tetap success pada kedua langkah, sehingga satu-satunya penanda perubahan adalah nilai isAdmin yang bergeser dari false menjadi true. Pola ini menutup halaman: server memperlakukan nilai klien sebagai keputusan, baik untuk memilih objek, memilih tujuan request, menyusun tautan, maupun menyimpan field.