Đôi khi, một tiêu chuẩn web biến mất nhanh chóng theo ý thích của một số công ty, có thể dẫn đến rất nhiều lời phàn nàn [và ít nhất là một trò đùa]
Nhưng đôi khi, chúng biến mất từ từ, giống như loại địa chỉ web này
//username:password@example.com/somewhere
Nếu bạn chưa từng thấy một URL như vậy trước đây, điều đó không sao cả, bởi vì câu trả lời cho câu hỏi “Tôi vẫn có thể sử dụng HTTP Basic Auth trong URL chứ?” . không, bạn có thể không thể
Nhưng bằng một bài học lịch sử, chúng ta hãy quay lại và xem những URL này là gì, tại sao chúng lại biến mất và cách các trình duyệt web xử lý chúng ngày nay. Cảm ơn Ruth, người đã đặt câu hỏi ban đầu đã truyền cảm hứng cho bài đăng này
xác thực cơ bản
Web ban đầu không được xây dựng để xác thực. Một tài nguyên trên Web về mặt lý thuyết có thể truy cập được cho tất cả nhân loại. nếu bạn không muốn nó xuất hiện trước công chúng, bạn đã không đưa nó lên Web. Một phương pháp đáng tin cậy sẽ không khả dụng cho đến khi khái niệm trạng thái được cung cấp bởi phát minh cookie HTTP của Netscape vào năm 1994 và thậm chí điều đó sẽ không được phổ biến rộng rãi trong vài năm, đặc biệt là do triển khai chương trình CGI [hoặc tương tự] để thực hiện xác thực
.htaccess . Các tệp.htaccess sau này sẽ tiếp tục phục vụ nhiều mục đích khác, nhưng mục đích ban đầu và có lẽ được biết đến nhiều nhất của chúng - và mục đích đặt tên cho chúng - là kiểm soát truy cậpThông tin xác thực trong URL
Một đặc điểm kỹ thuật riêng biệt, không dành riêng cho Web [nhưng là một trong những đóng góp quan trọng nhất của Tim Berners-Lee cho nó], được mô tả như sau
://:@:/#
Vào thời điểm thông số kỹ thuật đó được viết, Web không có cơ chế chuyển tên người dùng và mật khẩu. trường hợp chung này chỉ nhằm áp dụng cho các giao thức đã có các thông tin đăng nhập này. Một ví dụ được đưa ra trong thông số kỹ thuật và được làm rõ với “Tên người dùng tùy chọn. Một số kế hoạch [e. g. , ftp] cho phép xác định tên người dùng. ”
Nhưng khi các trình duyệt web có WWW-Authenticate, hầu như tất cả chúng đều hỗ trợ thêm tên người dùng và mật khẩu vào địa chỉ web. Điều này cho phép e. g. siêu liên kết với thông tin đăng nhập được nhúng trong chúng, được tạo cho dấu trang rất thuận tiện hoặc thông tin xác thực một phần [e. g. chỉ tên người dùng] được bao gồm trong một liên kết, với người dùng được nhắc nhập mật khẩu khi đến đích. Càng xa càng tốt
Đây là lý do tại sao chúng ta không thể có những điều tốt đẹp
Kỹ thuật này không còn được ưa chuộng ngay khi nó bắt đầu được sử dụng cho mục đích bất chính. Những kẻ lừa đảo không mất nhiều thời gian để nhận ra rằng chúng có thể tạo các liên kết như thế này
________số 8
Mọi thứ chúng tôi dạy người dùng về cách kiểm tra “https. //” theo sau là tên miền của ngân hàng của họ… đã bị hủy hoại bởi sự lựa chọn giao diện người dùng này. Nạn nhân đáng thương thực sự sẽ kết nối với e. g. Tin tặcTrang web. com, nhưng nhìn lướt qua thanh địa chỉ của họ sẽ khiến họ bị thuyết phục rằng họ đang nói chuyện với YourBank. com
về mặt lý thuyết. việc áp dụng rộng rãi chứng chỉ EV cùng với các lựa chọn giao diện người dùng hợp lý [chưa bao giờ được thực hiện] có thể giải quyết được vấn đề này, nhưng một giải pháp đơn giản hơn nhiều là không hiển thị tên người dùng trong thanh địa chỉ. Dù sao thì các nhà phát triển web cũng hào hứng hơn rất nhiều với các biểu mẫu và cookie để xác thực, vì vậy các trình duyệt bắt đầu cắt giảm tính năng “thông tin xác thực trong địa chỉ”
[Có những lý do khác khiến việc triển khai Xác thực cơ bản HTTP cụ thể này kém lý tưởng hơn, nhưng lý do này là lý do lớn giải thích tại sao mọi thứ phải thay đổi. ]
Từng cái một, các trình duyệt đã thực hiện thay đổi. Nhưng đây là một chút thú vị. các trình duyệt không phải lúc nào cũng thực hiện thay đổi theo cùng một cách
Cách các trình duyệt khác nhau xử lý xác thực cơ bản trong URL
Hãy kiểm tra một số trình duyệt phổ biến. Để chạy các thử nghiệm này, tôi đã kết hợp một ứng dụng web nhỏ xuất ra tiêu đề Authorization: được truyền cho nó, nếu có và có thể tùy chọn gửi phản hồi 401 Unauthorized cùng với tiêu đề WWW-Authenticate2 để kích hoạt xác thực cơ bản. Tại sao cả hai? . Điều này có liên quan vì một số địa chỉ – thường là điểm cuối API – có xác thực HTTP tùy chọn và đôi khi điều quan trọng đối với tác nhân người dùng [mặc dù thường là thư viện hoặc dòng lệnh] để chuyển thông tin đăng nhập mà không được nhắc trước
Trong mỗi trường hợp, tôi đã thử từng thử nghiệm sau trong phiên bản trình duyệt mới
- Chuyển đến
WWW-Authenticate3 [xác thực là tùy chọn] - Truy cập
WWW-Authenticate4 [bắt buộc phải xác thực] - Thử nghiệm 1, sau đó cho phép các siêu liên kết tương đối [sẽ giữ lại thông tin xác thực một cách chính xác] tới
WWW-Authenticate5 - Thử nghiệm 2, sau đó theo các siêu liên kết tương đối đến
WWW-Authenticate6
Tôi chỉ đang thử nghiệm sơ đồ WWW-Authenticate7, bởi vì tôi không có lý do gì để tin rằng bất kỳ trình duyệt nào đang được thử nghiệm xử lý sơ đồ WWW-Authenticate8 khác đi
Dòng máy tính để bàn Chromium
Opera 78 cũng loại bỏ tên người dùng, mật khẩu và lược đồ, nhưng không giữ lại tên người dùng và mật khẩu theo cách có thể sao chép ra ngoài
Xác thực chỉ được thông qua khi hạ cánh trên trang "bắt buộc"; . Làm mới trang hoặc nhập lại địa chỉ bằng thông tin đăng nhập không thay đổi điều này
Điều hướng từ trang "tùy chọn" đến trang "bắt buộc" chỉ bằng các liên kết tương đối đã giữ lại tên người dùng và mật khẩu và gửi nó đến máy chủ khi nó trở nên bắt buộc, ngay cả Opera ban đầu dường như không giữ lại thông tin đăng nhập
Điều hướng từ trang “bắt buộc” đến trang “tùy chọn” chỉ sử dụng các liên kết tương đối hoặc thậm chí nhập địa chỉ trang “tùy chọn” bằng thông tin đăng nhập sau khi truy cập trang “bắt buộc”, không dẫn đến việc chuyển xác thực sang trang “tùy chọn”. Tuy nhiên, thật thú vị khi lưu ý rằng một khi xác thực đã xảy ra trên trang bắt buộc, nhấn enter ở cuối thanh địa chỉ trên trang tùy chọn, với thông tin xác thực trong thanh địa chỉ [dù hiển thị hoặc ẩn đối với người dùng] sẽ dẫn đến thông tin đăng nhập . Chúng tiếp tục được chuyển vào mỗi lần tải tiếp theo của trang “tùy chọn” cho đến khi phiên duyệt web kết thúc
Máy tính để bàn Firefox
Tương tự như Opera, thông tin đăng nhập không xuất hiện trên thanh địa chỉ sau đó nhưng rõ ràng chúng vẫn đang được lưu trữ. nếu nhấn nút làm mới, hộp thoại sẽ xuất hiện lại. Nó không xuất hiện nếu người dùng chọn thanh địa chỉ và nhấn enter
Truy cập bất kỳ trang nào trong phạm vi lĩnh vực xác thực sau khi truy cập trang “bắt buộc” sẽ dẫn đến thông tin đăng nhập được gửi, cho dù chúng có được bao gồm trong địa chỉ hay không. Đây có lẽ là cách triển khai đúng nhất với mong đợi của tiêu chuẩn mà tôi đã tìm thấy trong một trình duyệt đồ họa hiện đại
Máy tính để bàn Safari
Sau khi được thông qua, thông tin đăng nhập sau đó sẽ được cung cấp tự động cho các địa chỉ khác trong cùng một lĩnh vực [i. e. trang tùy chọn]
trình duyệt cũ hơn
Hãy thử một số trình duyệt cũ hơn
WWW-Authenticate9…Các phiên bản IE cũ hơn này thậm chí [chính xác] vẫn giữ lại thông tin đăng nhập thông qua các siêu liên kết tương đối, cho phép chúng được chuyển khi chúng trở nên bắt buộc. Chúng không được chuyển qua các trang tùy chọn trừ khi đã gặp một trang bắt buộc trong cùng một lĩnh vực
401 Unauthorized0 và 401 Unauthorized1 trước đây, đây có lẽ là sự phân chia rõ ràng nhất giữa Microsoft và Netscape. Cuối cùng, Opera cổ điển là trình duyệt duy nhất tôi từng thấy che mật khẩu trên thanh địa chỉ, biến nó thành một loạt dấu hoa thị. Điều này đảm bảo người dùng biết rằng mật khẩu đã được sử dụng nhưng không làm rò rỉ bất kỳ thông tin nhạy cảm nào cho những người lướt qua vai [độ dài của mật khẩu “bị che” luôn có cùng độ dài, do đó, nó thậm chí không làm rò rỉ độ dài của mật khẩu . Hoàn toàn là một thiết kế ngoạn mục và là một ví dụ tuyệt vời về lý do tại sao Opera cổ điển lại đi trước thời đại
Dòng lệnh
Ngày nay, hầu hết những người sử dụng địa chỉ web có thông tin đăng nhập được nhúng bên trong chúng có thể đang làm việc với mã, API hoặc dòng lệnh, vì vậy không có gì ngạc nhiên khi thấy rằng đây là nơi tuân thủ các tiêu chuẩn “truyền thống” nhất
Tôi không ngạc nhiên khi phát hiện ra rằng việc cung cấp tên người dùng và mật khẩu cho curl trong URL có nghĩa là tên người dùng và mật khẩu đó đã được gửi đến máy chủ [tất nhiên là sử dụng xác thực Cơ bản, nếu không yêu cầu xác thực]
401 Unauthorized2
Tuy nhiên, wget đã bắt tôi ra ngoài. Truy cập cùng một địa chỉ với wget không dẫn đến thông tin đăng nhập được gửi trừ khi bắt buộc [tôi. e. trong đó đã nhận được phản hồi 401 Unauthorized3 và tiêu đề 401 Unauthorized4 trong lần thử đầu tiên]. Để buộc wget gửi thông tin xác thực khi chúng chưa được yêu cầu, yêu cầu sử dụng công tắc 401 Unauthorized5 và 401 Unauthorized6
401 Unauthorized7
lynx làm một điều dễ thương và thông minh. Giống như hầu hết các trình duyệt hiện đại, nó không gửi thông tin đăng nhập trừ khi được yêu cầu cụ thể, nhưng nếu chúng ở trong thanh địa chỉ khi chúng trở thành bắt buộc [e. g. vì theo các siêu liên kết tương đối hoặc siêu liên kết có chứa thông tin đăng nhập], nó sẽ nhắc nhập tên người dùng và mật khẩu, nhưng điền trước biểu mẫu với các chi tiết từ URL. Tốt đẹp
Trạng thái của Xác thực HTTP [Cơ bản] là gì?
Xác thực cơ bản HTTP và xác thực Digest, người anh em họ gần gũi của nó [khắc phục một số hạn chế bảo mật khi chạy Xác thực cơ bản qua kết nối không được mã hóa] vẫn còn rất nhiều, nhưng không thể dựa vào việc sử dụng nó trong các siêu liên kết. một số trình duyệt [e. g. IE, Safari] hoàn toàn trộn lẫn các liên kết như vậy trong khi những liên kết khác không hoạt động như bạn mong đợi. Các cơ chế khác như 401 Unauthorized8 được sử dụng rộng rãi trong API, nhưng không nơi nào khác
Các tiêu đề 401 Unauthorized4 và Authorization:, theo một số cách, là một ví dụ về cách tốt nhất có thể để triển khai xác thực trên Web. như một tiêu chuẩn cơ bản độc lập với sự hỗ trợ cho các biểu mẫu [và ngày càng tăng, Javascript], cookie và các cuộc hội thoại nhiều phần phức tạp. Thật dễ dàng để hình dung một mốc thời gian thay thế trong đó các tiêu chuẩn này tiếp tục được phát triển và duy trì một cách hợp tác cùng với những thiếu sót của chúng – e. g. không thể dễ dàng đăng xuất khi sử dụng hầu hết các trình duyệt đồ họa. - đã vượt qua. Dòng thời gian trong đó người ta có thể viết một biểu mẫu đăng nhập như thế này, biết rằng điện thoại của bạn. g. Thuộc tính “xác thực” sẽ hướng dẫn trình duyệt gửi thông tin xác thực bằng tiêu đề Authorization:
WWW-Authenticate2
Trong một thế giới như vậy, các chiến lược xác thực phức tạp hơn [e. g. xác thực đa yếu tố] có thể liên quan đến các biểu mẫu mã hóa dưới dạng JSON. Và các hệ thống đăng nhập một lần sẽ đơn giản bao gồm việc trình duyệt thu thập mã thông báo từ nhà cung cấp xác thực và chuyển nó tới dịch vụ của bên thứ ba, trực tiếp thông qua các tiêu đề của trình duyệt, không cần chuyển hướng ngược và xuôi với ngăn xếp thông tin trong . Các chứng chỉ phía máy khách – từ lâu đã là một cơ chế xác thực mạnh mẽ nhưng bị bỏ quên theo đúng nghĩa của chúng – có thể hoạt động như những công dân hạng nhất trực tiếp bên cạnh một hệ thống như vậy, cung cấp xác thực yếu tố thứ hai minh bạch ở bất cứ nơi nào nó được yêu cầu. Bạn sẽ không phải chấp nhận cookie theo dõi từ một trang web để đăng nhập [hoặc duy trì trạng thái đăng nhập] và nếu mật khẩu an toàn tích hợp với trình duyệt của bạn được hỗ trợ, bạn có thể đăng nhập và đăng xuất khỏi bất kỳ trang web nào chỉ bằng cách chuyển đổi “của tài khoản đó . tất cả những gì bạn sẽ thay đổi là liệu thông tin đăng nhập của bạn có được gửi hay không khi đến thời điểm
Web từ lâu đã không ngừng thúc đẩy những thứ sáng bóng mới tiếp theo và điều đó đôi khi có nghĩa là các tiêu chuẩn đã được thiết lập đã bị bỏ qua sớm hoặc không phát triển lâu hơn chúng ta mong muốn. Xem xét chúng tôi đã mất bao lâu để có được các yếu tố WWW-Authenticate4 và WWW-Authenticate5 vì Flash “sáng bóng mới” chiếm ưu thế, API Thanh toán trên Web chỉ mới bắt đầu hoàn thiện như thế nào mặc dù đã có hơn 25 năm thương mại điện tử trên Web hoặc chúng tôi vẫn có thể làm như thế nào
Mô hình mới cho các tính năng Web dường như là các tính năng mới đầu tiên đến từ việc triển khai JavaScript phổ biến và sau đó cuối cùng nó phát triển thành một tính năng trình duyệt gốc. ví dụ: xác thực biểu mẫu HTML, trong thời gian dài nhất chỉ có thể được thực hiện phía máy khách bằng ngôn ngữ kịch bản. Tôi rất muốn thấy ai đó suy nghĩ lại về Xác thực HTTP theo cách này, nhưng thật đáng buồn là chúng ta sẽ không bao giờ có được giải pháp 100% chỉ riêng với JavaScript. [Ví dụ: SSO được phân phối gần như chắc chắn là không cần bàn, do giới hạn giữa các miền]
Hoặc có thể đó chỉ là một vấn đề đang chờ ai đó thông minh hơn tôi đến và giải quyết nó. Muốn cho nó một lần thử?