Perintah dan cakupan
API pengunggahan berkas harus memungkinkan klien memverifikasi bahwa konten HTTP tidak ditulis ulang oleh gateway atau cache. Berdasarkan RFC 9530, rancang penggunaan Content-Digest, Repr-Digest, dan Want-Repr-Digest, serta jelaskan batasannya dengan TLS, tanda tangan digital, dan percobaan ulang (retry).
Pertanyaan ini menguji apakah Anda dapat mengikat digest ke lapisan HTTP yang benar: Content-Digest mencakup konten pesan sebenarnya, Repr-Digest mendeskripsikan representasi terpilih, dan Want-Repr-Digest menyatakan preferensi penerima terhadap digest representasi. Digest memeriksa integritas konten; digest itu sendiri tidak membuktikan siapa yang mengirim pesan.
Hal yang diuji oleh pewawancara
Cakup perbedaan antara konten pesan dan representasi, pemilihan algoritma yang aman, negosiasi permintaan dan respons, batasan proksi dan kompresi, komputasi streaming, state machine kegagalan digest, dan kombinasi digest yang tepat dengan autentikasi, TLS, percobaan ulang, serta idempotensi.
Jawaban 30 detik
"Pertama, saya mendefinisikan objek dan batas bita (byte) yang sedang diverifikasi. Klien pengunggah menghitung Content-Digest, dan server memverifikasinya saat melakukan streaming pesan yang diterima. Server dapat mengembalikan Repr-Digest, yang diperiksa klien terhadap representasi akhir. Want-Repr-Digest mengomunikasikan preferensi algoritma; server hanya memilih algoritma kuat yang diizinkan dan mencatat hasilnya. Ketidakcocokan akan menghentikan pengiriman atau persistensi. Autentikasi pengirim tetap berasal dari TLS, HTTP Message Signatures, atau token akses."
Solusi langkah demi langkah
Langkah 1: Tentukan objek yang dilindungi
Nyatakan apakah tujuannya adalah konten pesan yang ditransfer atau representasi setelah negosiasi konten. Content-Digest berlaku untuk konten pesan sebenarnya; Repr-Digest mendeskripsikan representasi yang dipilih. Digest representasi tidak dapat memvalidasi urutan bita yang berbeda setelah transkoding.
Langkah 2: Pilih algoritma digest
Gunakan daftar izin (allowlist) yang berisi algoritma yang saat ini disetujui seperti SHA-256 atau SHA-512, dan tolak pilihan lawas seperti MD5 atau SHA-1. Saat mengurai structured field, tolak algoritma duplikat, parameter yang tidak dikenal, dan pengodean yang salah format agar pustaka yang berbeda tidak menafsirkan satu nilai secara berbeda.
Langkah 3: Verifikasi permintaan
Klien pengunggah menghitung Content-Digest atas bita pesan akhir. Server menghitungnya saat membaca dan membandingkannya hanya setelah pesan berakhir. Ketidakcocokan mencegah commit objek dan publikasi event; output parsial tidak pernah diperlakukan sebagai keberhasilan. Pengunggahan besar harus dialirkan (streamed) daripada dibuffer di memori.
Langkah 4: Verifikasi respons
Server dapat mengirimkan Repr-Digest dalam respons. Klien menghitung digest atas representasi terpilih yang didekodekan sesuai dengan aturan yang dinegosiasikan. Jika kompresi dilibatkan, protokol harus menyatakan apakah digest mencakup pesan terkompresi atau representasi yang tidak dikompresi; klien tidak boleh mencampuradukkan lapisan-lapisan tersebut.
Langkah 5: Gunakan Want-Repr-Digest
Klien dapat mengirimkan Want-Repr-Digest dengan preferensi algoritma dan bobot. Server dapat memenuhinya, memilih algoritma lain yang diizinkan, atau menghilangkan field respons. Klien harus membedakan antara "digest tidak disediakan" dan "digest tidak cocok"; ketiadaan field bukanlah verifikasi yang berhasil.
Langkah 6: Tangani proksi dan cache
Cache hit tetap memerlukan digest yang cocok dengan representasi saat ini. Jika gateway mengompresi ulang, melakukan transkode, atau menggabungkan konten, gateway tersebut harus menghitung ulang digest yang relevan; menyalin field hulu (upstream) akan menghasilkan hasil yang salah. Menulis ulang field di luar cakupan bita digest tidak secara otomatis merusak digest, tetapi dapat mengubah semantik tanda tangan atau otorisasi.
Langkah 7: Gabungkan autentikasi dan perlindungan replay
Digest membuktikan relasi bita, bukan identitas pengirim, dan tidak menghentikan pengiriman ulang pesan yang valid. Gunakan TLS, HTTP Message Signatures, atau token untuk autentikasi pengirim. Gunakan nonce, jendela waktu, dan kunci idempotensi bisnis untuk mencegah tagihan ganda. Nilai digest bukanlah kredensial otorisasi.
Langkah 8: Tentukan kegagalan dan observabilitas
Tampilkan metrik dan kelas error terpisah untuk ketidakcocokan, algoritma yang tidak diizinkan, field dengan format salah, dan field yang hilang. Bersihkan objek sementara setelah verifikasi pengunggahan gagal; buang respons cache yang belum diverifikasi dan picu kebijakan percobaan ulang. Catat algoritma, ID permintaan, ukuran, dan kelas kegagalan dalam log, jangan pernah mencatat konten sensitif atau muatan (payload) lengkap.
Untung-rugi (trade-off) dan batasan
Content-Digest atau Repr-Digest
Content-Digest cocok untuk memverifikasi apa yang sebenarnya ditransfer oleh pesan HTTP ini. Repr-Digest cocok untuk cache, negosiasi konten, dan verifikasi representasi sumber daya. Keduanya dapat berdampingan, tetapi protokol harus mendokumentasikan batasan bita dan urutan dekode.
Digest atau tanda tangan digital
Digest berbiaya komputasi rendah dan mendeteksi perubahan dalam transit atau penyimpanan. Tanda tangan digital selain itu mengautentikasi pemegang kunci dan mendukung verifikasi lintas sistem. Tanda tangan dapat mencakup field digest untuk mengikat integritas konten ke metode dan target, tetapi digest itu sendiri tidak memiliki properti identitas.
Gagal tertutup (fail closed) atau degradasi
Pembayaran, paket perangkat lunak, dan arsip yang diatur regulasi harus menolak digest yang hilang atau tidak cocok. Sumber daya statis biasa dengan digest opsional dapat dilanjutkan setelah mencatat peringatan, tetapi pemanggil harus mengetahui bahwa integritas tidak diverifikasi; sumber daya tersebut tidak boleh secara diam-diam ditandai sebagai tepercaya.
Latihan kegagalan dan evolusi
Gateway mengompresi ulang respons
Minta gateway mengubah kompresi, lalu verifikasi bahwa klien masih melakukan hashing pada lapisan representasi yang ditentukan protokol. Jika gateway mengubah lapisan yang dicakup, gateway harus menghasilkan field baru.
Satu bita berubah selama pengunggahan
Ganti satu bita di proksi dan verifikasi bahwa server melaporkan ketidakcocokan Content-Digest sebelum melakukan commit objek, lalu menghapus data sementara dan event hilir (downstream).
Penurunan versi algoritma atau field hilang
Kirim preferensi yang berisi algoritma lawas dan verifikasi bahwa server menolak pilihan yang tidak diizinkan tersebut. Hapus Repr-Digest dan konfirmasikan bahwa klien memasuki cabang "tidak terverifikasi", bukan cabang sukses.
Kesalahan umum dan tindak lanjut
Kesalahan 1: Memperlakukan digest sebagai autentikasi
Tindak lanjut: Bisakah penyerang menghitung ulang digest untuk konten mereka sendiri? Ya. TLS, tanda tangan, atau token tetap diperlukan untuk mengautentikasi pengirim.
Kesalahan 2: Mengabaikan lapisan kompresi dan representasi
Tindak lanjut: Bisakah digest hulu disalin ke respons yang dikompresi ulang? Hanya jika lapisan bita yang dicakup tidak berubah; jika tidak, digest harus dihitung ulang.
Kesalahan 3: Memperlakukan field yang hilang sebagai terverifikasi
Tindak lanjut: Bagaimana jika server menghilangkan digest yang diminta? Tandai hasilnya sebagai tidak terverifikasi atau tolak sesuai kebijakan; ketiadaan bukanlah sebuah kecocokan.
Tindak lanjut lebih mendalam dan jawaban model
Mengapa permintaan pengunggahan dapat menggunakan Content-Digest?
Pengirim dapat memberikan digest sebelum transmisi atau saat streaming selesai, memungkinkan penerima memverifikasi bita sebelum persistensi. Objek besar harus di-hash secara inkremental daripada dibuffer.
Apakah field digest merupakan perlindungan replay?
Bukan. Pesan valid yang sama dapat dikirimkan kembali. Perlindungan replay memerlukan jendela waktu, nonce, cakupan tanda tangan, dan status idempotensi bisnis.
Haruskah proksi menghapus digest hulu?
Hanya jika proksi mengubah bita yang dicakup dan tidak dapat menghitung ulang field tersebut, proksi harus menghapus atau menandainya tidak dapat digunakan. Jika dapat menghitung ulang, proksi harus menghasilkan nilai untuk pesan atau representasi akhir dan mendokumentasikan batasan tanggung jawab.