English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

tamu
1 / ?
kembali ke pelajaran

Header sebagai Kantong

Kerangka kerja pencatatan HTTP memperlakukan header permintaan sebagai kantong pasangan kunci-nilai. API pencatatan mengekspos kantong penuh. Operator mengaktifkan pencatatan header untuk debugging: ketika permintaan gagal, header menceritakan kisahnya. Tidak ada daftar larangan bawaan. Tidak ada penyaringan kredensial dalam dokumentasi. Header penuh ke disk.

Header kredensial dalam permintaan tipikal:

- Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... (token JWT atau OAuth)

- Cookie: session=abc123; auth=xyz789

- X-API-Key: sk-live-abc123...

- X-Auth-Token: ghp_abc123... (pola token akses pribadi GitHub)

Nilai-nilai ini mengautentikasi permintaan. Ketika ditulis ke file log, mereka mengautentikasi setiap permintaan.

Alur Kredensial

Kredensial yang ditulis ke file log tidak tinggal di satu tempat. Ia bergerak:

1. Server web menulis ke /var/log/nginx/access.log

2. Agen rotasi log (logrotate) menyalin ke /var/log/nginx/access.log.1

3. Pengirim log (Fluentd, Filebeat, Logstash) membaca & mengirim ke agregator

4. Log aggregator (Elasticsearch, Splunk, Datadog) mengindeks & menyimpan

5. Disimpan selama 30-90 hari sesuai kebijakan default

Kredensial ada di kelima lokasi secara bersamaan. Mencabut token sesi tidak menghapus kredensial dari log aggregator. Kredensial tetap dapat dicari, diekspor, & diakses oleh siapa pun yang memiliki akses log selama periode retensi penuh.

Jendela Paparan

Jendela paparan untuk kredensial di memori: max(durasi sesi, masa hidup proses). Sesi: jam hingga hari. Proses: jam hingga minggu.

Jendela paparan untuk kredensial di log: max(durasi sesi, retensi log). Sesi: jam hingga hari. Retensi: 30-90 hari.

Kredensial yang dicuri dari memori mengharuskan penyerang hadir selama jendela sesi. Kredensial yang dicuri dari log hanya memerlukan akses ke log aggregator, tersedia secara retroaktif, selama periode retensi penuh.

MOAD-0003 vs MOAD-0004

MOAD-0003 (Kebocoran Konteks): kredensial di memori bocor ke request handler yang salah. Hanya dapat diakses selama jendela proses, melalui thread pool. Bersifat sementara.

MOAD-0004 (Rahasia yang Tercatat): kredensial di disk tetap ada meskipun terjadi rotasi log, pengiriman log, & agregasi log. Dapat diakses secara retroaktif oleh siapa pun yang memiliki akses log, selama 30-90 hari. Bersifat persisten.

Perbedaan struktural: sementara vs persisten. Perbaikan dilakukan pada lapisan yang berbeda.

Sementara vs Persisten

Perbedaan sementara/persisten menentukan permukaan risiko, lapisan perbaikan, & persyaratan respons insiden.

Mengapa MOAD-0004 memiliki risiko lebih tinggi dibanding MOAD-0003? Bandingkan di mana setiap kredensial berada dan berapa lama.

Credential Denylist at the Serialization Layer

Perbaikan: credential denylist pada lapisan serialisasi. Sebelum nilai header mencapai output log, periksa nama header terhadap daftar terlarang. Ganti nilainya dengan [REDACTED].

CREDENTIAL_HEADERS = {
'authorization',
'cookie',
'x-api-key',
'x-auth-token',
'x-csrf-token',
'proxy-authorization',
}

def sanitize_headers(headers: dict) -> dict:
return {
k: '[REDACTED]' if k.lower() in CREDENTIAL_HEADERS else v
for k, v in headers.items()
}

Denylist berada di lapisan serialisasi, bukan di lapisan kueri log. Redaksi kueri log: diterapkan setelah kredensial mencapai disk; nilai mentah masih ada, hanya disembunyikan dari tampilan. Redaksi lapisan serialisasi: kredensial tidak pernah mencapai disk. Nilai mentah tidak pernah masuk ke file log, pengirim log, atau agregator log.

Menguji Denylist

Tiga pola pengujian:

- Positif: permintaan dengan Authorization: Bearer token123 menghasilkan entri log dengan Authorization: [REDACTED]

- Negatif: permintaan dengan Content-Type: application/json menghasilkan entri log dengan nilai tetap utuh

- Tidak peka huruf besar-kecil: AUTHORIZATION: Bearer token123 juga menghasilkan [REDACTED] (nama header HTTP tidak peka huruf besar-kecil)

Denylist memerlukan pemeliharaan: pola header kredensial baru (misalnya header khusus X-Service-Auth) perlu ditambahkan secara eksplisit. Perbaikan ini bersifat struktural tetapi tidak otomatis memelihara dirinya sendiri.

Terapkan Denylist

Sebuah tim mengonfigurasi format log akses Nginx mereka untuk menyertakan semua header permintaan guna men-debug insiden produksi. Konfigurasinya:

log_format debug_format '$remote_addr - $request - $http_authorization - $http_cookie';
access_log /var/log/nginx/debug.log debug_format;

Mereka menyelesaikan insiden & berniat menghapus konfigurasi debug, tetapi perubahan tersebut tidak sampai ke produksi sebelum siklus deployment berikutnya (7 hari kemudian).

Identifikasi cacatnya. Header kredensial apa yang bisa terekspos? Jelaskan pendekatan denylist: di mana pemeriksaan dilakukan, apa yang diperiksa, dan apa yang dihasilkan?