Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã URL
Mã hóa kép URL: cách %2520 xảy ra cũng như cách phát hiện và hoàn tác nó
· Cách thức hoạt động
url-encoding javascript developer-workflow gỡ lỗi
%2520 trong URL có nghĩa là một khoảng trắng đã được mã hóa hai lần. Bài đăng này giải thích các lỗi đường dẫn gây ra lỗi này, cách nhận dạng chữ ký và số lần giải mã là an toàn.
Mã hóa URL kép: khi %2520 nghĩa là một khoảng trắng đi qua hai bộ mã hóa
Tên tệp đến dưới dạng "my%20file.pdf" thay vì "my file.pdf" báo hiệu mã hóa kép: một khoảng trắng được mã hóa thành %20, sau đó chính dấu phần trăm được mã hóa thành %25, tạo ra %2520 trong URL cuối cùng. Mỗi lớp của hệ thống như mã máy khách, khung web hoặc proxy ngược có thể mã hóa một lần. Khi hai lớp riêng biệt mã hóa, một ký tự sẽ bị đọc sai.
Bề mặt mã hóa kép thường xuyên nhất trong các chuỗi chuyển hướng phức tạp và hệ thống tạo khuôn mẫu. Nhà phát triển có thể tạo URL được mã hóa bên trong một khung tự mã hóa tất cả đầu ra theo mặc định. Mạng phân phối nội dung hoặc proxy ngược có thể mã hóa lại các URL đã được mã hóa từ hệ thống phụ trợ. Tham số chứa giá trị đã được mã hóa sẽ được mã hóa lại trước khi được lồng bên trong cấu trúc URL khác.
Tại sao %25 lại là dấu hiệu — bản thân ký hiệu phần trăm được mã hóa, vì vậy %20 trở thành %2520 và %C3%A9 trở thành %25C3%25A9
Dấu hiệu nhận biết của mã hóa kép là %25 xuất hiện ở nơi bạn thường mong đợi thấy một dấu phần trăm trong URL hoặc dữ liệu. Trong URL được mã hóa thông thường, bạn sẽ không bao giờ nhìn thấy %25 trừ khi gửi "%25" theo nghĩa đen. Nếu một khoảng trắng được mã hóa dưới dạng %20 được mã hóa lại, nó sẽ trở thành %2520.
Một ký tự có dấu như é, thường mã hóa thành %C3%A9, trở thành %25C3%25A9 khi được mã hóa hai lần bởi hai hệ thống khác nhau theo trình tự. Học cách phát hiện mẫu %25 trong thanh URL thanh, nhật ký và thông báo lỗi giúp tiết kiệm vô số giờ công việc gỡ lỗi phiền toái trong môi trường sản xuất nơi dữ liệu truyền qua nhiều dịch vụ.
Nơi giới thiệu mã hóa kép - mã máy khách cộng với khung, chuyển hướng, proxy và trình trợ giúp mẫu
Mã hóa kép phá hủy cả khả năng đọc và khả năng hệ thống phía máy chủ phân tích cú pháp URL một cách chính xác. Tệp có tên "my file.pdf" trở thành "my%20file.pdf" khi được mã hóa chính xác. Nếu chuỗi đã mã hóa được mã hóa lại—có thể bằng một biểu mẫu—nó sẽ trở thành "my%2520file.pdf".
Khi máy chủ nhận được thông tin này và giải mã nó một lần, nó sẽ thấy "my%20file.pdf" là tên tệp theo nghĩa đen thay vì nhận dạng nó là "file.pdf của tôi". Bất kỳ ứng dụng nào mong muốn chỉ nhận được một lần giải mã duy nhất sẽ nhận được kết quả sai lệch. Tệ hơn nữa, một nhà phát triển giải mã hai lần để khắc phục sự cố trên các giá trị chỉ được mã hóa một lần sẽ thực sự làm hỏng dữ liệu hợp pháp với đường giải mã bổ sung.
Ví dụ đã hoạt động: giải mã một URL được mã hóa kép mỗi lần một lần — mỗi lần chuyển sẽ tiết lộ nội dung gì và khi nào nên dừng
Mã JavaScript phía máy khách và các giá trị mặc định của khung phía máy chủ là những nguồn mã hóa kép ngẫu nhiên phổ biến nhất trong các hệ thống sản xuất. Ứng dụng JavaScript có thể sử dụng EncodeURIComponent trên một giá trị, sau đó chuyển trực tiếp giá trị đó đến một khung mã hóa tất cả đầu ra chuỗi theo mặc định, từ đó mã hóa ký hiệu phần trăm lần thứ hai. Lớp proxy ngược nhằm mục đích khử trùng các URL có thể mã hóa lại các tham số đã được mã hóa trước từ ứng dụng phụ trợ.
Chuyển hướng URL được tạo bằng cách nối đầu vào do người dùng cung cấp với chức năng trợ giúp khung có thể mã hóa đồng thời ở cả hai bước. Ví dụ hoạt động: người dùng gửi "kiểm tra&giá trị" thông qua biểu mẫu HTML, trình duyệt sẽ mã hóa nó thành "test%26value". Khung nhìn thấy văn bản phần trăm theo nghĩa đen và mã hóa nó, tạo ra "test%2526value". Một giải mã cho "test%26value", vẫn sai.
Khi cố tình mã hóa kép — một URL được mang bên trong tham số truy vấn của URL khác
Mã hóa kép có chủ ý hợp lệ trong một trường hợp cụ thể: khi URL phải di chuyển bên trong tham số truy vấn của URL khác. Các luồng OAuth và các liên kết quay lại đăng nhập đôi khi yêu cầu lồng một URL hoàn chỉnh vào trong một luồng khác. URL bên trong trước tiên phải được mã hóa hoàn toàn theo phần trăm, sau đó toàn bộ chuỗi được mã hóa phải được mã hóa lại dưới dạng giá trị tham số cho URL bên ngoài.
Việc mã hóa kép này là có chủ ý và hoàn toàn cần thiết trong những trường hợp này. Trình phân tích cú pháp tham số bên ngoài giải mã một lần, mang lại URL bên trong vẫn được mã hóa. Sau đó, hệ thống bên trong sẽ giải mã lại, khôi phục URL ban đầu. Chìa khóa quan trọng là hiểu được mục đích và ghi lại nó một cách rõ ràng trong phần nhận xét mã cho những người bảo trì trong tương lai.
Các lỗi phổ biến — giải mã cho đến khi không có gì thay đổi, làm hỏng các giá trị chứa %25 một cách hợp pháp
Sai lầm cổ điển và nguy hiểm là giải mã lặp đi lặp lại cho đến khi không có gì thay đổi, điều này sẽ làm hỏng các giá trị chứa dấu phần trăm trong dữ liệu thực tế một cách hợp pháp. Một tham số như "discount%2525" (biểu thị chữ "%25" được mã hóa dưới dạng giá trị tham số, sau đó được mã hóa lại để vận chuyển) là hoàn toàn chính xác theo thiết kế. Giải mã nó một lần sẽ mang lại "giảm giá%25", điều này vẫn đúng. Giải mã lần thứ hai sẽ ra "% chiết khấu", sai và làm mất thông tin.
Nhà phát triển có thể cho rằng "%25" là một lỗi và giải mã nhiều lần, làm mất dấu phần trăm. Thay vào đó, hãy giải mã chính xác số lần theo yêu cầu của kiến trúc: một lần cho một tham số, hai lần lồng nhau. Đếm các lớp để biết các hoạt động giải mã phù hợp.
Điều này không bao gồm những gì — mã hóa thực thể HTML được xếp lớp trên đầu các URL mà trình thoát thực thể HTML xử lý
Các lỗi phổ biến bao gồm mã hóa toàn bộ URL bằng EncodeURIComponent, sau đó mong đợi dấu gạch chéo và dấu hai chấm hoạt động như dấu phân cách cấu trúc mà chúng không thể thực hiện được sau khi mã hóa. Một lỗi thường gặp khác là trộn lẫn các tiêu chuẩn mã hóa khác nhau: một số mã sử dụng mã hóa phần trăm cho mỗi RFC 3986 và mã khác sử dụng mã hóa biểu mẫu có dấu cộng biểu thị khoảng trắng. Một giá trị như "my+tệp" thực sự trở nên mơ hồ—nó có thể có nghĩa là "tệp của tôi" hoặc có thể có nghĩa là văn bản "my+tệp" có dấu cộng.
Nếu mã hóa phần trăm chạm vào "tệp+của tôi" trước tiên, nó sẽ trở thành "tệp%2B của tôi". Nếu giải mã biểu mẫu theo sau, mong đợi dấu cộng như dấu cách, nó vẫn sai. Tính nhất quán giữa các lớp là điều cần thiết. Mọi hệ thống phải sử dụng cùng một tiêu chuẩn mã hóa hoặc mỗi lớp phải được ghi lại rõ ràng.
Bài học rút ra: mã hóa chính xác một lần trên mỗi lớp — cách bộ mã hóa và giải mã URL cho phép bạn giải mã từng lượt một và xem từng kết quả trung gian
Sau khi bạn đã xác định thành công việc mã hóa kép xảy ra trong hệ thống sản xuất, việc khắc phục hoàn toàn phụ thuộc vào vị trí xảy ra sự trùng lặp trong quy trình. Nếu cả mã máy khách và khung đều đang mã hóa, hãy xóa hoàn toàn mã hóa khỏi một trong số chúng. Nếu một tham số truyền qua nhiều dịch vụ phụ trợ, hãy theo dõi đường dẫn đầy đủ qua từng dịch vụ và tìm ra dịch vụ nào đang mã hóa khi lẽ ra nó không nên làm như vậy.
Kiểm tra kỹ lưỡng bản sửa lỗi bằng cách chuyển dữ liệu mẫu qua quy trình hoàn chỉnh từ đầu đến cuối và xác minh rằng dữ liệu đến đích hoàn toàn không thay đổi. Ghi lại giả định mã hóa ở mỗi ranh giới một cách rõ ràng: "điểm cuối này trả về các tham số được mã hóa theo phần trăm" hoặc "phần mềm trung gian này yêu cầu UTF-8 thô và áp dụng mã hóa cho nó". Bao gồm số lượt giải mã dự kiến trong tài liệu đó dành cho các nhà phát triển trong tương lai.