+− THE DAILY DIFFdev & AI news
REVERT

SAML, bên trong: chữ ký bên trong bức thư

SAML đăng nhập bạn vào hầu hết mọi ứng dụng công việc, và chữ ký của nó nằm bên trong XML mà nó ký.

SAML đăng nhập bạn vào hầu hết mọi ứng dụng công việc, và chữ ký của nó nằm bên trong XML mà nó ký. Bên trong: quy trình đăng nhập giữa ứng dụng, trình duyệt và nhà cung cấp danh tính, một xác nhận trông như thế nào, tại sao chuẩn hóa phải đồng ý trên từng byte, và tại sao cùng một loại lỗi cứ quay trở lại từ năm 2012 đến 2025. Được gợi ý bởi "SAML: A fractal of bad design" của Trail of Bits (312 điểm trên Hacker News).

Đọc phiên bản viết (tiếng Anh) ↗

Nội dung video này đề cập

  • SAML: đăng nhập tự ký từ bên trong
  • 2002: bốn định dạng XML, một ủy ban, cả một ngành công nghiệp
  • Quy trình đăng nhập: ứng dụng → nhà cung cấp danh tính → quay lại qua trình duyệt của bạn
  • Xác nhận: chữ ký nằm bên trong thứ nó ký
  • Chuẩn hóa: đồng ý trên từng byte, hoặc không ai đăng nhập được

Bản ghi đã dịch

Được dịch từ lời tường thuật tiếng Anh gốc. Âm thanh và phụ đề có sẵn được điều khiển bởi YouTube.

SAML: đăng nhập tự ký từ bên trong

0:00 SAML là XML giúp bạn đăng nhập vào hầu hết mọi ứng dụng công việc của bạn, và chữ ký của nó nằm bên trong tài liệu mà nó ký, như một công chứng viên đóng dấu bên trong phong bì anh ta đang niêm phong. Mười năm sau khi một ủy ban viết nó, các nhà nghiên cứu đã thử nghiệm mười bốn khung Saml Mười một thất bại. Và tuần này, một bài đăng của Trail of Bits gọi nó là một fractal của thiết kế tồi đã lên trang nhất của Hacker News. Trong ba phút: cách quy trình đăng nhập hoạt động, chữ ký ẩn ở đâu,

0:27 và tại sao giải pháp mọi người đồng ý lại là một giao thức khác. Đây là The Daily Diff, bên trong.

2002: bốn định dạng XML, một ủy ban, cả một ngành công nghiệp

0:34 Năm 2002. Một ủy ban bảo mật tại Oasis hợp nhất bốn định dạng XML của nhà cung cấp thành một. Các trường đại học áp dụng nó trước, sau đó Okta xây dựng một công ty dựa trên nó, tài liệu của ủy ban nhanh nhất từng biến thành doanh thu. Bạn mở ứng dụng.

Quy trình đăng nhập: ứng dụng → nhà cung cấp danh tính → quay lại qua trình duyệt của bạn

0:46 Nó không biết bạn là ai, vì vậy nó chuyển trình duyệt của bạn đến nhà cung cấp danh tính, ví dụ như Okta của công ty bạn. Bạn đăng nhập vào đó. Okta đưa cho trình duyệt của bạn một tài liệu XML đã ký nói bạn là ai, và trình duyệt gửi nó trở lại.

Xác nhận: chữ ký nằm bên trong thứ nó ký

0:59 Tài liệu đó là xác nhận. Nó nêu tên người dùng, và chữ ký nằm bên trong nó, trỏ lại xác nhận bằng ID của nó. Và toàn bộ việc này đi qua trình duyệt của bạn, tức là, qua người dùng. Để kiểm tra nó, ứng dụng

Chuẩn hóa: đồng ý trên từng byte, hoặc không ai đăng nhập được

1:11 xây dựng lại chính xác các byte đã được ký. Nó cắt bỏ chữ ký, chuẩn hóa khoảng trắng và thứ tự thuộc tính, và băm kết quả. Đó là chuẩn hóa, và nếu hai bên không đồng ý dù chỉ một byte, không ai đăng nhập được. Một mã thông báo web JSON thực hiện khác. Tiêu đề, tải trọng và chữ ký nằm cạnh nhau với các dấu chấm ở giữa. Không có gì để cắt bỏ trước.

2012: trình kiểm tra và trình đọc nhìn vào các phần tử khác nhau

1:32 Đây là vấn đề. Mã kiểm tra chữ ký và mã đọc tên người dùng thường là hai phần khác nhau. Năm 2012, một bài báo có tên On Breaking Saml cho thấy bạn có thể di chuyển xác nhận đã ký đến nơi trình đọc bỏ qua nó, và đặt một cái thứ hai nơi nó tìm kiếm. Salesforce và Shibboleth nằm trong số mười một cái bị lừa. Năm 2018, Duo cho thấy một bình luận bên trong tên người dùng có thể khiến một số

2018 và 2025: hai trình phân tích cú pháp, hai câu trả lời khác nhau

1:55 thư viện chỉ đọc một nửa tên, trong khi chữ ký vẫn hợp lệ. Năm 2025, GitHub tìm thấy hai trình phân tích cú pháp XML bên trong ruby Saml không đồng ý về cùng một tài liệu. Cùng một lỗi, thập kỷ mới. Trail of Bits gọi nó là một fractal, vì mọi cấp độ bạn phóng to đều có

Tại sao nó cứ hỏng: một fractal của thiết kế tồi

2:12 cùng một lỗi. Nó được xây dựng trên XML, chữ ký được bao bọc, và các lần đăng nhập thực tế chỉ sử dụng khoảng một phần mười của đặc tả. Và phản hồi hàng đầu trên Hacker News đến từ người mua. Nếu bạn không có hỗ trợ Saml, tôi có thể tìm một sản phẩm có. Cả hai đều đúng, đó là vấn đề. Vậy, thứ Hai. SHIP IT OpenID Connect trước, Fly và Tailscale bán cho

Thứ Hai: OIDC trước, một thư viện được duy trì, các hình dạng nghiêm ngặt

2:31 các doanh nghiệp mà không cần Saml chút nào. Nếu khách hàng yêu cầu, hãy sử dụng một thư viện được duy trì, giữ nó được vá, và từ chối các tin nhắn không giống những gì Okta hoặc Google gửi. Không bao giờ tự viết kiểm tra chữ ký của bạn.

Phán quyết, bên trong: REVERT

2:43 Phán quyết, bên trong. REVERT. Gần hai mươi lăm năm, một loại lỗi không bao giờ chết, và giải pháp mọi người đồng ý là một giao thức khác. Thứ Bảy tuần trước tôi đã tháo passkeys, vậy hãy cho tôi biết nên mở cái gì tiếp theo trong bình luận. Và đó là The Daily Diff hôm nay. Tôi là Niko từ Axrisi. Hợp nhất một cách có trách nhiệm.

Nguồn

  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

Video liên quan