Langsung ke konten

Topic archive

Keamanan Siber

Artikel Keamanan Siber berfokus pada keamanan aplikasi dan infrastruktur secara praktis, kontrol akses, TLS, hardening, pencegahan serangan, dan praktik operasional yang aman.

206 articles
Keamanan Siber 23 Sep 2026 5 min read

Validasi Origin RPKI Memeriksa Otoritas Prefix BGP

BGP mengumumkan reachability, tetapi sebuah route advertisement tidak membuktikan bahwa Autonomous System yang menjadi origin memiliki otorisasi untuk mengumumkan prefix tersebut. Resource Public Key Infrastructure, atau RPKI, menambahkan data otorisasi resource bertanda tangan yang dapat diubah menjadi record untuk validasi origin pada router. Pemeriksaan ini sengaja memiliki cakupan sempit. Prefix dan origin AS pada rute dibandingkan dengan validated ROA payloads, yang umum disebut VRP. Hasilnya dapat digunakan oleh kebijakan routing, tetapi tidak mengautentikasi setiap AS di dalam AS_PATH dan tidak mengubah BGP menjadi protokol validasi path.

Keamanan Siber 23 Sep 2026 6 min read

TLS-RPT Menampilkan Kegagalan TLS SMTP sebagai Laporan Agregat

Keamanan transport SMTP memiliki persoalan observabilitas. Domain penerima dapat memublikasikan kebijakan MTA-STS atau record DANE TLSA, tetapi banyak kegagalan terjadi pada sistem pengirim di luar kendalinya: validasi sertifikat dapat gagal, host MX dapat tidak terjangkau, negosiasi STARTTLS dapat bermasalah, atau kebijakan transport yang dipublikasikan dapat tidak valid. Penerima memerlukan telemetri dari pengirim tersebut untuk membedakan deployment yang berfungsi dari kebijakan yang tanpa terlihat menghambat pengiriman. SMTP TLS Reporting, yang umum disebut TLS-RPT, menetapkan kanal telemetri tersebut dalam RFC 8460. Domain penerima memublikasikan record DNS TXT yang menyebut satu atau beberapa tujuan laporan. Sistem pengirim yang mendukung mekanisme ini kemudian menghasilkan laporan agregat mengenai sesi TLS yang berhasil memenuhi kebijakan dan kegagalan yang ditemui saat mengirim email ke domain tersebut.

Keamanan Siber 23 Sep 2026 4 min read

TLS Must-Staple Mewajibkan Status OCSP

TLS Must-Staple Mewajibkan Status OCSP OCSP stapling memungkinkan server TLS membawa bukti status sertifikat di dalam handshake. Client dapat memvalidasi response tersebut tanpa membuat request terpisah ke OCSP responder milik certificate authority. Namun, stapling biasa tidak otomatis membuat response yang hilang menjadi kesimpulan tentang status sertifikat: ketiadaan dapat sekadar berarti server tidak mengirimkannya. RFC 7633 mendefinisikan ekstensi X.509v3 TLS Feature. Sertifikat dapat memakai ekstensi ini untuk menyatakan bahwa sebuah fitur TLS diwajibkan. Fitur yang umum disebut Must-Staple menunjuk status_request, sehingga penggunaan sertifikat terikat pada pengiriman informasi status sertifikat bagi client yang mengimplementasikan ekstensi tersebut.

Keamanan Siber 23 Sep 2026 5 min read

Subresource Integrity Mengikat Aset Eksternal ke Digest Kriptografis

Subresource Integrity Mengikat Aset Eksternal ke Digest Kriptografis Halaman web dapat memuat JavaScript dan CSS dari origin di luar batas deployment-nya sendiri. Susunan ini praktis untuk package bersama dan content delivery network, tetapi sebagian jalur eksekusi atau presentasi halaman ikut bergantung pada server yang mengirim resource tersebut. Subresource Integrity (SRI) menambahkan batasan pada tingkat byte terhadap dependensi itu. Halaman menyertakan satu atau beberapa digest kriptografis melalui atribut integrity. Browser yang mendukung SRI mengambil resource, menghitung digest memakai algoritma yang dideklarasikan, lalu menerima response hanya jika byte-nya memenuhi metadata integritas.

Keamanan Siber 23 Sep 2026 4 min read

SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC

SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC Client SSH memerlukan dasar tepercaya untuk menentukan apakah host key server benar-benar milik host yang dituju. Entri lokal known_hosts menyediakan dasar tersebut setelah sebuah key diterima, tetapi koneksi pertama tetap memerlukan jalur verifikasi jika key belum diprovisikan sebelumnya. SSHFP menempatkan fingerprint host key di DNS. RFC 4255 mendefinisikan resource record SSHFP agar client dapat membandingkan public key yang disajikan server SSH dengan fingerprint yang dipublikasikan untuk hostname tersebut. Properti keamanannya bergantung pada data DNS yang terautentikasi: fingerprint yang cocok dari jawaban DNS tanpa autentikasi tidak memenuhi kondisi trust yang ditetapkan untuk verifikasi SSHFP yang aman.

Keamanan Siber 23 Sep 2026 5 min read

Sertifikat Host OpenSSH Menggantikan Pinning Key per Host

Sertifikat Host OpenSSH Menggantikan Pinning Key per Host Autentikasi host SSH melindungi client agar tidak diam-diam menerima key server berbeda untuk nama yang hendak dituju. Model known_hosts yang umum dapat melakukan pinning key secara langsung ke sebuah host. Model ini sederhana, tetapi pengoperasiannya pada fleet besar menimbulkan masalah distribusi: host baru memerlukan entri tepercaya, rotasi key terencana mengubah pin, dan entri lama dapat bertahan setelah infrastruktur berubah. Sertifikat host OpenSSH memindahkan keputusan trust itu satu tingkat ke atas. Client dapat mempercayai certificate authority (CA) host, sedangkan server menyajikan sertifikat host yang ditandatangani CA tersebut. Client tetap memvalidasi host key, tetapi penerimaan bergantung pada signature sertifikat, identitas host, interval validitas, dan semantik sertifikat, bukan pin jangka panjang yang terpisah untuk setiap server.

Keamanan Siber 23 Sep 2026 5 min read

RPKI ASPA Mengotorisasi Hubungan Transit untuk Pemeriksaan AS_PATH

Origin rute yang valid hanya memberi sedikit informasi tentang hubungan yang direpresentasikan oleh bagian lain AS_PATH. Sebuah prefix dapat berasal dari AS yang berwenang tetapi tetap melewati urutan AS yang bertentangan dengan struktur customer-to-provider yang diharapkan. Autonomous System Provider Authorization, atau ASPA, menambahkan objek RPKI bertanda tangan untuk masalah kedua tersebut. Per September 2026, ASPA masih ditetapkan dalam Internet-Draft IETF aktif, belum sebagai RFC yang telah diterbitkan. Draft profil ASPA saat ini mendefinisikan objek bertanda tangan, sedangkan draft verifikasi saat ini mendefinisikan prosedur untuk menerapkan data ASPA tervalidasi pada AS_PATH BGP. Status tersebut penting secara operasional: field dan prosedurnya masih dapat berubah sampai spesifikasi menyelesaikan proses standardisasi.

Keamanan Siber 23 Sep 2026 4 min read

Record CAA Membatasi Penerbitan oleh Certificate Authority

Record CAA Membatasi Penerbitan oleh Certificate Authority Sebuah certificate authority publik hanya dapat menerbitkan sertifikat setelah memenuhi persyaratan validasi dan kebijakannya. DNS Certification Authority Authorization menambahkan kontrol lain: pemegang domain dapat mempublikasikan resource record set CAA yang menyatakan issuer mana yang diizinkan untuk suatu nama. CAA merupakan batas penerbitan, bukan pengganti validasi kontrol domain. CA yang diizinkan tetap harus menjalankan validasi yang diwajibkan oleh certificate policy-nya. Sebaliknya, validasi domain yang berhasil tidak memberi izin kepada CA yang patuh untuk mengabaikan pembatasan CAA yang berlaku.

Keamanan Siber 23 Sep 2026 4 min read

Prefix Cookie __Host- Membatasi Cakupan Cookie

Prefix Cookie __Host- Membatasi Cakupan Cookie Keamanan cookie tidak hanya bergantung pada nilai yang disimpan. Cakupan menentukan request mana yang dapat membawa cookie dan response mana yang dapat mencoba menggantinya. Untuk cookie sesi sensitif, aturan domain yang luas dapat memberi pengaruh kepada host saudara yang sebenarnya tidak diperlukan aplikasi. Prefix nama cookie __Host- memberi browser yang mendukungnya seperangkat persyaratan cakupan yang ringkas. Cookie dengan nama berawalan __Host- hanya diterima jika memakai Secure, memiliki Path=/, dan tidak memiliki atribut Domain. Hasilnya adalah cookie khusus host yang tersedia pada seluruh path di host tersebut dan dibatasi ke transport aman.

Keamanan Siber 23 Sep 2026 6 min read

Origin-Agent-Cluster Memisahkan Heap JavaScript Berbasis Origin

Origin-Agent-Cluster Memisahkan Heap JavaScript Berbasis Origin Origin web yang berada dalam satu site tetap dapat menjadi principal keamanan yang berbeda. app.example.com dan admin.example.com, misalnya, memiliki origin berbeda meskipun keduanya berada di bawah registrable domain yang sama. Arsitektur proses browser secara historis dapat menempatkan origin terkait dalam agent cluster yang sama pada kondisi tertentu, sehingga lingkungan eksekusi JavaScript mereka lebih berdekatan daripada yang tersirat dari model berbasis origin saja. Header response Origin-Agent-Cluster memberi dokumen cara untuk meminta clustering berbasis origin:

Keamanan Siber 23 Sep 2026 6 min read

NSEC3 Opt-Out Menukar Cakupan Bukti demi Skala Delegasi

DNSSEC memerlukan jawaban kriptografis bukan hanya saat data tersedia, tetapi juga saat nama atau record yang diminta tidak ada. NSEC3 menyediakan negative proof tersebut melalui rantai hashed owner name. Pada zona yang didominasi delegasi menuju child zone tanpa tanda tangan, merepresentasikan setiap delegasi tidak aman di dalam rantai dapat menambah pekerjaan pemeliharaan secara signifikan. NSEC3 Opt-Out mengubah kompromi tersebut. Sebuah Opt-Out span dapat mencakup delegasi tidak aman tanpa memberikan NSEC3 record tersendiri kepada setiap delegasi. Hasilnya dapat mengurangi pembaruan NSEC3 chain pada zona besar yang sarat delegasi, tetapi nama yang dihilangkan tidak lagi memperoleh pernyataan terautentikasi yang sama mengenai keberadaan atau ketidakberadaannya.

Keamanan Siber 23 Sep 2026 5 min read

Nonce Content Security Policy Mengendalikan Eksekusi Script

Nonce Content Security Policy Mengendalikan Eksekusi Script Content Security Policy dapat mengubah eksekusi script dari aturan lokasi yang luas menjadi keputusan eksplisit untuk setiap respons. Alih-alih mempercayai setiap script yang disajikan dari host yang diizinkan, server menempatkan nonce baru di dalam policy lalu menyalin nilai tersebut hanya ke elemen script yang memang hendak diotorisasi. Content-Security-Policy: script-src 'nonce-r4nd0mBase64Value' <script nonce="r4nd0mBase64Value" src="/assets/app.js"></script> Elemen script tanpa nonce yang cocok tidak mendapat otorisasi dari directive tersebut. Markup hasil injeksi menjadi lebih terbatas bagi penyerang ketika jalur injeksi tidak dapat memperoleh nonce yang valid.

Keamanan Siber 23 Sep 2026 5 min read

MTA-STS Mewajibkan TLS Terautentikasi untuk Pengiriman SMTP

MTA-STS Mewajibkan TLS Terautentikasi untuk Pengiriman SMTP SMTP STARTTLS dapat mengenkripsi transport email, tetapi TLS oportunistik biasa mengizinkan pengiriman berlanjut saat enkripsi tidak tersedia. Perilaku kompatibilitas tersebut membuka ruang bagi perantara aktif untuk menekan STARTTLS atau mengalihkan pengiriman menuju server yang tidak semestinya. SMTP MTA Strict Transport Security, yang ditetapkan dalam RFC 8461, memberi domain penerima kanal kebijakan untuk MTA pengirim yang kompatibel. Kebijakan itu menetapkan host MX yang dapat diterima dan apakah pengiriman harus memakai TLS dengan sertifikat PKIX yang valid. Dalam mode enforce, pengirim tidak melakukan downgrade secara diam-diam ketika pemeriksaan tersebut gagal.

Keamanan Siber 23 Sep 2026 6 min read

HTTP Strict Transport Security Mengunci HTTPS untuk Kunjungan Berikutnya

HTTP Strict Transport Security Mengunci HTTPS untuk Kunjungan Berikutnya TLS melindungi koneksi HTTP setelah klien memakai HTTPS. Pengguna yang mengetik hostname tanpa skema, mengikuti tautan lama http://, atau membuka endpoint HTTP yang melakukan redirect masih dapat memulai sesi dengan request tanpa enkripsi. HTTP Strict Transport Security (HSTS) memberi browser yang mendukungnya aturan persisten untuk host tersebut. Setelah menerima header Strict-Transport-Security yang valid melalui HTTPS, browser menyimpan kebijakan itu dan mengubah navigasi HTTP berikutnya menjadi HTTPS selama kebijakan masih aktif.

Keamanan Siber 23 Sep 2026 5 min read

Fetch Metadata Menambahkan Konteks Request ke Kebijakan Server

Fetch Metadata Menambahkan Konteks Request ke Kebijakan Server Server sering menerima cookie autentikasi yang sama dari request yang dibuat melalui aksi browser yang sangat berbeda. Form dari situs lain, panggilan API same-origin, pemuatan gambar, dan navigasi tingkat atas dapat menuju host yang sama. Cookie saja tidak menjelaskan konteks request tersebut. Fetch Metadata menambahkan header request buatan browser yang menjelaskan asal request dan cara browser akan memakai response. Server dapat memasukkan sinyal tersebut ke kebijakan isolasi sebelum logika aplikasi menangani route sensitif.

Keamanan Siber 23 Sep 2026 5 min read

DNS Cookies Membatasi Amplifikasi dan Pemalsuan DNS Off-Path

UDP membuat DNS efisien, tetapi source address dapat dipalsukan oleh pengirim off-path. Query kecil yang membawa alamat korban dapat memicu response yang lebih besar menuju korban tersebut, sehingga terbentuk reflection dan amplification. Response palsu juga relevan bagi resolver karena penyerang dapat mencoba menyisipkan jawaban sebelum response yang sah tiba. DNS Cookies menambahkan token transaksi ringan pada batas ini. RFC 7873 menetapkan option COOKIE pada EDNS, sedangkan RFC 9018 memperbarui konstruksi sisi server agar implementasi dapat saling beroperasi, termasuk pada deployment anycast multi-vendor. Cakupan mekanisme ini sengaja terbatas: mekanisme tersebut menaikkan biaya pemalsuan off-path, tetapi bukan enkripsi, autentikasi data DNS, atau perlindungan dari adversary yang dapat mengamati traffic pada jalur.

Keamanan Siber 23 Sep 2026 5 min read

DMARC Mengaitkan Autentikasi Email dengan Domain From yang Terlihat

Email dapat membawa beberapa identitas domain sekaligus. Alamat yang tampil pada header From dapat berbeda dari envelope sender yang dipakai SMTP, sementara tanda tangan DKIM dapat menyebut domain lain lagi pada tag d=. SPF dan DKIM mengautentikasi identitas dari lapisan protokol yang berbeda tersebut; masing-masing mekanisme tidak dengan sendirinya mewajibkan domain terautentikasi cocok dengan domain yang ditampilkan kepada penerima pada From. Domain-based Message Authentication, Reporting, and Conformance (DMARC), yang ditetapkan dalam RFC 7489, menghubungkan lapisan tersebut. Penerima mengevaluasi SPF dan DKIM, menguji keselarasan domain terhadap domain RFC5322.From, lalu mengambil kebijakan yang dipublikasikan domain itu. Pesan lolos DMARC ketika setidaknya satu jalur SPF atau DKIM yang memenuhi syarat berhasil diautentikasi sekaligus selaras.

Keamanan Siber 23 Sep 2026 4 min read

DANE untuk SMTP Mengikat Autentikasi TLS ke DNSSEC

SMTP umumnya memulai koneksi dalam plaintext lalu meningkatkannya dengan STARTTLS. Opportunistic TLS meningkatkan kerahasiaan ketika kedua sisi mendukungnya, tetapi upgrade tanpa autentikasi dapat ditekan atau dialihkan oleh penyerang aktif di jaringan. DANE untuk SMTP, yang ditetapkan dalam RFC 7672, menambahkan jalur autentikasi yang berakar pada DNSSEC. MTA pengirim tidak menganggap setiap respons TLSA sebagai otoritatif. Pengirim terlebih dahulu memerlukan hasil DNSSEC-secure untuk data tujuan yang mengarahkan pengiriman. Ketika record TLSA yang dapat digunakan diperoleh secara aman untuk host MX terpilih, record tersebut membatasi kredensial server TLS yang dapat diterima pengirim.

Keamanan Siber 23 Sep 2026 4 min read

DANE TLSA Mengikat Key Layanan TLS melalui DNSSEC

DANE TLSA Mengikat Key Layanan TLS melalui DNSSEC TLS biasanya mengautentikasi server melalui aturan validasi sertifikat yang ditetapkan aplikasi dan trust model-nya. DANE menambahkan binding berbasis DNS: resource record TLSA mengasosiasikan endpoint layanan dengan material sertifikat atau public key, sedangkan DNSSEC menyediakan data DNS terautentikasi untuk asosiasi tersebut. Batasnya tegas. RRset TLSA yang berstatus insecure atau memiliki status DNSSEC indeterminate tidak dapat menjadi asosiasi DANE terautentikasi. Karena itu, DANE bergantung pada validasi DNSSEC dan tidak menganggap transport DNS biasa sebagai bukti yang memadai.

Keamanan Siber 23 Sep 2026 5 min read

Cross-Origin-Resource-Policy Membatasi Embedding No-CORS

Cross-Origin-Resource-Policy Membatasi Embedding No-CORS Banyak elemen browser dapat meminta resource lintas origin tanpa memakai CORS. Image, script, media, dan subresource lain dapat melewati jalur fetch no-cors ketika halaman tidak memperoleh akses normal dari script ke body response. Pembatasan tersebut berguna, tetapi load cross-origin yang tidak diinginkan tetap dapat mengekspos resource pada embedding atau kondisi side-channel. Header response Cross-Origin-Resource-Policy, yang umum disingkat CORP, memungkinkan pemilik resource menyatakan hubungan site yang diizinkan untuk load no-cors tersebut.

Keamanan Siber 23 Sep 2026 5 min read

Caching DNSSEC Agresif Memakai Ulang Bukti Penyangkalan Terautentikasi

Negative cache DNS konvensional mengingat hasil negatif untuk query tertentu. DNSSEC menambahkan materi yang lebih kaya pada response tersebut: record NSEC dan NSEC3 dapat membuktikan secara kriptografis bahwa nama atau tipe record tidak ada. RFC 8198 mengizinkan resolver yang melakukan validasi untuk memakai ulang bukti tersebut bagi query berikutnya yang berada di dalam ruang yang telah dibuktikan. Perilaku ini disebut aggressive use of the DNSSEC-validated cache. Resolver dapat menahan lookup authoritative berulang untuk nama yang ketiadaannya sudah ditetapkan oleh data tervalidasi. Mekanisme ini bukan sekadar optimasi performa: berkurangnya query yang tidak perlu juga mengurangi penyebaran nama salah ketik atau nama acak melewati recursive resolver dan dapat menyerap sebagian beban dari traffic random-QNAME.

Keamanan Siber 23 Sep 2026 5 min read

BGPsec Menandatangani Jalur AS pada Setiap Hop

Otorisasi origin route BGP melindungi satu pernyataan yang sempit: AS mana yang boleh mengawali sebuah prefix. Mekanisme itu tidak melindungi setiap hop AS setelah origin secara kriptografis. BGPsec, yang distandardisasi dalam RFC 8205, menangani batas yang berbeda tersebut dengan membawa informasi jalur bertanda tangan di dalam pesan BGP UPDATE. Mekanismenya mengubah lebih dari aturan validasi. BGPsec UPDATE memakai BGPsec_PATH sebagai pengganti AS_PATH konvensional, lalu AS yang berpartisipasi memperpanjang rantai Secure_Path dan Signature Segment saat route bergerak di antara peer eksternal yang mendukung BGPsec.

Keamanan Siber 23 Sep 2026 4 min read

BGP Roles dan OTC Membatasi Propagasi Route Leak

Sebuah rute BGP dapat memiliki origin yang valid tetapi tetap bergerak melampaui cakupan yang dimaksudkan oleh network yang menukarkannya. Perbedaan ini penting karena otorisasi origin dan kontrol route leak memeriksa properti yang berbeda. RFC 7908 mendefinisikan route leak sebagai propagasi routing announcement melampaui cakupan yang dimaksudkan, umumnya bertentangan dengan kebijakan yang terkait hubungan customer, provider, atau peer. RFC 9234 menambahkan mekanisme protokol untuk konteks hubungan tersebut. BGP Roles menyatakan hubungan pada sesi eBGP, sedangkan atribut Only to Customer, disingkat OTC, menandai rute yang propagasi berikutnya dibatasi. Mekanisme ini menargetkan kebijakan propagasi rute; mekanisme tersebut tidak mengubah BGP menjadi protokol path yang diautentikasi secara kriptografis.

Keamanan Siber 22 Sep 2026 4 min read

X-Content-Type-Options Memblokir MIME Type Sniffing

X-Content-Type-Options Memblokir MIME Type Sniffing Response HTTP membawa header Content-Type yang menjelaskan media type representasi. Browser juga memiliki riwayat menginferensikan tipe dari byte response ketika tipe yang dideklarasikan tidak ada, keliru, atau ambigu. Inferensi tersebut dapat membantu konten lama, tetapi juga menciptakan batas eksekusi yang mungkin tidak dimaksudkan operator aplikasi. X-Content-Type-Options: nosniff mempersempit batas itu. Untuk request destination yang tercakup aturan pemeriksaan MIME browser, response harus memiliki tipe terdeklarasi yang dapat diterima dan tidak bergantung pada content sniffing. Header ini sederhana, tetapi efeknya bergantung pada nilai Content-Type yang benar di seluruh aplikasi.