Pada konferensi DEF CON di Las Vegas tahun ini, peneliti keamanan Marek Tóth mendemonstrasikan bagaimana aktor ancaman dapat menggunakan serangan clickjack untuk memicu dan membajak upacara otentikasi berbasis passkey secara diam-diam.
Pada intinya, ini adalah cerita tentang bagaimana pengelola kata sandi dapat dibohongi untuk membocorkan informasi login — baik kredensial tradisional seperti ID pengguna dan kata sandi maupun artefak semacam kredensial yang terkait dengan passkey — kepada aktor ancaman.
Tóth — peneliti yang menemukan eksploitasi ini — menyarankan bahwa pengelola kata sandi patut disalahkan, tetapi jawabannya lebih rumit dari itu.
Mengamankan sepenuhnya proses otomatis apa pun selalu merupakan hasil dari keamanan berlapis. Di sebagian besar kasus penggunaan yang memperhatikan keamanan digital, hampir tidak pernah ada solusi tunggal yang dapat menangkal peretas. Tergantung pada lapisan teknologi yang digabungkan untuk menyelesaikan suatu alur kerja (misalnya, login ke situs web), tanggung jawab keamanan proses itu dibagi oleh pihak-pihak yang mengendalikan setiap lapisan tersebut.
Ya, pengelola kata sandi adalah satu lapisan dalam menghentikan eksploitasi ini. Tetapi operator situs web dan pengguna akhir — pihak yang mengendalikan lapisan lain — harus menukar terlalu banyak keamanan demi kenyamanan agar eksploitasi ini dapat bekerja. Menyalahkan satu pihak tidak ada gunanya. Semua pihak di setiap lapisan harus mengambil tindakan.
Setiap musim panas, industri keamanan siber berkumpul di Las Vegas untuk konferensi Black Hat dan DEF CON yang berurutan, di mana para peneliti keamanan bergiliran mempresentasikan "temuan besar" mereka. Sepanjang tahun menuju acara tersebut, para peneliti ini bekerja untuk menemukan kerentanan baru yang belum dilaporkan. Semakin besar kerentanan dan semakin banyak pengguna yang terdampak, semakin besar perhatian (dan mungkin imbalan finansial) yang menanti seorang peneliti.
Tahun ini, beberapa peneliti mengumumkan segelintir masalah yang menantang anggapan superioritas passkey sebagai kredensial login.
Di ZDNET ini, saya telah banyak menulis tentang passkey dan mengapa, dari perspektif keamanan dan teknis, mereka jauh lebih baik daripada ID pengguna dan kata sandi (bahkan ketika faktor autentikasi tambahan dilibatkan).
Tiga ide besar di balik passkey adalah:
- Mereka tidak bisa ditebak seperti halnya kata sandi (yang sering kali bisa dan memang terjadi).
- Passkey yang sama tidak dapat digunakan kembali di berbagai situs web dan aplikasi (seperti halnya kata sandi).
- Anda tidak dapat dibohongi untuk membocorkan passkey Anda kepada aktor jahat (seperti halnya kata sandi).
Sayangnya, meskipun superior, pengalaman pengguna passkey sangat bervariasi dari satu situs web dan aplikasi (secara kolektif, "relying parties") ke yang lain sehingga passkey berisiko ditolak secara global oleh pengguna.
Namun, untuk melindungi diri Anda sebanyak mungkin (seringkali dari diri Anda sendiri), rekomendasi saya tetaplah: Manfaatkan passkey whenever memungkinkan.
Marek Tóth menemukan cara — di bawah kombinasi prasyarat teknis yang sangat spesifik — untuk membajak otentikasi berbasis passkey saat otentikasi tersebut sedang berlangsung.
Untuk memberikan nasihat yang tepat kepada pembaca ZDNET, saya selalu memeriksa ulang kebenaran dari setiap berita utama yang menantang kelayakan dan keamanan superior passkey. Berbagai laporan muncul dari Black Hat dan DEF CON tahun ini, yang mengutip potensi masalah dalam "surga" passkey. Yang paling mendapat perhatian datang dari Tóth, yang — di bawah kombinasi prasyarat teknis yang sangat spesifik — telah menemukan cara untuk membajak otentikasi berbasis passkey saat otentikasi tersebut sedang berlangsung.
Penelitian saya melibatkan komunikasi panjang dengan Tóth, pejabat dari FIDO Alliance (organisasi yang bertanggung jawab atas pengembangan dan promosi standar passkey), pengembang plugin turnkey yang memungkinkan situs web untuk otentikasi berbasis passkey, dan vendor berbagai pengelola kata sandi.
Mengapa pengelola kata sandi? Dari perspektif pengguna akhir, mustahil untuk terlibat dalam otentikasi berbasis passkey — secara teknis dikenal sebagai "upacara otentikasi" — tanpa bantuan pengelola kata sandi. Mereka memainkan peran kunci dalam temuan Tóth.
Adapun spesifikasi passkey FIDO2 Credential itu sendiri, Tóth mengatakan kepada saya, "Protokolnya sendiri mungkin aman. Saya belum mengujinya secara ekstensif, karena itu bukan fokus penelitian saya." Dengan kata lain, dia tidak menyarankan bahwa passkey itu sendiri tidak aman. Faktanya, penelitian Tóth juga mencakup ID pengguna dan kata sandi, dan temuan intinya pada dasarnya membuktikan bahwa kredensial tradisional tersebut jauh lebih dapat dieksploitasi daripada passkey yang dikonfigurasi dengan benar.
Namun, melalui kombinasi manajemen situs web yang ceroboh dan ketidakpedulian pengguna dalam mengonfigurasi pengelola kata sandi mereka dengan aman, terdapat peluang yang sebelumnya belum terungkap bagi aktor jahat untuk membajak upacara otentikasi berbasis passkey saat sedang berlangsung. Ini benar meskipun passkey itu sendiri tidak dapat dicuri.
Alih-alih menunjuk spesifikasi FIDO2 atau operator situs web yang ceroboh, Tóth terutama menyalahkan pengelola kata sandi, yang menurut pendapatnya, bisa melakukan lebih banyak untuk melindungi pengguna dari eksploitasi yang ditemukannya.
"Tidak, ini bukan hanya kesalahan operator situs web," tulis Tóth kepada saya melalui email. "Tetapi juga vendor pengelola kata sandi, karena kerentanannya ada di perangkat lunak mereka." Dalam sebuah tweet tempat Tóth merangkum beberapa temuan intinya, dia menyebutkan 12 pengelola kata sandi (termasuk semua yang populer) secara nama sebagai pihak yang rentan dalam satu atau lain tingkat. Vertigo3d/iStock/Getty Images Plus via Getty Images
Apakah berbagai manajer kata sandi memang rentan tergantung pada definisi Anda tentang "kerentanan." Tak satupun vendor manajemen kata sandi yang saya hubungi sepakat dengan klaim bahwa produk mereka memiliki celah keamanan. Namun, mengingat izin peramban yang agresif yang harus diberikan pengguna kepada manajer kata sandi saat instalasi (izin yang sama yang memungkinkannya mencegah penggunaan aplikasi SaaS tidak resmi), manajer kata sandi berada dalam posisi unik untuk mendeteksi dan mencegah ancaman ini serta lainnya sebelum kerusakan terjadi. Tidak mengherankan, beberapa manajer kata sandi merilis versi baru untuk mengatasi eksploit Tóth.
Inti Serangan
Meskipun eksploitasi terjadi dalam sekejap mata, ia melibatkan serangkaian interaksi dan prasyarat rumit yang, jika digabungkan, menjadi hambatan signifikan bagi peluang kesuksesan penyerang. Pada intinya, eksploit Tóth tidak pernah mencuri passkey pengguna (salah satu prinsip utama passkey adalah bahwa ia tidak bisa dicuri). Tetapi pada dasarnya, ia mencuri hal terbaik berikutnya.Pada saat pengguna terkecoh dan tidak sengaja mengautentikasi ke suatu situs web dengan passkey, eksploit tersebut menyadap muatan informasi yang dibuat oleh manajer kata sandi pengguna dengan bantuan passkey-nya ke situs tersebut. Seperti dijelaskan dalam bagian 5 serial saya tentang How Passkeys Actually Work, muatan ini disebut PublicKeyCredential, dan ia seperti tiket emas sekali pakai yang berisi semua yang diperlukan pengguna untuk masuk ke akun mereka di situs web legitimate. Begitu penyerang menguasai tiket emas ini, ia dapat digunakan untuk masuk ke sistem penyerang ke akun korban seolah-olah sistem penyerang adalah sistem korban. Juga: What really happens during your ‘passwordless’ passkey login? Dan itulah yang dilakukan eksploit ini.
Setelah memuat malware ke dalam peramban korban, eksploit tersebut — sebuah script cross-site (XSS) berbahaya — mencegat tiket emas itu dan, alih-alih menyajikannya untuk masuk ke situs legitimate (seperti yang biasanya dilakukan peramban pengguna atas permintaan manajer kata sandi), ia mengirimkannya ke situs web penyerang. Kemudian, dengan tiket emas itu di tangan, penyerang mengirimkan tiket yang sama dari sistem mereka sendiri ke situs web legitimate, sehingga efektif memasukkan sistem penyerang ke dalam akun pengguna di situs web legitimate tersebut.
Namun, seperti disebutkan sebelumnya, temuan Tóth bergantung pada pra-eksistensi beberapa kondisi yang melibatkan situs web terkait, pilihan pengguna akan manajer kata sandi, bagaimana mereka mengonfigurasinya, dan pilihan operator situs web akan teknologi untuk menambahkan kemampuan autentikasi dengan passkey. Baik Anda pengguna akhir, operator situs web, atau vendor manajer kata sandi, penting untuk memahami kondisi-kondisi ini karena, begitu Anda memahaminya, Anda juga akan memahami pertahanannya. Anda juga bisa menilai sendiri pihak mana di antara yang terlibat yang paling bertanggung jawab atas kerentanan ini.
Sementara Tóth menunjuk pada manajer kata sandi, saya percaya bahwa operator situs web akan paling disalahkan jika threat actor sungguhan menggunakan eksploit ini di dunia nyata. Kesampingkan sejenak tantangan membuat korban menemui malware (JavaScript cross-site berbahaya yang berjalan di peramban korban), ada dua pengaturan yang menggagalkan serangan yang harus diketahui setiap operator situs web profesional.
Juga: 3 reasons VPN use is set to explode worldwide – and that might apply to you
Ada momen selama upacara autentikasi passkey — setelah pengguna menunjukkan keinginan untuk masuk dengan passkey — ketika situs web merespons pengguna dengan sebuah challenge sebagai bagian dari muatan yang lebih besar disebut PublicKeyCredentialRequestOptions. Seperti setiap respons dari server web, respons itu juga menyertakan beberapa parameter yang dikenal sebagai header HTTP, salah satunya dapat digunakan untuk membangun sesi komunikasi tertentu dengan sistem klien menggunakan cookie yang dikodekan secara unik, dan kemudian mengonfigurasi cookie tersebut sebagai cookie HttpOnly.
Versi sederhana dari parameter header tersebut — yang dikenal sebagai parameter set-cookie — mungkin terlihat seperti ini (sebagai bagian dari transmisi yang lebih besar dari server web ke peramban pengguna):
Set-Cookie: session_id=123456789abcdefg; HttpOnlyKetika server web dikonfigurasi untuk menyertakan header seperti ini selama upaya autentikasi pengguna dengan passkey, ia secara permanen merekatkan challenge (dan sisa percakapan antara peramban pengguna dan server web) ke ID sesi yang ditentukan. Begitu sebuah challenge terikat ke ID sesi spesifik, server hanya akan menerima tiket emas yang dikemas dengan ID yang sama. Agar eksploit Tóth bekerja, sistem penyerang tidak hanya harus memiliki tiket emas yang disadap, tetapi juga harus mengetahui ID sesi yang tepat untuk digunakan saat menyajikan tiket itu ke server web legitimate.
Di sinilah parameter HttpOnly berperan. Ketika header set-cookie menyertakan parameter ini (seperti yang ditunjukkan di atas), ia seperti jubah tembus pandang ajaib. ID sesi menjadi tidak terlihat oleh JavaScript apa pun — legitimate atau berbahaya — yang mungkin berjalan di peramban pengguna. Akibatnya, jika JavaScript itu kebetulan berbahaya, ia tidak dapat melakukan apa yang dilakukan eksploit Tóth; ia tidak dapat menemukan ID sesi, dan juga tidak dapat menyertakannya dengan tiket emas yang disadap yang diteruskannya ke sistem penyerang. Jadi, bahkan jika JavaScript berbahaya meneruskan tiket emas yang disadap ke sistem penyerang, itu akan sia-sia bagi penyerang tanpa ID sesi yang hilang.
Juga: How I easily set up passkeys through my password manager – and why you should too
Selama berabad-abad, "pengikatan-sesi" (session-binding) dari percakapan autentikasi (terkait passkey atau tidak) antara situs web dan peramban pengguna akhir telah dianggap sebagai garis pertahanan utama terhadap serangan semacam ini. Gambar dari Vertigo3d/iStock/Getty Images Plus via Getty Images
Kegagalan operator situs web untuk mengunci proses autentikasinya dengan praktik terbaik yang sederhana dan terkenal ini akan dipandang oleh sebagian besar profesional keamanan siber sebagai kelalaian yang sangat serius.
Banyak Pihak yang Turut Bersalah
Namun dalam wawancara saya dengan Tóth, ia juga menyalahkan dua kelompok lain: penyedia solusi yang menjual plug-in yang digunakan oleh relying parties untuk menambahkan dukungan passkey ke situs web mereka, dan FIDO Alliance, organisasi yang bertanggung jawab atas pengembangan, promosi, dan adopsi passkey.Dalam penelitiannya, Tóth mencatat bahwa, dari tujuh solusi plug-in yang diujinya, empat "tidak mengimplementasikan ‘session-bound challenge‘, [sehingga] membuat serangan ini dapat diexploit." Dengan kata lain, jika operator situs web memasang salah satu dari keempat pustaka tersebut (dari Hanko, SK Telecom, NokNok, atau Authsignal) dan membiarkannya dalam keadaan default, itu akan setara dengan mengabaikan praktik terbaik.
Tóth juga merasa tidak percaya bahwa FIDO Alliance memasukkan keempat solusi tersebut dalam showcase online-nya untuk solusi bersertifikat FIDO. Menurut Tóth, mengabaikan praktik terbaik yang dikenal luas dan menggunakan default challenge yang tidak terikat sesi seharusnya mendiskualifikasi plug-in dari sertifikasi FIDO. FIDO Alliance tidak setuju.
CTO FIDO Alliance, Nishant Kaushik, mengatakan kepada saya:
"Mengenai empat perusahaan yang Anda tunjuk karena tidak menggunakan session binding, perlu dicatat bahwa peneliti menguji situs demo yang digunakan perusahaan-perusahaan ini untuk memamerkan pengalaman pengguna yang diberikan produk mereka. Situs demo biasanya tidak akan dikeraskan dengan cara yang sama seperti implementasi sebenarnya."Kaushik melanjutkan dengan membahas pentingnya session binding, dengan mengatakan bahwa situs passkeycentral.org yang dioperasikan FIDO Alliance memuat tulisan yang menunjukkan bahwa "FIDO Alliance telah jelas menyatakan bahwa session-binding ‘sangat penting’ untuk mencegah session hijacking." Namun, artikel tersebut merujuk pada teknik cryptographic session-binding seperti Device Bound Session Credentials (DBSC) dan Demonstrating Proof of Possession (DPoP), dan gagal menyebutkan praktik terbaik yang jauh lebih sederhana dan telah dipublikasikan secara luas, yaitu session-binding dengan header set cookie.
Selain itu, sementara FIDO Alliance membela sertifikasinya dan pada dasarnya menyatakan bahwa tidak ada yang akan benar-benar menerapkan plug-in dengan cara seperti yang dilakukan Tóth, CEO dari salah satu plug-in tersebut bersikap jauh lebih tulus, rekonsiliatif, dan mengakui kesalahan, sehingga mempertanyakan keakuratan tanggapan Kaushik.
"Kami menyadari masalahnya dan tim kami sedang aktif mengerjakan perbaikan," kata CEO Hanko.io, Felix Magedanz. "Implementasi passkey adalah salah satu komponen paling awal Hanko. Meskipun sejak itu kami telah menambahkan fungsionalitas seperti session dan manajemen pengguna, celah tetap ada dalam cara alur WebAuthn terikat ke sesi pengguna. Kami menangani ini dengan prioritas tertinggi dan akan segera merilis versi Hanko yang diperbarui."
Sementara perbaikan datang dari Hanko.io (dan mungkin lainnya), sangat jelas bahwa tanggung jawab ada pada relying parties untuk menerapkan session binding secara bertanggung jawab guna melindungi pengguna akhir mereka dengan lebih baik.
Lapisan demi Lapisan
Tetapi mari asumsikan, seperti yang dilakukan Tóth, bahwa operator situs web telah secara katastropik mengabaikan salah satu teknik terpenting dan terkenal untuk mengamankan alur kerja autentikasi. Eksploitasi Tóth masih melibatkan beberapa prasyarat lain yang tidak sepele.Yang pertama melibatkan pemasangan script jahat ke dalam web browser Anda. Dengan menunjuk pada postingan HackerOne 2019 yang mendokumentasikan keberadaan XSS jahat di PayPal, Tóth mengatakan bahwa pengguna akhir harus berasumsi bahwa bahkan situs web yang paling terkemuka dan dianggap terlindungi dengan baik dapat menjadi sumber script jahat seperti itu. Dalam percakapan saya dengannya, ia mencatat bahwa situs-situs yang menyertakan banyak konten yang dibuat pengguna menjadi target favorit pelaku ancaman karena mereka dapat menambahkan script ke sebuah pos atau ulasan dan, jika situs tersebut tidak memiliki perlindungan yang memadai untuk menolak entri semacam itu (tindakan kelalaian lain dari operator situs), yang harus dilakukan pengguna yang tidak bersalah hanyalah mengunjungi pos atau ulasan itu untuk menjalankan script jahat tersebut.
Dengan asumsi seorang pengguna secara tidak sengaja menemukan situs seperti itu dan memuat script jahat ke dalam browser-nya, script tersebut harus secara diam-diam menipu pengguna untuk secara tidak sengaja meluncurkan upacara autentikasi dengan jenis serangan yang dikenal sebagai serangan clickjack. Seperti namanya, serangan clickjack terjadi ketika pelaku ancaman menipu Anda untuk mengklik elemen yang dapat diklik (mis., tombol atau tautan) yang mungkin tidak terlihat oleh Anda.
Dalam eksploitasi Tóth, JavaScript jahat menutupi jendela browser dengan dialog yang tampaknya tidak berbahaya seperti iklan pop-up atau formulir persetujuan cookie — hal semacam yang sering kita lihat dan ingin kita singkirkan dari layar. Namun, ketika kita mengklik elemen itu untuk menghilangkannya, yang tidak kita sadari adalah bahwa kita sebenarnya mengklik sesuatu yang lain yang disembunyikan di belakangnya. Licik, bukan? Pada saat itu, klik mouse Anda pada dasarnya telah dibajak. Tetapi apa yang sebenarnya Anda klik?
Dalam proof-of-concept Tóth, script jahatnya melibatkan formulir login tersembunyi, yang pada gilirannya memicu password manager Anda untuk bertindak (seperti yang biasanya dilakukan password manager ketika mereka mendeteksi kehadiran formulir login). Kemudian, klik yang dibajaknya adalah klik yang menginstruksikan password manager untuk menyiapkan golden ticket untuk dikirim kembali ke situs web yang sah. Secara teoretis, karena formulir login disembunyikan dari pandangan, Anda bahkan tidak menyadari bahwa Anda baru saja menyelesaikan upacara autentikasi passkey.
Setelah password manager menyiapkan tiket itu untuk transmisi, script jahat mencegatnya dan, alih-alih mengirimkannya (dengan perintah HTTP POST) ke server yang sah, ia mengirimkannya via HTTP POST ke server penyerang seperti yang dijelaskan sebelumnya.
Tetapi, seperti yang baru saja disarankan, serangan itu tidak mungkin terjadi tanpa keterlibatan password manager pengguna. Jadi, apa — jika ada — yang dapat dilakukan oleh password manager untuk mengurangi serangan ini?
Keuntungan dan Kerugian Pengingat yang Terus-Menerus
Ketika pendukung menggambarkan passkey sebagai lebih aman daripada kredensial tradisional, mereka sering berbicara tentang bagaimana proses passkey sesederhana masuk ke ponsel Anda dengan biometrik (sidik jari, Face ID, dll.) atau kode PIN. Misalnya, di salah satu halaman dukungannya, Microsoft menyatakan, "Passkeys adalah pengganti kata sandi Anda." Dengan passkey, Anda bisa masuk ke akun pribadi Microsoft atau akun kerja/sekolah menggunakan wajah, sidik jari, atau PIN. Bahkan situs passkeycentral.org yang dioperasikan FIDO Alliance menyatakan, "Passkey adalah kredensial autentikasi FIDO berbasis standar FIDO, yang memungkinkan pengguna masuk ke aplikasi dan situs web dengan langkah sama seperti membuka kunci perangkat (biometrik, PIN, atau pola)" — seolah-itu selalu terjadi.Pendukung passkey lainnya juga menggunakan bahasa serupa di situs mereka sehingga terdengar seperti setiap kali autentikasi dengan passkey, Anda harus menyediakan biometrik atau PIN untuk menyelesaikan prosesnya (mirip dengan login ke aplikasi seluler yang meminta sidik jari). Namun, ini terutama terjadi ketika pengelola kata sandi Anda juga dikonfigurasi untuk meminta biometrik atau PIN setiap kali percobaan otentikasi.
Karena beberapa pengguna tidak ingin terus diganggu dengan lapisan keamanan tambahan setiap kali login, kebanyakan pengelola kata sandi memberikan opsi untuk mengurangi notifikasi ini. Dengan kata lain, Anda dapat mengaturnya untuk selalu memverifikasi, sesekali, atau tidak pernah.
Eksploitasi Tóth bergantung pada pengguna yang tertipu untuk melakukan otentikasi tanpa disadari. Serangan ini menyembunyikan semua isyarat visual bahwa suatu otentikasi sedang berlangsung agar pengguna tidak waspada terhadap aktivitas mencurigakan. Jika pengelola kata sandi Anda dikonfigurasi seperti milik saya — untuk meminta PIN atau biometrik agar setiap upaya otentikasi dapat dilanjutkan — Anda akan langsung menyadari bahwa ada yang tidak beres.
Misalnya, jika serangan clickjack meminta Anda mengeklik tombol "Terima" pada formulir persetujuan cookie, tetapi kemudian pengelola kata sandi tiba-tiba meminta sidik jari atau PIN, itu harus menjadi tanda bahaya yang jelas untuk tidak melanjutkan. Formulir persetujuan cookie tidak memerlukan sidik jari Anda.
Dengan mengatur pengelola kata sandi untuk lebih agresif meminta verifikasi, Anda pada dasarnya menambahkan tombol jeda dalam proses autentikasi. Ini memberi kesempatan untuk memastikan bahwa tindakan yang dilakukan memang sesuai dengan yang Anda inginkan. Memilih pengaturan yang lebih longgar sama saja dengan melepas lapisan keamanan penting yang seharusnya dikendalikan pengguna.
Tóth setuju dengan penilaian ini namun mencatat bahwa banyak pengguna mungkin tidak menyadari bahwa beberapa pengelola kata sandi secara default menggunakan pengaturan yang lebih permisif selama instalasi. Ini poin yang valid. Tapi ini juga pengingat bahwa dalam menjalankan praktik opsec (keamanan operasional) pribadi yang baik, pengguna harus secara proaktif mengambil tindakan pencegahan setelah mempelajari opsi keamanan yang tersedia.
Opsi Terakhir
Bahkan ketika pengguna lalai mengamankan pengaturannya, operator situs web memiliki opsi khusus yang dapat digunakan. Selain membuat setiap sesi autentikasi terikat dan menerapkan tindakan pencegahan untuk menghalangi aktor ancaman memasang JavaScript berbahaya di browser, pihak relying party juga berwenang untuk mengabaikan preferensi pengguna terkait kapan pengelola kata sandi meminta biometrik, PIN, atau kata sandi.
Ketihak pihak relying party mengirimkan tantangan kepada pengelola kata sandi sebagai bagian dari payload PublicKeyCredentialRequestOptions, mereka dapat menyertakan parameter khusus yang disebut userVerification. Parameter ini memiliki tiga pengaturan: Discouraged, Preferred, dan Required. Jika diatur ke "Required", pengelola kata sandi wajib meminta verifikasi pengguna — terlepas dari konfigurasi yang dipilih pengguna.
Dengan kata lain, operator situs web dapat memaksa pengguna untuk mendapatkan prompt verifikasi yang seharusnya membuat mereka waspada terhadap perilaku situs web yang tidak biasa. Ada satu kemungkinan yang membuat opsi ini tidak efektif: bagaimana jika pengelola kata sandi tidak menghormati opsi "Required" yang ditentukan? Namun, dari beberapa penyedia yang diuji (1Password, BitWarden, LastPass, dan NordPass), semua menunjukkan bahwa mereka mematuhi pengaturan "Required" ketika ditentukan sebagai bagian dari payload.
Waspada dan Laporkan
Sebagai pengguna akhir, Anda hampir tidak memiliki kendali atas situs yang dikunjungi. Anda bergantung pada keyakinan buta bahwa mereka melakukan yang terbaik untuk menghentikan serangan semacam ini — tetapi Anda tak pernah bisa benar-benar yakin. Di sisi lain, login ke begitu banyak situs dengan pengaturan verifikasi paling ketat bisa sangat merepotkan, dan Anda mungkin bertanya-tanya apakah ada jaring pengaman alternatif.
Untuk menjawabnya, kita perlu kembali ke pengelola kata sandi. Ternyata, agar pengelola kata sandi dapat berfungsi, Anda harus memberikannya izin yang seharusnya hampir tidak pernah diberikan kepada ekstensi browser lain. Pengelola kata sandi tidak hanya dapat membaca semua konten halaman web yang dikunjungi, tetapi juga memodifikasinya.
Karena izin tersebut, pengelola kata sandi Anda juga dapat mendeteksi tanda-tanda serangan clickjack yang sedang berlangsung. Misalnya, untuk melakukan tugasnya (seperti mengisi otomatis ID dan kata sandi), pengelola kata sandi harus mendeteksi kehadiran formulir login. Namun, karena ia dapat mem-parsing setiap bit HTML yang membangun halaman web, ia juga dapat mengambil tindakan jika mendeteksi formulir login yang disembunyikan dari pandangan atau ditimpa oleh objek yang dapat diklik — ciri khas serangan clickjack.
Meskipun tidak menghubungi semua vendor pengelola kata sandi, saya melakukan pengecekan secara acak pada beberapa penyedia. Tidak mengherankan, versi-versi terbaru dari perangkat lunak mereka sedang dalam pengerjaan atau telah dirilis. "Bitwarden telah menerapkan mitigasi untuk jenis serangan ini dalam rilis paling anyar pekan lalu," menurut direktur komunikasi BitWarden, Mike Stolyar. "Pembaruan terkini memperkenalkan pengaman yang menonaktifkan isi-otomatis inline ketika gaya situs menunjukan potensi manipulasi, seperti lapisan tersembunyi atau perubahan opasitas."
Melalui email, CISO 1Password, Jacob DePriest, menyampaikan bahwa "pada 20 Agustus 2025, kami merilis versi 8.11.7, yang menambahkan opsi bagi pengguna untuk diberi notifikasi dan menyetujui atau menolak tindakan isi-otomatis sebelum itu terjadi. Ini memperluas peringatan konfirmasi yang sudah ada untuk informasi pembayaran, sebuah peringatan yang tidak dapat disembunyikan atau ditindih oleh clickjacking, memberikan pengguna visibilitas dan kontrol lebih besar sebelum segala sesuatu diisi."
"Ikon-ikon NordPass sekarang dirender dengan z-index tertinggi, mencegah apapun untuk ditampung di atasnya," ujar kepala produk bisnis NordPass, Karolis Arbaciauskas. "Kini juga tidak mungkin untuk mengubah atribut gaya dialog, yang sebelumnya memungkinkan dialog dibuat tak terlihat."
LastPass juga telah memperkuat pertahanannya terhadap potensi serangan clickjack. Pembaruan terbaru "adalah untuk mendeteksi tipe elemen dengan opasitas nol dan tidak [mengisi-otomatis]," kata direktur manajemen produk LastPass, Greg Armanini. Ketika ditanya apakah LastPass memberikan peringatan kepada pengguna tentang perilaku berisiko potensial yang mungkin diamati di halaman web saat ini, Armanini menjawab bahwa "dalam rilis pertama, itu akan tampak seolah-olah tidak terjadi apa-apa." Tapi, [jika kami memutuskan untuk membawa perbaikan selangkah lebih maju], itu mungkin akan mirip dengan yang sudah kami lakukan untuk kartu kredit Anda, yaitu sebuah prompt yang mengatakan ‘Sebelum Anda melakukan ini, pastikan Anda mempercayai situs ini.’"
Sementara itu, Tóth memantau berbagai password manager untuk melihat bagaimana pembaruan mereka — beberapa sudah diterapkan, yang lain masih akan datang — berhasil dengan metodologi ujinya. Dia juga dengan cepat menunjukan bahwa pembaruan saja tidak akan membantu kecuali pengguna memasang pembaruan tersebut. Selama pengguna tetap pada versi lama password manager mereka, mereka dapat menjadi mangsa dari serangan clickjack opasitas nol.
Akhirnya, terlepas dari potensi ancaman seorang threat actor untuk membajak upacara otentikasi passkey setelah prasyarat non-sepele terpenuhi, eksploitasi Tóth menawarkan bukti tambahan bahwa passkey lebih aman daripada kredensial tradisional. Session-binding membuat golden ticket yang dihasilkan passkey satu waktu tidak dapat digunakan dari sistem penyerang. Namun, itu tidak melakukan apa pun untuk menghentikan eksfiltrasi ID dan kata sandi pengguna oleh threat actor ketika serangan clickjack Tóth menemukan upaya untuk mengautentikasi dengan kredensial tradisional tersebut versus passkey yang lebih sensitif terhadap waktu dan aman.