Keamanan Siber

Keamanan Siber / 17 Sep 2026 / 5 min read

close_range dengan UNSHARE Memisahkan Tabel Descriptor Sebelum Penutupan Massal

Proses Linux multithread dapat mencapai batas yang rumit tepat sebelum execve(): satu thread hendak membuang setiap file descriptor di atas standard input, output, dan error, sementara thread lain masih dapat membuat descriptor pada tabel yang sama. Loop pemanggilan close() menangani nomor descriptor satu per satu, tetapi tidak dengan sendirinya mengubah fakta bahwa tabel tersebut dibagi. close_range() dengan CLOSE_RANGE_UNSHARE menangani race spesifik itu. Kernel terlebih dahulu memberi caller tabel file descriptor yang tidak lagi dibagi dengan pengguna lain dari tabel lama, lalu menerapkan penutupan massal yang diminta pada tabel milik caller. Properti keamanannya berkaitan dengan kepemilikan tabel selama pembersihan, bukan sekadar pengurangan jumlah system call.

Keamanan Siber Linux

Keamanan Siber / 17 Sep 2026 / 6 min read

Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit Secara Publik

Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit Secara Publik Certificate authority yang dipercaya publik dapat menerbitkan sertifikat yang secara sintaksis valid untuk sebuah domain meskipun penerbitan itu seharusnya tidak pernah terjadi. Validasi TLS path saja tidak dapat mengungkap kesalahan tersebut jika sertifikat berantai ke root tepercaya, cocok dengan nama yang diminta, masih dalam masa berlaku, dan memenuhi pemeriksaan kebijakan client lainnya. Certificate Transparency mengubah bukti yang tersedia di sekitar peristiwa itu. Alih-alih hanya mengandalkan catatan privat CA dan pengungkapan insiden di kemudian hari, ekosistem dapat mewajibkan penerbitan sertifikat meninggalkan bukti yang dapat diverifikasi secara kriptografis dalam log append-only publik. Log tidak memutuskan apakah sebuah sertifikat diotorisasi. Log membuat penerbitan dapat diamati dan membuat bentuk tertentu dari equivocation log dapat dideteksi.

Keamanan Siber TLS

Keamanan Siber / 16 Sep 2026 / 5 min read

TLS Early Data Menukar Latensi Handshake dengan Risiko Replay

TLS Early Data Menukar Latensi Handshake dengan Risiko Replay Client yang kembali dapat memiliki cukup state dari koneksi TLS 1.3 sebelumnya untuk mengirim application data bersama flight handshake pertamanya. Ini menghilangkan satu round trip dari critical path untuk traffic yang memenuhi syarat, tetapi juga mengubah properti keamanan yang sering dianggap implisit oleh aplikasi: encrypted transport tidak lagi berarti sebuah request hanya dapat muncul satu kali di seluruh koneksi. TLS 1.3 early data, yang umum disebut 0-RTT, dilindungi menggunakan key yang diturunkan dari pre-shared key yang terkait dengan session sebelumnya atau PSK yang disediakan secara eksternal. Server belum memberikan fresh handshake state ketika byte tersebut dikirim. Akibatnya, early data memiliki replay property yang lebih lemah daripada application data biasa yang dikirim setelah handshake.

Keamanan Siber TLS

Keamanan Siber / 16 Sep 2026 / 7 min read

Proof Penyangkalan DNSSEC Memungkinkan Resolver Mensintesis Jawaban Negatif

Proof Penyangkalan DNSSEC Memungkinkan Resolver Mensintesis Jawaban Negatif Recursive resolver menerima query untuk random subdomain di bawah signed zone dan sudah memiliki validated denial record dari lookup sebelumnya. Label yang ditanyakan tidak pernah dikirim ke authoritative server, tetapi resolver tetap dapat mengembalikan authenticated negative result. Jawaban itu bukan tebakan dan bukan exact-match negative caching biasa. Jawaban tersebut diturunkan dari cryptographic evidence yang mencakup sebagian DNS namespace. Perilaku ini merupakan efek operasional aggressive use of DNSSEC-validated cache, yang distandardisasi dalam RFC 8198 dan disempurnakan oleh RFC 9077. Record NSEC dan NSEC3 tidak hanya membuktikan satu queried name tidak ada. Dalam aturan validasi DNSSEC yang berlaku, record tersebut dapat membuktikan ketiadaan di sepanjang sebuah rentang. Validating resolver dapat menyimpan evidence itu dan menerapkannya pada query berikutnya selama proof tersebut masih dapat digunakan.

Keamanan Siber DNS

Keamanan Siber / 16 Sep 2026 / 8 min read

HTTP Request Smuggling Dimulai Saat Intermediary Berbeda Menentukan Batas Pesan

Reverse proxy menerima request HTTP/1.1, menentukan tempat body berakhir, lalu meneruskan trafik ke application server melalui koneksi persisten. Jika application server menentukan batas berbeda dari informasi framing yang sama, kedua komponen berhenti sepakat mengenai byte mana yang termasuk ke request tertentu. Byte yang dianggap sebagai body oleh satu komponen dapat menjadi awal request baru bagi komponen lain. Perbedaan tersebut merupakan kondisi inti HTTP request smuggling. Masalahnya bukan sekadar header malformed, proxy, atau connection reuse secara terpisah. Masalahnya adalah parser differential di sepanjang chain tempat beberapa recipient menafsirkan framing request dan setidaknya satu koneksi membawa trafik berikutnya.

Keamanan Siber HTTP

Keamanan Siber / 16 Sep 2026 / 8 min read

HTTP Request Framing Desynchronization Mengubah Perbedaan Parser Menjadi Kegagalan Proxy Boundary

HTTP Request Framing Desynchronization Mengubah Perbedaan Parser Menjadi Kegagalan Proxy Boundary Reverse proxy dapat memvalidasi HTTP request, meneruskannya ke origin, tetapi tetap membuat origin memproses urutan request yang berbeda dari yang disetujui proxy. Kegagalan ini bukan akibat hilangnya encryption atau authentication check yang tidak ada. Ia muncul ketika dua recipient mengonsumsi byte pada connection yang sama dengan aturan berbeda untuk menentukan tempat satu message berakhir dan message berikutnya dimulai. HTTP request smuggling adalah konsekuensi keamanan dari ketidaksepakatan tersebut. Boundary penentunya adalah message framing: jika edge server dan downstream server tidak sepakat mengenai body length, field syntax, atau malformed input, byte yang diperlakukan sebagai body data oleh satu komponen dapat ditafsirkan sebagai request baru oleh komponen berikutnya.

Keamanan Siber HTTP

Keamanan Siber / 16 Sep 2026 / 7 min read

HSTS Mengunci Navigasi HTTP ke Kebijakan Origin HTTPS-Only

HSTS Mengunci Navigasi HTTP ke Kebijakan Origin HTTPS-Only Browser menerima link yang diawali http:// untuk host yang sebelumnya pernah dihubungi secara aman. Tidak ada request HTTP yang keluar dari perangkat. Sebaliknya, user agent menulis ulang navigasi menjadi HTTPS berdasarkan kebijakan lokal dan langsung memulai TLS. Redirect di sisi server yang sering dikaitkan administrator dengan migrasi HTTPS tidak pernah terlibat dalam jalur request tersebut. HTTP Strict Transport Security (HSTS), yang distandardisasi dalam RFC 6797, menghasilkan perilaku ini dengan memungkinkan host HTTPS mendeklarasikan kebijakan transport berbatas waktu. Setelah user agent yang sesuai menyimpan kebijakan tersebut, HTTP tidak aman tidak lagi menjadi pilihan transport yang diizinkan untuk request yang cocok selama masa berlaku kebijakan. Batas penting pun berpindah dari penanganan respons server ke pemilihan koneksi di sisi client.

Keamanan Siber HTTP

Keamanan Siber / 16 Sep 2026 / 8 min read

Header Sertifikat Client Memindahkan Identitas mTLS ke Trust Boundary Proxy

Sebuah service dapat mewajibkan mutual TLS pada public edge tetapi tetap tidak memiliki TLS client certificate di application server. Client membuktikan kepemilikan private key kepada reverse proxy yang melakukan terminasi TLS; proxy kemudian membuka koneksi terpisah ke origin. Kecuali informasi sertifikat dibawa melewati hop kedua tersebut, origin tidak dapat secara langsung memeriksa credential yang diautentikasi pada koneksi pertama. Meneruskan sertifikat melalui HTTP field menyelesaikan masalah transport, tetapi mengubah security boundary. Origin tidak lagi mengonsumsi identity evidence langsung dari TLS handshake miliknya sendiri. Origin mengonsumsi pernyataan yang dibuat intermediary tentang handshake yang berbeda.

Keamanan Siber TLS

Keamanan Siber / 16 Sep 2026 / 8 min read

Cross-Origin Opener Policy Memisahkan Relasi Window pada Browsing Context Boundary

Cross-Origin Opener Policy Memisahkan Relasi Window pada Browsing Context Boundary Browser dapat mencegah cross-origin popup membaca sebagian besar properti opener-nya sambil tetap mempertahankan hubungan hidup antara kedua window. Same-origin policy membatasi akses langsung ke foreign document, tetapi cross-origin WindowProxy dapat tetap dapat dijangkau, mengekspos interface terbatas, ikut dalam navigation relationship, dan membawa observable state seperti apakah window yang direferensikan sudah ditutup. Perbedaan ini penting bagi aplikasi yang menganggap origin separation sama dengan window separation. Halaman hostile dapat membuka site sensitif, atau site sensitif dapat membuka external service, sementara kedua document tetap berhubungan melalui browser-level context machinery. Cross-Origin-Opener-Policy (COOP) mengubah hubungan ini dengan mengontrol penempatan ke browsing context group.

Keamanan Siber Keamanan Browser

Keamanan Siber / 15 Sep 2026 / 6 min read

Certificate Transparency Membuat Penerbitan TLS Publik Dapat Diaudit

Certificate Transparency Membuat Penerbitan TLS Publik Dapat Diaudit Sertifikat TLS yang dipercaya publik dapat valid secara teknis tetapi tetap menjadi masalah keamanan serius. Certificate authority dapat menerbitkan sertifikat untuk domain yang salah setelah kompromi akun, kegagalan validasi, atau kesalahan operasional. Sertifikat tersebut dapat memiliki signature yang valid, membentuk chain ke root tepercaya, dan memenuhi pemeriksaan hostname biasa. Dari sudut pandang browser, properti itu saja tidak menunjukkan bahwa operator domain tidak pernah mengharapkan sertifikat tersebut ada.

Keamanan Siber Certificate Transparency

Keamanan Siber / 13 Sep 2026 / 8 min read

Verifikasi JWT Harus Mengikat Algorithm, Key, dan Issuer

Verifikasi JWT Harus Mengikat Algorithm, Key, dan Issuer Token yang ditandatangani dapat valid secara kriptografis tetapi tetap tidak dapat diterima oleh service yang menerimanya. Signature menjawab pertanyaan sempit: byte token cocok dengan signature yang dibuat menggunakan cryptographic key tertentu di bawah algorithm tertentu. Authorization bergantung pada kumpulan fakta yang lebih luas, termasuk siapa yang mengendalikan key tersebut, issuer mana yang dipercaya, audience mana yang dituju token, dan algorithm mana yang memang dimaksudkan aplikasi untuk diterima.

Keamanan Siber Autentikasi

Keamanan Siber / 10 Sep 2026 / 11 min read

Ikat Callback OAuth ke Login yang Memulainya

Callback OAuth dapat terlihat valid meskipun berasal dari interaksi browser yang salah. Authorization server mungkin telah menerbitkan code yang nyata, redirect URI mungkin benar, dan pertukaran code mungkin berhasil. Namun jika client tidak dapat menentukan apakah browser ini benar-benar memulai authorization flow tersebut, client dapat mengaitkan identitas eksternal atau authorization yang salah ke session saat ini. Ini adalah bentuk cross-site request forgery pada callback OAuth. Dalam login flow, salah satu konsekuensinya adalah login CSRF: korban dapat berakhir login ke client sebagai account yang terkait dengan orang lain. Detailnya berbeda antar-aplikasi, tetapi pertanyaan defensifnya tetap sama: apakah callback ini milik transaksi login yang dimulai user agent ini?

Cybersecurity OAuth

Keamanan Siber / 09 Sep 2026 / 9 min read

Buat Request Sensitif Tahan terhadap Replay

Server dapat membuktikan dengan benar bahwa sebuah request berasal dari client tepercaya tetapi tetap memprosesnya lebih banyak dari yang dimaksudkan. Jika request terautentikasi mengatakan “setujui pembayaran ini” atau “ubah alamat pemulihan ini”, menerima request valid yang sama dua kali dapat menimbulkan masalah keamanan walaupun tidak ada salinan yang dipalsukan. Ini adalah masalah replay. Replay terjadi ketika pesan yang sebelumnya valid disajikan kembali dan penerima tidak dapat mengetahui bahwa otoritasnya sudah digunakan, atau bahwa pesan tersebut terlalu lama untuk dipercaya.

Keamanan Siber Autentikasi

Keamanan Siber / 08 Sep 2026 / 9 min read

Hentikan Secret Sebelum Masuk ke Version Control

Developer dapat menghapus API key dari versi terbaru sebuah file tetapi tetap meninggalkan key tersebut di riwayat version control. Setelah credential nyata ter-commit, menghapus baris yang terlihat tidaklah cukup: salinannya mungkin masih berada di commit sebelumnya, clone, cache, mirror, build system, atau tempat lain yang pernah mengamati repository. Karena itu, kebocoran secret merupakan masalah yang sebaiknya dihentikan sejak awal. Alih-alih hanya mengandalkan scan belakangan yang melaporkan credential setelah masuk ke riwayat repository, tim dapat memeriksa perubahan pada batas tempat perubahan akan diterima dan memblokir secret yang dicurigai sebelum hal itu terjadi.

Keamanan Siber Manajemen Secret