Câu trả lời:
Vâng, đúng vậy. Nhưng sử dụng GET cho dữ liệu nhạy cảm là một ý tưởng tồi vì nhiều lý do:
Do đó, ngay cả khi Chuỗi truy vấn được bảo mật, không nên chuyển dữ liệu nhạy cảm qua chuỗi truy vấn.
[1] Mặc dù tôi cần lưu ý rằng RFC nói rằng trình duyệt không nên gửi người giới thiệu từ HTTPS đến HTTP. Nhưng điều đó không có nghĩa là thanh công cụ trình duyệt bên thứ 3 xấu hoặc hình ảnh / đèn flash bên ngoài từ trang web HTTPS sẽ không làm rò rỉ nó.
History caches in browsershoặc thêm một số tài liệu tham khảo cho ir?
Từ quan điểm "đánh hơi gói mạng", yêu cầu GET là an toàn, vì trước tiên trình duyệt sẽ thiết lập kết nối an toàn và sau đó gửi yêu cầu có chứa các tham số GET. Nhưng url của GET sẽ được lưu trữ trong lịch sử / tự động hoàn thành của trình duyệt, đây không phải là nơi tốt để lưu trữ, ví dụ như dữ liệu mật khẩu. Tất nhiên điều này chỉ áp dụng nếu bạn sử dụng định nghĩa "Dịch vụ web" rộng hơn có thể truy cập dịch vụ từ trình duyệt, nếu bạn chỉ truy cập nó từ ứng dụng tùy chỉnh thì đây không phải là vấn đề.
Vì vậy, sử dụng bài viết ít nhất cho các hộp thoại mật khẩu nên được ưu tiên. Cũng như được chỉ ra trong liên kết littlegeek đã đăng một URL GET có nhiều khả năng được ghi vào nhật ký máy chủ của bạn.
Có , chuỗi truy vấn của bạn sẽ được mã hóa.
Lý do đằng sau là các chuỗi truy vấn là một phần của giao thức HTTP, là giao thức của lớp ứng dụng, trong khi phần bảo mật (SSL / TLS) đến từ lớp vận chuyển. Kết nối SSL được thiết lập trước và sau đó các tham số truy vấn (thuộc giao thức HTTP) được gửi đến máy chủ.
Khi thiết lập kết nối SSL, khách hàng của bạn sẽ thực hiện các bước sau theo thứ tự. Giả sử bạn đang cố gắng đăng nhập vào một trang web có tên example.com và muốn gửi thông tin đăng nhập của bạn bằng các tham số truy vấn. URL hoàn chỉnh của bạn có thể trông giống như sau:
https://example.com/login?username=alice&password=12345)
example.comthành địa chỉ IP (124.21.12.31)bằng yêu cầu DNS. Khi truy vấn thông tin đó, chỉ có thông tin cụ thể của miền được sử dụng, tức là chỉ example.comđược sử dụng.124.21.12.31và sẽ cố gắng kết nối với cổng 443 (cổng dịch vụ SSL không phải là cổng HTTP mặc định 80).example.comsẽ gửi chứng chỉ cho khách hàng của bạn.Do đó, bạn sẽ không để lộ dữ liệu nhạy cảm. Tuy nhiên, gửi thông tin đăng nhập của bạn qua phiên HTTPS bằng phương pháp này không phải là cách tốt nhất. Bạn nên đi cho một cách tiếp cận khác.
(e.g http://example.com/login?username=alice&password=12345).
Đúng. Toàn bộ văn bản của phiên HTTPS được bảo mật bằng SSL. Điều đó bao gồm các truy vấn và các tiêu đề. Về mặt đó, POST và GET sẽ hoàn toàn giống nhau.
Về tính bảo mật của phương pháp của bạn, không có cách nào thực sự để nói mà không có sự kiểm tra thích hợp.
SSL trước tiên kết nối với máy chủ, vì vậy tên máy chủ và số cổng được chuyển dưới dạng văn bản rõ ràng. Khi máy chủ phản hồi và thử thách thành công, máy khách sẽ mã hóa yêu cầu HTTP bằng URL thực tế (tức là bất cứ điều gì sau dấu gạch chéo thứ ba) và gửi nó đến máy chủ.
Có một số cách để phá vỡ bảo mật này.
Có thể định cấu hình proxy để hoạt động như một "người đàn ông ở giữa". Về cơ bản, trình duyệt gửi yêu cầu kết nối với máy chủ thực tới proxy. Nếu proxy được cấu hình theo cách này, nó sẽ kết nối qua SSL với máy chủ thực nhưng trình duyệt vẫn sẽ nói chuyện với proxy. Vì vậy, nếu kẻ tấn công có thể có quyền truy cập proxy, anh ta có thể thấy tất cả dữ liệu chảy qua nó trong văn bản rõ ràng.
Yêu cầu của bạn cũng sẽ được hiển thị trong lịch sử trình duyệt. Người dùng có thể bị cám dỗ để đánh dấu trang web. Một số người dùng đã cài đặt công cụ đồng bộ hóa dấu trang, vì vậy mật khẩu có thể kết thúc trên deli.ci.us hoặc một số nơi khác.
Cuối cùng, ai đó có thể đã hack máy tính của bạn và cài đặt bộ ghi bàn phím hoặc trình quét màn hình (và rất nhiều loại virus Trojan Horse làm). Vì mật khẩu được hiển thị trực tiếp trên màn hình (trái ngược với "*" trong hộp thoại mật khẩu), đây là một lỗ hổng bảo mật khác.
Kết luận: Khi nói đến an ninh, luôn luôn dựa vào con đường bị đánh đập. Có quá nhiều thứ mà bạn không biết, sẽ không nghĩ đến và nó sẽ làm gãy cổ bạn.
Có, miễn là không ai nhìn qua vai bạn trên màn hình.
Tôi không đồng ý với tuyên bố về [...] Rò rỉ giới thiệu HTTP (hình ảnh bên ngoài trong trang đích có thể bị rò rỉ mật khẩu) trong phản hồi của Slough .
RFC HTTP 1.1 tuyên bố rõ ràng :
Khách hàng KHÔNG NÊN bao gồm trường tiêu đề Người giới thiệu trong yêu cầu HTTP (không bảo mật) nếu trang giới thiệu được chuyển với giao thức bảo mật.
Dù sao, nhật ký máy chủ và lịch sử trình duyệt là quá nhiều lý do để không đưa dữ liệu nhạy cảm vào chuỗi truy vấn.
Bạn có thể gửi mật khẩu dưới dạng MD5 hash param với một chút muối được thêm vào. So sánh nó ở phía máy chủ cho auth.