Thông tin xác thực cơ bản HTTP được chuyển qua URL và mã hóa


250

Tôi có một câu hỏi về thông tin xác thực HTTPS và HTTP.

Giả sử tôi bảo mật URL bằng Xác thực HTTP:

<Directory /var/www/webcallback>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /var/www/passwd/passwords
Require user gooduser
</Directory>

Sau đó tôi truy cập URL đó từ một hệ thống từ xa thông qua HTTPS, chuyển thông tin đăng nhập trong URL:

https://gooduser:secretpassword@www.example.com/webcallback?foo=bar

Tên người dùng và mật khẩu sẽ được tự động mã hóa SSL? Điều này có đúng với GET và POST không? Tôi đang gặp khó khăn trong việc tìm kiếm một nguồn đáng tin cậy với thông tin này.



Câu hỏi rất cũ nhưng tuy nhiên: cách tiếp cận này đã bị ietf.org/rfc/rfc3986.txt phản đối : "Sử dụng định dạng" user: password "trong trường userinfo bị phản đối."
Madbreaks

Câu trả lời:


237

Tên người dùng và mật khẩu sẽ được tự động mã hóa SSL? Điều này có đúng với GET và POST không

Có có có.

Toàn bộ giao tiếp (lưu để tra cứu DNS nếu IP cho tên máy chủ chưa được lưu trong bộ nhớ cache) được mã hóa khi SSL được sử dụng.


25
+1. GET và POST, bao gồm cả url, được mã hóa. Tôi sẽ chỉ thêm - các công cụ như dữ liệu firebird và Tamper chỉ có thể hiển thị kết quả chưa được mã hóa chúng là một phần của trình duyệt và do đó có thể chặn yêu cầu trước khi được mã hóa. Sau khi gửi qua dây, mọi thứ đều được mã hóa.
Sripathi Krishnan

21
Để rõ ràng, tất cả mọi thứ trừ tên miền được mã hóa. Nếu tình cờ bất cứ ai trên này và muốn một câu trả lời chi tiết, xem answers.google.com/answers/threadview/id/758002.html
rcourtna

7
Để hoàn thiện, " Internet Explorer không hỗ trợ tên người dùng và mật khẩu trong địa chỉ trang Web (URL HTTP hoặc HTTPS) " Có vẻ như chỉ có phiên bản Internet Explorer 3.0 đến 6.0 hỗ trợ cú pháp sau cho URL HTTP hoặc HTTPS: http (s): //username:password@server/resource.ext Lưu ý: Thay đổi này trong hành vi mặc định không ảnh hưởng đến các giao thức khác. Ví dụ: bạn vẫn có thể đưa thông tin người dùng vào URL FTP sau khi bạn cài đặt bản cập nhật bảo mật 832894.
Luke

câu trả lời này không chứa bất kỳ nguồn đáng tin cậy cũng như giải thích thêm.
Jens Piegsa

26

Vâng, nó sẽ được mã hóa.

Bạn sẽ hiểu nó nếu bạn chỉ cần kiểm tra những gì xảy ra đằng sau hậu trường.

  1. Trình duyệt hoặc ứng dụng trước tiên sẽ phân tích URL và cố gắng lấy IP của máy chủ bằng Truy vấn DNS. tức là: Một yêu cầu DNS sẽ được thực hiện để tìm địa chỉ IP của tên miền (www.example.com). Xin lưu ý rằng không có thông tin khác sẽ được gửi qua yêu cầu này.
  2. Trình duyệt hoặc ứng dụng sẽ khởi tạo kết nối SSL với địa chỉ IP nhận được từ yêu cầu DNS. Giấy chứng nhận sẽ được trao đổi và điều này xảy ra ở cấp độ vận chuyển. Không có thông tin cấp ứng dụng sẽ được chuyển tại thời điểm này. Hãy nhớ rằng xác thực Cơ bản là một phần của HTTP và HTTP là giao thức cấp ứng dụng. Không phải là một nhiệm vụ lớp vận chuyển.
  3. Sau khi thiết lập kết nối SSL, bây giờ dữ liệu cần thiết sẽ được chuyển đến máy chủ. tức là: Đường dẫn hoặc URL, các tham số và tên người dùng và mật khẩu xác thực cơ bản.

-5

Không nhất thiết phải đúng. Nó sẽ được mã hóa trên dây tuy nhiên nó vẫn nằm trong nhật ký văn bản đơn giản


17
Máy chủ web nào ghi lại tên người dùng và mật khẩu từ các yêu cầu? Đó sẽ là một địa ngục của một máy chủ web không an toàn.
Andrew Barber

1
Vâng, điều này không đúng. Có thể hướng dẫn apache đăng nhập thông tin này, nhưng chắc chắn nó không được thực hiện theo mặc định.
DougW

27
@Brandon có lẽ đã nghĩ "trong URL" có nghĩa là trong chuỗi truy vấn (ví dụ:? User = bob & pw = 123hackmeplz). Điều đó có thể kết thúc trong nhật ký máy chủ.
Mike Graf

5
Liên quan: "Khi bạn gọi URL đó trên máy khách với ví dụ: curl, tên người dùng và mật khẩu sẽ hiển thị rõ ràng trong danh sách quy trình và có thể xuất hiện trong tệp lịch sử bash." - stackoverflow.com/a/4981309
Hawkeye Parker

1
@ zb226 người hỏi đặc biệt đã đề cập đến việc đặt thông tin đăng nhập vào URL.
Lambart
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.