SAML, di balik layar: tanda tangan di dalam surat

Isi video ini

• SAML: login yang menandatangani dirinya sendiri dari dalam
• 2002: empat format XML, satu komite, seluruh industri
• Tarian login: aplikasi → penyedia identitas → kembali melalui browser Anda
• Pernyataan: tanda tangan ada di dalam apa yang ditandatanganinya
• Kanonisasi: menyepakati setiap byte, atau tidak ada yang bisa login

Transkrip terjemahan

Diterjemahkan dari narasi asli bahasa Inggris. Audio dan teks tersedia yang dikontrol oleh YouTube.

SAML: login yang menandatangani dirinya sendiri dari dalam

0:00 SAML adalah XML yang membuat Anda masuk ke hampir setiap aplikasi kerja yang Anda miliki, dan tanda tangannya ada di dalam dokumen yang ditandatanganinya, seperti notaris yang menyematkan stempelnya di dalam amplop yang dia segel. Sepuluh tahun setelah sebuah komite menulisnya, para peneliti menguji empat belas kerangka kerja SAML. Sebelas di antaranya gagal. Dan minggu ini sebuah postingan Trail of Bits yang menyebutnya sebagai "fraktal" desain yang buruk menjadi berita utama di Hacker News. Dalam tiga menit: bagaimana tarian login bekerja, di mana tanda tangan bersembunyi,

0:27 dan mengapa perbaikan yang disepakati semua orang adalah protokol yang berbeda. Ini The Daily Diff, di balik layar.

2002: empat format XML, satu komite, seluruh industri

0:34 Dua ribu dua. Sebuah komite keamanan di Oasis menggabungkan empat format XML vendor menjadi satu. Universitas mengadopsinya terlebih dahulu, lalu Okta membangun perusahaan di atasnya, dokumen komite tercepat yang pernah menghasilkan pendapatan. Anda membuka aplikasi.

Tarian login: aplikasi → penyedia identitas → kembali melalui browser Anda

0:46 Aplikasi tidak tahu siapa Anda, jadi aplikasi mengalihkan browser Anda ke penyedia identitas, katakanlah Okta perusahaan Anda. Anda masuk di sana. Okta memberikan dokumen XML yang ditandatangani kepada browser Anda yang menyatakan siapa Anda, dan browser mempostingnya kembali.

Pernyataan: tanda tangan ada di dalam apa yang ditandatanganinya

0:59 Dokumen itu adalah pernyataan. Dokumen itu menyebutkan nama pengguna, dan tanda tangan ada di dalamnya, menunjuk kembali ke pernyataan berdasarkan ID-nya. Dan semuanya berjalan melalui browser Anda, yang berarti, melalui pengguna. Untuk memeriksanya, aplikasi

Kanonisasi: menyepakati setiap byte, atau tidak ada yang bisa login

1:11 membangun kembali byte persis yang ditandatangani. Aplikasi memotong kembali tanda tangan, menormalisasi spasi putih dan urutan atribut, dan "menghash" hasilnya. Itu kanonisasi, dan jika kedua belah pihak tidak setuju bahkan dengan satu byte pun, tidak ada yang bisa login. Token web JSON melakukannya secara berbeda. Header, payload, dan tanda tangan berdampingan dengan titik di antaranya. Tidak ada yang perlu dipotong terlebih dahulu.

2012: pemeriksa dan pembaca melihat elemen yang berbeda

1:32 Inilah celahnya. Kode yang memeriksa tanda tangan dan kode yang membaca nama pengguna seringkali merupakan dua bagian yang berbeda. Pada dua ribu dua belas, sebuah makalah berjudul On Breaking SAML menunjukkan bahwa Anda dapat memindahkan pernyataan yang ditandatangani ke tempat yang diabaikan oleh pembaca, dan meletakkan yang kedua di tempat yang dicari. Salesforce dan Shibboleth termasuk di antara sebelas yang jatuh untuk itu. Pada dua ribu delapan belas, Duo menunjukkan bahwa komentar di dalam nama pengguna dapat membuat beberapa

2018 dan 2025: dua parser, dua jawaban berbeda

1:55 pustaka membaca hanya setengah nama, sementara tanda tangan masih valid. Pada dua ribu dua puluh lima, GitHub menemukan dua parser XML di dalam Ruby SAML tidak setuju tentang dokumen yang sama. Bug yang sama, dekade baru. Trail of Bits menyebutnya fraktal, karena setiap level yang Anda perbesar memiliki

Mengapa terus rusak: "fraktal" desain yang buruk

2:12 cacat yang sama. Ini dibangun di atas XML, tanda tangan "terbungkus", dan login sebenarnya hanya menggunakan sepersepuluh dari spesifikasi. Dan balasan teratas di Hacker News berasal dari pembeli. Jika Anda tidak memiliki dukungan SAML, saya dapat menemukan produk yang memilikinya. Keduanya benar, itulah masalahnya. Jadi, Senin. Kirim OpenID Connect terlebih dahulu, Fly dan Tailscale menjual ke

Senin: OIDC dulu, pustaka yang terawat, bentuk yang ketat

2:31 perusahaan tanpa SAML sama sekali. Jika pelanggan memaksanya, gunakan pustaka yang terawat, jaga agar tetap diperbarui, dan tolak pesan yang tidak terlihat seperti yang dikirim Okta atau Google. Jangan pernah menulis pemeriksaan tanda tangan Anda sendiri.

Keputusan, di balik layar: REVERT

2:43 Keputusan, di balik layar. REVERT. Hampir dua puluh lima tahun, satu kelas bug yang tidak pernah mati, dan perbaikan yang disepakati semua orang adalah protokol yang berbeda. Sabtu lalu saya membongkar "passkey", jadi beri tahu saya apa yang harus saya bongkar selanjutnya di kolom komentar. Dan itulah "diff" untuk hari ini. Saya Niko dari Axrisi. Gabungkan secara bertanggung jawab.

Sumber

1. Trail of Bits, "SAML: A fractal of bad design" (Matt Schwager, Sep 21, 2026)blog.trailofbits.com
2. Hacker News threadnews.ycombinator.com
3. Somorovsky et al., "On Breaking SAML: Be Whoever You Want to Be", USENIX Security 2012www.usenix.org
4. Duo Labs, SAML vulnerabilities affecting multiple implementations (2018): https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations · CERT VU#475445www.kb.cert.org
5. GitHub Security Lab, "Sign in as anyone: Bypassing SAML SSO authentication with parser differentials" (Mar 12, 2025)github.blog