Percayai Header Forwarding Hanya dari Proxy yang Dikenal

Reverse proxy sering mengetahui fakta yang tidak dapat diamati langsung oleh application server. Proxy dapat menghentikan TLS, menerima hostname publik, dan menerima koneksi client sebelum membuka koneksi terpisah ke backend. Field forwarding membawa fakta tersebut melewati hop kedua.

Susunan ini aman hanya jika backend dapat membedakan metadata dari proxy dengan field HTTP yang dikirim client. Nama header tidak menciptakan kepercayaan. Kepercayaan berasal dari jalur jaringan, konfigurasi proxy, dan aturan yang menentukan hop mana yang boleh menetapkan atau mengganti setiap field.

Backend melihat koneksi yang berbeda

Bayangkan request publik yang mencapai proxy terminasi TLS:

browser
  |
  | HTTPS ke https://account.example
  v
reverse proxy
  |
  | HTTP ke 10.0.0.20:8080
  v
aplikasi

Pada socket aplikasi, peer dapat berupa proxy, transport dapat berupa HTTP biasa, dan alamat lokal dapat bersifat private. Namun logic aplikasi mungkin tetap memerlukan scheme, host, dan alamat client yang asli.

Deployment lazim membawa metadata ini melalui field standar Forwarded atau field seperti X-Forwarded-For, X-Forwarded-Host, dan X-Forwarded-Proto. Konvensi yang dipilih penting, tetapi batas kepercayaan di sekelilingnya lebih penting.

Jika aplikasi menerima field tersebut dari setiap requester, client eksternal dapat mencoba mengirim metadata yang sama. Backend kemudian memiliki dua sumber yang bertentangan: properti koneksi yang dapat diverifikasi dan teks di dalam request yang mungkin dikendalikan client.

Field forwarding merupakan sebuah assertion

X-Forwarded-Proto: https menyatakan bahwa hop tepercaya sebelumnya menerima request melalui HTTPS. X-Forwarded-Host: account.example menyatakan authority yang terlihat pada hop tersebut. Field alamat client menyatakan peer jaringan pada koneksi sebelumnya.

Assertion memerlukan provenance. Backend sebaiknya menerimanya hanya ketika immediate peer merupakan proxy yang memang berwenang membuat assertion tersebut.

Boundary yang umum berbentuk:

client tidak tepercaya
     |
     v
edge proxy -- ganti field forwarding -->
     |
     v
aplikasi -- percaya field hanya dari edge proxy

Kata ganti penting. Jika edge hanya mempertahankan field forwarding arbitrary dari request masuk, nilai yang dikendalikan client dapat bertahan hingga channel yang dianggap tepercaya oleh aplikasi. Edge sebaiknya menghapus atau menimpa field yang menjadi tanggung jawabnya, lalu menyusun nilai sesuai policy deployment.

Data host dapat memengaruhi URL yang dibuat aplikasi

Aplikasi kadang membangun absolute URL untuk pesan reset password, OAuth redirect, canonical link, atau redirect setelah login. Jika data public origin berasal dari forwarded host atau scheme yang tidak tepercaya, URL yang dihasilkan dapat mengarah ke origin pilihan penyerang walaupun request mencapai aplikasi yang sah.

Pola yang lebih aman adalah menyimpan public origin dalam konfigurasi tepercaya ketika nilainya tetap:

PUBLIC_ORIGIN=https://account.example

Jika service memang mendukung beberapa public host, kumpulan host yang diterima tetap perlu dibatasi. Metadata proxy dapat memilih salah satu host yang telah dikonfigurasi, tetapi input arbitrary tidak boleh menjadi authority hanya karena berada dalam field forwarding.

Pemisahan ini juga membedakan routing dari security policy. Reverse proxy dapat merutekan banyak hostname, sedangkan aplikasi tertentu mungkin valid hanya pada sebagian hostname tersebut.

Alamat client memerlukan parsing yang sadar hop

Penanganan IP client lebih rumit karena field forwarding dapat berisi chain. Proxy dapat menambahkan alamat ke daftar yang sudah ada, dan beberapa trusted proxy dapat menghasilkan beberapa entry.

Backend tidak boleh menganggap alamat tekstual pertama selalu merupakan client. Backend memerlukan model jalur proxy. Salah satu metode praktis adalah berjalan dari sisi aplikasi pada chain, melewati alamat yang sesuai dengan hop proxy tepercaya, lalu berhenti pada alamat pertama di luar trusted set.

client 198.51.100.8
   |
proxy A
   |
proxy B
   |
aplikasi

forwarded chain: 198.51.100.8, proxy-A
socket peer: proxy-B

Algoritme parsing harus sesuai dengan perilaku proxy yang membentuk field tersebut. Fixed hop count dapat rapuh ketika traffic dapat mencapai aplikasi melalui jalur dengan jumlah intermediary berbeda. Trusted-proxy set yang eksplisit sering lebih mudah diaudit.

Alamat client juga sebaiknya tetap dianggap sebagai identity signal yang lemah. Source address yang diperoleh dengan benar tetap dapat mewakili NAT gateway, carrier network, enterprise egress, atau privacy relay. Alamat itu dapat membantu rate limiting dan telemetry, tetapi tidak seharusnya diam-diam menggantikan authentication yang lebih kuat.

Scheme memengaruhi keputusan secure request

TLS termination menimbulkan pemisahan lain. Koneksi backend dapat berupa HTTP walaupun request publik memakai HTTPS. Framework sering menyediakan flag secure atau reconstructed request URL berdasarkan metadata proxy.

Jika aplikasi mempercayai X-Forwarded-Proto yang tidak diverifikasi, client dapat memengaruhi logic yang bercabang berdasarkan scheme yang terlihat. Dampaknya bergantung pada aplikasi dan framework: redirect behavior, pembuatan absolute URL, cookie policy, dan middleware dapat memakai properti request yang direkonstruksi.

Kontrolnya bukan menolak metadata proxy sepenuhnya. Proxy trust perlu diaktifkan hanya untuk jalur reverse proxy yang nyata dan nilai scheme yang diharapkan perlu ditentukan. Aplikasi yang tidak pernah dimaksudkan menerima traffic Internet secara langsung juga perlu dilindungi pada network layer agar proxy menjadi satu-satunya peer yang dapat menjangkaunya.

Beberapa proxy memerlukan satu contract yang konsisten

CDN, load balancer, ingress proxy, dan service proxy dapat berada pada satu request path:

client
  |
CDN
  |
load balancer
  |
ingress
  |
aplikasi

Setiap hop memerlukan aturan forwarding metadata yang terdokumentasi. Hop mana yang membuat field? Hop mana yang menambahkan nilai? Field mana yang diganti? Private address mana yang diharapkan? Apakah ada komponen yang dapat dilewati?

Tanpa contract tersebut, penambahan satu proxy dapat membatalkan asumsi hop count lama pada aplikasi. Jalur untuk health check atau internal traffic juga dapat berbeda dari jalur publik dan menghasilkan reconstruction yang tidak terduga.

Standardisasi pada satu konvensi internal mengurangi ambiguitas. Field standar Forwarded menyediakan syntax untuk parameter seperti for, host, dan proto, tetapi syntax standar tidak memberikan authenticity. Kepercayaan tetap bergantung pada pihak yang memasok field.

Network control dan application control saling memperkuat

Konfigurasi trusted proxy pada application layer tidak seharusnya memikul seluruh beban. Jika backend hanya dimaksudkan menerima traffic dari load balancer atau ingress tier, firewall rule, security group, private networking, atau kontrol setara perlu menegakkan topology tersebut.

Pembatasan jaringan mengurangi peluang penyerang terhubung langsung ke backend lalu meniru proxy dengan mengirim header yang diharapkan. Pemeriksaan aplikasi kemudian memberi boundary kedua untuk kasus seperti configuration drift atau caller internal tambahan.

Proxy sendiri juga memerlukan inbound policy yang ketat. Proxy perlu menormalisasi field forwarding yang menjadi tanggung jawabnya, bukan menganggap salinan dari client sebagai authoritative.

Log perlu mempertahankan peer dan nilai turunan

Troubleshooting proxy trust sulit ketika log hanya berisi satu reconstructed address atau URL. Telemetry yang berguna mencatat immediate socket peer secara terpisah dari derived client address, serta effective host dan scheme yang dipakai aplikasi.

Pemisahan itu membantu menampilkan kombinasi yang mustahil. Request yang mengklaim forwarding chain publik tetapi datang dari peer di luar proxy network perlu diperlakukan berbeda dari traffic proxied biasa.

Hindari pencatatan secret yang tertanam di URL atau header. Tujuannya adalah provenance untuk routing metadata, bukan merekam seluruh request tanpa batas.

Uji jalur direct dan proxied secara terpisah

Konfigurasi yang aman perlu diuji dengan request yang datang melalui proxy yang dimaksud dan, jika akses jaringan memungkinkan, dengan request langsung ke backend.

Pengujian dapat memastikan bahwa:

  • request dari trusted proxy menghasilkan public host, scheme, dan client address yang diharapkan;
  • field forwarding dari client diganti di edge;
  • direct backend request tidak dapat menyuntikkan origin atau metadata client tepercaya;
  • nilai forwarding malformed ditolak atau diabaikan sesuai policy;
  • jalur internal alternatif tidak tanpa sengaja memperoleh trust yang lebih luas.

Pengujian ini sangat berguna setelah perubahan CDN, load balancer, ingress controller, atau framework proxy setting. Properti keamanan bergantung pada seluruh jalur, bukan satu komponen secara terpisah.

Proxy trust perlu sempit dan eksplisit

Forwarding metadata mengisi kesenjangan informasi yang nyata akibat reverse proxy. Metadata tersebut perlu diperlakukan sebagai infrastructure metadata yang diautentikasi, bukan client input biasa.

Deployment yang kuat mengikat trusted field ke proxy peer yang dikenal, meminta proxy mengganti field yang menjadi tanggung jawabnya, membatasi nilai host dan scheme, mengurai address chain sesuai topology nyata, serta mencegah direct access ketika arsitektur tidak memerlukannya.

Boundary tersebut mempertahankan kegunaan request reconstruction tanpa memberi teks HTTP arbitrary kewenangan yang setara dengan network path.

Referensi

Cybersecurity Reverse Proxy HTTP Trust Boundary