Rakan soket lawan pengepala diteruskan: alamat mana yang anda percaya?

Permintaan yang tiba di aplikasi anda membawa dua jenis bukti alamat: rakan yang membuka sambungan rangkaian, dan medan HTTP yang mendakwa alamat klien terdahulu. Kedua-duanya menjawab soalan yang berbeza. Rakan soket diperhatikan, manakala pengepala didakwa oleh sesiapa yang menulisnya, dan tiada satu pun sepatutnya menggantikan yang lain secara senyap dalam log atau peraturan akses. Perbandingan di bawah memisahkan kedua-duanya, kemudian menunjukkan satu-satunya susunan yang menjadikan pengepala boleh digunakan.

Huraikan laluan sebelum membandingkan apa-apa:

Client -> approved reverse proxy -> application origin

Dalam susunan itu, rakan soket asalan biasanya ialah proksi, dan pengepala pengiriman boleh membawa dakwaan proksi tentang klien. Nilainya datang daripada hubungan terkawal dengan proksi itu, bukan daripada nama pengepala.

Dua jenis bukti alamat

Rakan soket ialah fakta tentang satu sambungan TCP: sesuatu telah melengkapkan jabat tangan dari alamat itu. Ia bukan semestinya manusia, peranti atau akaun yang anda pedulikan, kerana VPN atau pintu keluar Tor boleh menjadi sumber yang diperhatikan oleh perkhidmatan secara sah. Namun ia kekal sebagai satu-satunya alamat yang disahkan oleh hos itu sendiri, dan di situlah seluruh nilainya.

Medan pengiriman ialah metadata tentang rantaian. X-Forwarded-For, X-Real-IP dan medan piawai Forwarded boleh ditulis oleh mana-mana klien yang mencapai titik akhir yang memantulkannya, jadi kebolehpercayaannya bergantung sepenuhnya pada siapa yang dibenarkan menetapkannya.

Simpan kedua-duanya dalam konteks permintaan di bawah nama yang berbeza. Aplikasi yang menimpa rakan dengan pengepala kehilangan keupayaan untuk membina semula ralat kepercayaan kemudian, dan itulah saat yang tepat anda memerlukannya.

Pengepala tidak pernah mengubah laluan sambungan

Menulis alamat ke dalam medan pengiriman tidak mengubah sumber sambungan TCP yang tiba di pelayan, dan tidak mengubah penghalaan di mana-mana sepanjang laluan. Penghalaan VPN biasa atau NAT sumber menyampaikan trafik tanpa sebarang pengepala HTTP. Begitu juga, get laluan transit tidak menulis semula pertukaran HTTPS yang dilindungi dengan betul tanpa mengubah susunan titik akhir TLS.

Kesilapan sebaliknya sama biasa: HTTPS tidak menjadikan pengepala pengiriman yang diberikan oleh klien itu benar. Ia melindungi pengangkutan dakwaan palsu sama baiknya dengan dakwaan benar.

Jika rakan sekerja mencadangkan perubahan pengepala untuk membaiki masalah penghalaan, diagnosis sudah pun tersasar. Baiki laluan, atau baiki konfigurasi proksi yang menulis pengepala itu.

Namakan proksi yang dibenarkan mendakwa

Dua peraturan menjadikan medan pengiriman boleh digunakan, dan kedua-duanya konfigurasi bukan kod. Tepi menormalkan atau membuang apa-apa yang datang dari luar, mengikut tingkah laku terdokumentasinya untuk medan tersebut. Asalan kemudian mengambil alamat pengganti daripada laluan proksi yang anda namakan dan bukan dari tempat lain. Peraturan kedua itu hanya terpakai selagi klien tidak boleh mencapai asalan dengan cara lain, kerana asalan yang menjawab kedua-dua permintaan langsung dan melalui proksi tidak tahu yang mana satu dilayaninya.

Modul IP sebenar NGINX menunjukkan pemisahan itu dengan jelas. set_real_ip_from menamakan penghantar yang dakwaannya dikira, dan real_ip_header menyatakan medan mana yang membawanya; yang pertama melakukan kepercayaan, yang kedua hanya menyatakan di mana hendak melihat.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Arahan pemilihan pengepala sahaja masih tidak menetapkan apa-apa tentang siapa yang menghantar nilai itu.

Keselamatan pengangkutan mesti berjalan sepanjang laluan antara komponen yang anda percayai. Tepi yang menormalkan dengan betul kehilangan nilai itu pada saat lonjakan tidak terlindung di hilir membenarkan orang lain mengedit dakwaan semasa ia dalam perjalanan.

Tangani rantaian berbilang lonjakan secara sengaja

Beberapa proksi memerlukan model rantaian yang jelas. Jangan ambil nilai paling kiri atau paling kanan yang dipisahkan koma kerana sesetengah catatan blog berbuat demikian; ketahui proksi mana yang menambah, mana yang menggantikan dan mana yang mengekalkan medan masuk. NGINX, sebagai contoh, boleh menyusuri senarai ke belakang terhadap set dipercayainya dan berhenti pada alamat pertama yang bukan miliknya, dan itu peraturan produk tersebut, bukan undang-undang yang diikuti setiap rangka kerja. Baca dokumentasi proksi anda sendiri dengan dua soalan yang sama: nilai mana yang dipilihnya, dan penghantar mana yang dipercayainya?

Tuliskan rantaian itu: susunan lonjakan, lonjakan mana yang menetapkan medan dan lonjakan mana yang membuang salinan masuk. Kemudian simpan nota itu di sebelah konfigurasi proksi, bukan hanya dalam tiket. Kemudian ujinya dengan menghantar permintaan dengan pengepala palsu melalui proses pengesahan yang diluluskan dan mengesahkan asalan mengabaikannya.

Apabila anda menambah lonjakan, semak semula dokumen itu. Penyeimbang beban baharu yang dimasukkan di hadapan proksi dipercayai boleh mengubah alamat mana yang menang tanpa sesiapa mengedit aplikasi.

Simpan kedua-dua pemerhatian dalam log

Di tempat diagnostik dibenarkan, log rakan sambungan dan alamat klien ternormal sebagai dua medan berasingan, dan tambah hanya metadata pengiriman yang benar-benar diperlukan oleh tujuan itu. Kemudian buktikan penggunaan dengan dua permintaan: satu melalui proksi yang sepatutnya merekodkan kedua-dua nilai secara munasabah, dan satu percubaan langsung ke asalan yang mesti ditolak.

Ingat apa maksud pasangan itu. Pengepala menambah konteks yang disediakan oleh komponen yang anda pilih untuk dipercayai; rakan kekal sebagai satu-satunya alamat yang benar-benar dilihat oleh hos anda. Kedua-duanya bukan bukti identiti individu, dan reka bentuk yang menganggap mana-mana satu sebagai bukti akan tersilap tentang seseorang.