Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã Base64
Cách xây dựng và giải mã tiêu đề xác thực cơ bản HTTP bằng Base64
· Cách thức hoạt động
base64 bảo vệ
Tiêu đề Authorization: Basic chỉ là tên người dùng: mật khẩu chạy qua Base64. Bài đăng này cho biết cách tạo giá trị, cách giải mã một giá trị từ nhật ký yêu cầu và lý do mã hóa không ẩn giấu điều gì.
401 vẫn tồn tại mặc dù thông tin xác thực là đúng — một giá trị tiêu đề giải mã thành một chuỗi hơi sai
HTTP API trả về 401 Không được phép và yêu cầu tiêu đề Ủy quyền: Cơ bản. Giá trị là từ lược đồ Cơ bản, một khoảng trắng và chuỗi Base64. Tiền tố bị thiếu, tiền tố được mã hóa hoặc dòng mới không được chú ý sẽ thay đổi những gì máy chủ nhận được ngay cả khi tên người dùng và mật khẩu hiển thị có vẻ chính xác.
Giải mã chuỗi đó và nó đọc tên người dùng: mật khẩu (nghĩa đen là dấu hai chấm giữa hai). Tên người dùng: mật khẩu byte được mã hóa UTF-8 sau đó được mã hóa Base64, tạo ra giá trị tiêu đề. Nếu thông tin đăng nhập là quản trị viên:s3cret, UTF-8 byte là 0x61 0x64 0x6D 0x69 0x6E 0x3A 0x73 0x33 0x63 0x72 0x65 0x74 (ASCII chữ cái và dấu hai chấm), mã hóa Base64 tạo ra YWRtaW46czNjcmV0 và tiêu đề là Giấy phép: Cơ bản YWRtaW46czNjcmV0.
Công thức từ RFC 7617: 'user:pass', UTF-8, Base64 — các bước chính xác và vai trò của dấu hai chấm
Điều này đã hoàn tất HTTP Lược đồ xác thực cơ bản được xác định trong RFC 7617. Nó đơn giản, được tiêu chuẩn hóa và không có tính bảo mật: bất kỳ ai đọc tiêu đề đều có thể giải mã ngay lập tức để đọc mật khẩu. Đây là lý do tại sao HTTPS là bắt buộc đối với xác thực cơ bản. Mã hóa là yêu cầu vận chuyển chứ không phải tính năng bảo mật. Mật khẩu di chuyển dưới dạng UTF-8 byte, giống như mọi dữ liệu khác; Base64 chỉ là ký hiệu được sử dụng trong giao thức HTTP.
Nếu cần giải mã tiêu đề Cơ bản từ nhật ký mạng, quy trình rất đơn giản: loại bỏ phần còn lại của Cơ bản, giải mã Base64 và bạn có tên người dùng:mật khẩu. Dấu hai chấm là dấu phân cách giữa tên người dùng và mật khẩu. RFC 7617 chỉ định thông tin xác thực là user-id : mật khẩu và dấu hai chấm đầu tiên là dấu phân cách. Nếu mật khẩu chứa dấu hai chấm thì dấu hai chấm thứ hai chỉ là một ký tự khác trong mật khẩu. Dấu hai chấm có tính cấu trúc vì người nhận cần một ranh giới rõ ràng. Nó tìm kiếm dấu hai chấm đầu tiên sau khi giải mã; mọi thứ trước nó xác định người dùng và mọi thứ sau nó là mật khẩu. Do đó, dấu hai chấm bị thiếu cho biết cặp thông tin xác thực không đúng định dạng chứ không phải vấn đề về bảng chữ cái Base64.
Ví dụ hoạt động: mã hóa admin:s3cret và giải mã tiêu đề từ nhật ký - cả hai hướng, bao gồm cả lỗi ở dòng mới
Nếu tên người dùng là quản trị viên và mật khẩu là pass:word, thông tin đăng nhập là quản trị viên:pass:word, mã hóa thành YWRtaW46cGFzczp3b3Jk. Khi giải mã chỉ phải tách ở dấu hai chấm đầu tiên, nhập tên người dùng quản trị viên và mật khẩu pass:word. Việc tách mỗi dấu hai chấm sẽ chia mật khẩu không chính xác. Tham số bộ ký tự trong RFC 7617 cho biết thông tin đăng nhập được mã hóa UTF-8. Điều này có nghĩa là các ký tự không phải ASCII trong tên người dùng hoặc mật khẩu được chuyển đổi thành UTF-8 byte trước khi mã hóa Base64.
Nếu tên người dùng là café (e có dấu), UTF-8 byte là 0x63 0x61 0x66 0xC3 0xA9 (bốn byte cho ASCII chữ cái cộng với hai byte cho ký tự có dấu) và thông tin xác thực đầy đủ café:password có byte cho café, sau đó là dấu hai chấm byte 0x3A, sau đó là mật khẩu. Đầu ra Base64 mã hóa tất cả các byte một cách trung thực. Bộ giải mã phải biết diễn giải các byte được giải mã dưới dạng văn bản UTF-8 chứ không phải tiếng Latin-1.
Mật khẩu chứa dấu hai chấm, dấu cách và không phải ASCII — tại sao dấu hai chấm đầu tiên được phân tách và tham số bộ ký tự dùng để làm gì
Một ví dụ hoạt động: bắt đầu với admin:s3cret. Chuyển đổi sang UTF-8 byte: a=0x61, d=0x64, m=0x6D, i=0x69, n=0x6E, :=0x3A, s=0x73, 3=0x33, c=0x63, r=0x72, e=0x65, t=0x74. Ở dạng thập phân: (97, 100, 109, 105, 110, 58, 115, 51, 99, 114, 101, 116). Base64 mã hóa 12 bytes này: nhóm thành bốn nhóm ba (tạo ra bốn nhóm bốn ký tự Base64).
Giá trị được mã hóa là YWRtaW46czNjcmV0. Tiêu đề ủy quyền là Ủy quyền: Basic YWRtaW46czNjcmV0. Phía mật khẩu có thể chứa một dấu hai chấm khác mà không cần di chuyển ranh giới đầu tiên đó. Dấu cách và văn bản không phải ASCII cũng tồn tại khi cả hai ngang hàng đồng ý về mã hóa văn bản. ToolAcre có thể xác minh UTF-8 byte mà nó phát ra nhưng máy chủ cũ hơn yêu cầu bộ ký tự khác vẫn là vấn đề về khả năng tương tác bên ngoài quá trình chuyển đổi Base64.
Tại sao điều này không an toàn nếu không có TLS — việc giải mã sẽ hiển thị mật khẩu cho bất kỳ ai nhìn thấy tiêu đề
Để giải mã tiêu đề đã nhận, hãy loại bỏ Basic, Base64 giải mã YWRtaW46czNjcmV0 để lấy lại byte, diễn giải dưới dạng văn bản UTF-8 để lấy admin:s3cret, tách dấu hai chấm đầu tiên để trích xuất tên người dùng và mật khẩu. Một lỗi phổ biến là theo dõi dòng mới từ echo. Nếu chạy echo admin:s3cret | base64 trong Unix shell, echo thêm dòng mới theo mặc định, vì vậy hãy mã hóa admin:s3cret bằng dòng mới (13 bytes thay vì 12).
Đầu ra Base64 khác nhau: YWRtaW46czNjcmV0Cg== (phần đệm và ký tự phụ). Tiêu đề ủy quyền có giá trị này sẽ không thành công vì mật khẩu bao gồm ký tự dòng mới. Cách khắc phục là sử dụng echo -n hoặc chuyển qua printf hoặc công cụ không nối thêm dòng mới. Bộ mã hóa & giải mã Base64 tránh điều này: mã hóa chính xác những gì bạn dán, không có dòng mới ẩn. TLS thay đổi mối đe dọa vận chuyển chứ không phải định dạng thông tin xác thực. Bên trong kết nối được bảo vệ, tiêu đề được mã hóa cùng với phần còn lại của yêu cầu; sau khi phần mềm ghi nhật ký hoặc hiển thị nó, giá trị Base64 lại hiển thị thông tin xác thực có thể sử dụng lại cho bất kỳ ai có thể giải mã nó. Sự biên tập vẫn còn quan trọng ở mọi điểm quan sát.
Các lỗi phổ biến — dòng mới từ echo, thiếu tiền tố 'Cơ bản' và mã hóa kép giá trị
Một lỗi khác là thiếu tiền tố Cơ bản. Giá trị tiêu đề ủy quyền không chỉ hợp lệ Base64; đó là tên lược đồ (Cơ bản hoặc Bearer hoặc các tên khác), theo sau là dấu cách và sau đó là thông tin xác thực. Một số hệ thống không nhận ra YWRtaW46czNjcmV0 là thông tin xác thực nhưng lại thành công với YWRtaW46czNjcmV0 cơ bản. Nếu gỡ lỗi 401, hãy kiểm tra xem máy chủ có phân tích cú pháp tiêu đề Cấp phép chính xác hay không.
Lược đồ không phân biệt chữ hoa chữ thường theo tiêu chuẩn HTTP nhưng nhiều cách triển khai phân biệt chữ hoa chữ thường; kiểm tra tài liệu API. Mã hóa kép là một chế độ lỗi khác. Nếu chuỗi mã hóa Base64 đã được mã hóa Base64 thì đầu ra sẽ là chuỗi khác. Mã hóa YWRtaW46czNjcmV0 tạo ra WVdkbWFXNDZjek5qY3JldA== (hoàn toàn khác). Một số hệ thống có thể vô tình áp dụng mã hóa hai lần: một lần trong khi thiết lập thông tin xác thực và một lần nữa khi xây dựng tiêu đề. Dòng mới từ lệnh shell đặc biệt dễ bị bỏ sót vì nó có thể được mã hóa như một phần của thông tin xác thực thay vì bị từ chối dưới dạng khoảng trắng xung quanh Base64. Tiêu đề kết quả giải mã rõ ràng thành mật khẩu có thêm một byte, tạo ra 401 trông giống như lỗi xác thực phía máy chủ.
Điều này không bao gồm những gì - Sơ đồ Digest và Bearer cũng như lời nhắc về thông tin xác thực của trình duyệt
Bộ giải mã mong đợi một lớp Base64, do đó, việc mã hóa kép sẽ gây ra sự không khớp. Đây là lý do tại sao việc ghi lại các giá trị thông tin xác thực ở dạng Base64 (không phải văn bản gốc) có thể gây nhầm lẫn: nếu ai đó áp dụng giải mã một lần, họ sẽ thấy tên người dùng và mật khẩu; nếu áp dụng hai lần, họ sẽ thấy sự xáo trộn. Xác thực thông báo (RFC 7616) và xác thực Bearer (đối với mã thông báo OAuth) sử dụng các lược đồ khác nhau, mỗi lược đồ có định dạng thông tin xác thực khác nhau.
Thông báo yêu cầu máy chủ gửi nonce, máy khách tính toán hàm băm và tiêu đề bao gồm hàm băm cộng với tên người dùng chứ không phải mật khẩu. Tên thường là JSON Mã thông báo web (JWT), được mã hóa Base64url nhưng không có tiền tố tên người dùng. Xác thực cơ bản đơn giản hơn cả hai nhưng hoàn toàn không an toàn nếu không có TLS vì thông tin xác thực có thể đọc được trong tiêu đề. Digest và Bearer sử dụng cùng một trường tiêu đề Cấp phép nhưng gán ý nghĩa hoàn toàn khác nhau cho các giá trị của chúng. Lời nhắc về thông tin xác thực của trình duyệt thêm giao diện người dùng và hành vi bộ nhớ đệm lên trên Cơ bản. Bài viết này dừng lại ở việc xây dựng và kiểm tra tải trọng thông tin xác thực Cơ bản thay vì so sánh các hệ thống xác thực đó.
Bài học rút ra: Xác thực cơ bản là Base64, không phải bảo vệ - cách bộ mã hóa và giải mã Base64 cho phép bạn kiểm tra giá trị tiêu đề cục bộ mà không cần gửi thông tin xác thực đi bất cứ đâu
Nếu API hỗ trợ nhiều phương thức xác thực, hãy chọn phương án an toàn nhất hiện có. Bộ mã hóa và giải mã Base64 có thể giúp gỡ lỗi Lỗi xác thực cơ bản: dán chuỗi thông tin xác thực (tên người dùng, dấu hai chấm và mật khẩu) và công cụ sẽ tạo ra giá trị Base64 ngay lập tức. So sánh kết quả với việc gửi tiêu đề và có thể thấy sự không khớp. Ngược lại, dán giá trị tiêu đề từ nhật ký mạng, loại bỏ tiền tố Cơ bản, giải mã để xem máy chủ đã nhìn thấy gì.
Để tìm hiểu, hãy dán admin:s3cret và quan sát đầu ra, sau đó sửa đổi mật khẩu để xem Base64 thay đổi như thế nào. Hiểu cách xây dựng tiêu đề sẽ làm rõ lý do giải mã yêu cầu biết định dạng RFC và tại sao dấu hai chấm là thành phần cấu trúc chứ không phải Base64. Kiểm tra cục bộ phải sử dụng thông tin xác thực được phát minh chứ không phải mật khẩu trực tiếp được sao chép từ sản xuất. Mã hóa cặp, di chuyển đầu ra trở lại bảng đầu vào và giải mã nó. Dấu chấm câu phù hợp và các ký tự ở cuối chính xác chứng minh hành trình khứ hồi đại diện trước khi tiêu đề được gửi đi bất kỳ đâu.