Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã URL
Mã hóa chuyển hướng URL bên trong tham số truy vấn mà không làm hỏng tham số đó
· Cách thức hoạt động
url-encoding query-parameters bảo vệ xác thực
Việc lồng một URL vào một cái khác là trường hợp phổ biến nhất khiến mã hóa phần trăm bị sai. Bài đăng này cho biết lý do tại sao ?, & và = bên trong của URL phải được mã hóa, cách thực hiện cũng như cách kiểm tra kết quả.
Liên kết quay lại đã loại bỏ một nửa tham số của nó — một URL bên trong và bị chuỗi truy vấn bên ngoài nuốt chửng
Liên kết quay lại đã giảm một nửa tham số của nó là một kiểu gỡ lỗi mà mọi nhà phát triển đều gặp phải. Người dùng đăng nhập, ứng dụng sẽ cố gắng chuyển hướng đến ?next=https://example.com/page?id=1&user=alice, và họ kết thúc tại example.com/page?id=1. Ký hiệu và trong URL bên trong được phân tích cú pháp dưới dạng dấu phân cách giữa các tham số truy vấn bên ngoài. Hai URL có dấu phân cách khác nhau có nghĩa là URL bên trong phải được mã hóa.
Khi lồng một URL bên trong một tham số truy vấn khác làm tham số truy vấn, địa chỉ bên trong đó sẽ trở thành dữ liệu không rõ ràng đối với lớp bên ngoài. Dấu hỏi, ký hiệu và dấu bằng không được đọc được dưới dạng dấu phân cách cấu trúc. Mã hóa phần trăm biến đổi chúng: ? trở thành %3F, & trở thành %26, = trở thành %3D. Sau đó, trình phân tích cú pháp bên ngoài xử lý chuỗi được mã hóa dưới dạng một giá trị tham số.
Hai URL, hai bộ dấu phân cách — tại sao URL bên trong chỉ là giá trị cho giá trị bên ngoài
EncodeURIComponent ở bên trong hoàn chỉnh URL tạo ra sự bảo vệ hoàn toàn: EncodeURIComponent("https://example.com/a?b=1&c=2") trả về "https%3A%2F%2Fexample.com%2Fa%3Fb%3D1%26c%3D2". Mọi ký tự cấu trúc đều trở thành %XX ký hiệu để trình phân tích cú pháp bên ngoài không thể hiểu sai các dấu phân cách lồng nhau. Một cách tiếp cận cạnh tranh như EncodeURI không để lại dấu gạch chéo và dấu chấm hỏi, tạo ra sự mơ hồ khi kết quả đó trở thành giá trị truy vấn.
Máy chủ giải mã chính xác một lần. Sau khi trích xuất tham số tiếp theo, một lệnh gọi giải mãURIComponent duy nhất sẽ khôi phục URL bên trong về dạng ban đầu. Phân tích kết quả dưới dạng chuỗi truy vấn mới sau đó sẽ thấy cấu trúc tham số chính xác. Giải mã kép là rủi ro khi cùng một giá trị đi qua nhiều lớp; %26 trở thành & sau một lần giải mã và giữ nguyên & sau lần giải mã thứ hai.
EncodeURIComponent trên toàn bộ bên trong URL — nội dung nào được mã hóa, bao gồm :, / và ?
Quy tắc cơ bản rất đơn giản: bất kỳ ký tự nào có ý nghĩa trong cú pháp URL, bao gồm : / ? = & #, phải được mã hóa phần trăm khi nó xuất hiện trong giá trị tham số truy vấn. Điều này đảm bảo trình phân tích cú pháp bên ngoài chỉ nhìn thấy cấu trúc tham số mà bạn dự định chứ không nhìn thấy bất kỳ dấu phân cách ngẫu nhiên nào ẩn bên trong giá trị bạn đang chuyển. Sử dụng EncodeURIComponent để xử lý mã hóa này một cách đầy đủ và đáng tin cậy.
Kiểm tra mã hóa này trong bộ mã hóa và giải mã URL: dán URL bên trong, mã hóa nó ở chế độ giá trị, quan sát đầu ra %XX. Sử dụng chế độ giải mã để xác minh chính xác chuyến đi khứ hồi. Công cụ này trình bày cách mã hóa từ đầu đến cuối để bạn có thể tự tin sao chép kết quả trực tiếp vào mã ứng dụng của mình.
Ví dụ hoạt động: xây dựng ?next=https://example.com/a?b=1&c=2 chính xác — chuỗi được mã hóa và giải mã ở phía máy chủ
Một ranh giới bảo mật quan trọng nằm cùng với mã hóa. Máy chủ phải xác thực rằng đích được giải mã thực sự an toàn để chuyển hướng đến. Mã hóa phần trăm làm cho cấu trúc URL trở nên rõ ràng; nó không làm cho các URL tùy ý trở nên an toàn. Lỗ hổng chuyển hướng mở xảy ra khi các ứng dụng mù quáng đi theo các URL do người dùng cung cấp. Việc xác thực yêu cầu danh sách cho phép, xác minh miền hoặc xác nhận người dùng rõ ràng.
Mã hóa khắc phục vấn đề phân tích cú pháp; xác nhận khắc phục vấn đề bảo mật. Đây là những mối quan tâm riêng biệt ở các lớp khác nhau. Bộ mã hóa & giải mã URL thể hiện mã hóa chính xác. Máy chủ phải thêm xác thực: kiểm tra danh sách, xác minh tên miền hoặc yêu cầu xác nhận. Nếu không xác thực, chuyển hướng được mã hóa chính xác đến bất kỳ tên miền nào vẫn có thể bị khai thác.
Rủi ro chuyển hướng mở - tại sao máy chủ phải xác thực đích được giải mã chứ không chỉ giải mã nó
Những sai lầm phổ biến tích lũy ở đây. Các nhà phát triển đôi khi chỉ mã hóa phần truy vấn, không để lại dấu gạch chéo, làm phá vỡ cấu trúc. Những cái khác mã hóa toàn bộ tham số được xây dựng bao gồm ?next=, tạo mã hóa kép. Một số kiểm tra tính hợp lệ bằng cách phân tích cú pháp mà không giải mã, đọc sai cấu trúc được mã hóa. Việc xây dựng bằng EncodeURIComponent đảm bảo tính nhất quán và chính xác trong mọi trường hợp.
Một lỗi phổ biến khác là tin tưởng trình duyệt sẽ tự động sửa một tham số không đúng định dạng. URL là dữ liệu và phải được xử lý chính xác như dữ liệu. EncodeURIComponent là công cụ tiêu chuẩn cho công việc này. Bộ mã hóa và giải mã URL giữ quy trình này cục bộ để bạn có thể xác minh số byte chính xác trước khi chuyển sang sản xuất.
Các lỗi phổ biến - chỉ mã hóa phần truy vấn hoặc tin tưởng trình duyệt sẽ sửa nó
Các tham số OAuth redirect_uri tuân theo chính xác mẫu này. Máy chủ ủy quyền chuyển quyền kiểm soát cho khách hàng tại một địa chỉ đã biết, thường là URL hoàn chỉnh với nhiều tham số. Mã hóa nó dưới dạng một giá trị duy nhất đảm bảo các tham số tồn tại trong quá trình vận chuyển và máy khách sẽ giải mã một lần trước khi sử dụng. Mã hóa bị xử lý sai trong luồng OAuth khiến mã thông báo và tham số gọi lại biến mất trong quá trình truyền.
Tham số trạng thái trong OAuth sử dụng mã hóa kết hợp với chữ ký mật mã để bảo vệ CSRF. Mã nhận dạng mảnh vẫn ở phía máy khách và không bao giờ di chuyển đến máy chủ. Không bao giờ được đặt mã thông báo mang trong các URL chuyển hướng bất kể mã hóa vì URL xuất hiện trong nhật ký, lịch sử trình duyệt và tiêu đề liên kết giới thiệu.
Điều này không bao gồm những gì — tham số trạng thái OAuth và thiết kế bảo vệ CSRF
Chiến lược thử nghiệm: xây dựng URL bên trong của bạn bằng các tham số thực, mã hóa nó dưới dạng giá trị bên ngoài, giải mã nó khi nhận mã. Xác minh kết quả được giải mã là giống hệt từng byte với bản gốc. Sử dụng bộ mã hóa và giải mã URL trước khi triển khai sản xuất. Kiểm tra lưu lượng truy cập và nhật ký mạng để xác nhận việc đến chính xác và không cắt bớt hoặc xáo trộn dữ liệu được mã hóa.
Một lỗi đánh máy như %2e thay vì %2E có thể giải mã chính xác nhưng không thực hiện được các lần kiểm tra khứ hồi trong các hệ thống phụ yêu cầu tính nhất quán. Việc mã hóa không khớp giữa các thư viện trên các nền tảng khác nhau là rất hiếm nhưng có thể xảy ra; kiểm tra toàn bộ chuyến đi sẽ phát hiện được chúng trước khi chúng gây ra các vấn đề về sản xuất và khiếu nại của khách hàng.
Bài học rút ra: coi URL bên trong là dữ liệu — cách chế độ một giá trị đơn của bộ mã hóa & giải mã URL mã hóa nó hoàn toàn và bộ giải mã của nó xác nhận chuyến đi khứ hồi
Ranh giới mã hóa rõ ràng: EncodeURIComponent xử lý dữ liệu đầu vào của bạn dưới dạng dữ liệu không rõ ràng và thoát khỏi mọi ký tự ngoại trừ dấu câu không được đặt trước, giúp việc lồng vào bất kỳ lớp URL nào trở nên an toàn. Ranh giới xác thực là riêng biệt: sau khi giải mã, hãy xác minh đích đến là nơi người dùng dự định đến. Sử dụng bộ mã hóa và giải mã URL để xem cách mã hóa được minh họa từ đầu đến cuối.
Hãy coi URL bên trong là dữ liệu ngay từ đầu. Mã hóa nó dưới dạng một giá trị truy vấn duy nhất, giải mã chính xác một lần khi nhận được, sau đó áp dụng xác thực trước khi chuyển hướng. Bộ mã hóa và giải mã URL hiển thị mã hóa phần trăm của bất kỳ URL hoàn chỉnh nào dưới dạng một giá trị truy vấn duy nhất và xác minh các chuyến đi khứ hồi cục bộ. Cả mã hóa và xác nhận đều cần thiết; công cụ này xử lý mã hóa chính xác.