2009-05-06 27 views
28

Một đồng nghiệp và tôi đã có một cuộc tranh luận nóng bỏng ngày hôm qua liệu có an toàn khi gửi thông tin đăng nhập thông qua các tham số URL như một phương tiện xác thực hay không. Ông đã chỉ ra rằng HTTPS mã hóa tất cả các ký tự không phải tên máy chủ/cổng trong một URL trước khi gửi yêu cầu đến phía máy chủ.Tên người dùng và mật khẩu có thể được gửi an toàn qua HTTPS thông qua thông số URL không?

Tuy nhiên, tôi vẫn nghĩ có những trường hợp cạnh ở đây, nơi có thể lấy cắp các thông tin đăng nhập này và tin rằng chúng sẽ được gửi qua một POST HTTPS. Đây có phải là phương tiện an toàn để gửi dữ liệu đăng nhập/mã thông báo không?

+1

Ý của bạn là SSL thay vì SSH? – Greg

+0

SSH không có ý nghĩa. SSL có thể sử dụng trong các ngữ cảnh khác với HTTPS, nhưng điều này là đủ gần. – MSalters

+0

Có, ý tôi là HTTPS chứ không phải SSL. Tôi đã sửa tiêu đề. –

Trả lời

37

URL được yêu cầu có thể hiển thị trong bản ghi máy chủ Weblịch sử trình duyệt/bookmarks mà không phải là một điều tốt.

+0

Nếu cặp tên người dùng-mật khẩu là một lần- sử dụng (ví dụ như OTP), nó thực sự là một chương trình an toàn tuyệt đối để gửi chúng qua URL. Thông tin thêm @ http://stackoverflow.com/q/4833314/632951 – Pacerier

5

An toàn là một từ lớn. SSH sẽ ngăn những người dùng khác truy xuất nó, nhưng bạn có thực sự muốn hiển thị mật khẩu của ai đó trên chuỗi truy vấn hay không. Còn anh chàng đứng trên vai người dùng thì sao? Điều gì về SQL injection? Ý tưởng thực sự tồi tệ, ít nhất là nhét nó trong một bài đăng mẫu.

4

Tôi cũng không biết HTTPS đã mã hóa URL là điều tốt.

Tuy nhiên, từ quan điểm bảo mật, tôi sẽ bị làm phiền hơn bởi thực tế là các thông tin đăng nhập có thể được đọc trong thanh URL. Chưa kể có thể được lưu trữ trong lịch sử trình duyệt.

8

Theo như việc truyền thông tin đăng nhập có liên quan, anh ấy đúng. Nhưng có rất nhiều thứ khác để xem xét, như lịch sử brwser, logfiles máy chủ, người dùng xem màn hình vv mà sẽ là một nguy cơ trong trường hợp đó.

26

Thực hiện thêm một bước nếu bạn có cơ sở dữ liệu phía sau. Gửi tên người dùng và mật khẩu qua một bài đăng biểu mẫu, có mã trả lại back-end (một guid sẽ làm), viết mã thông báo vào bảng cơ sở dữ liệu và gán thời gian hết hạn, sau đó sử dụng mã thông báo đó trong chuỗi truy vấn thay cho thông tin đăng nhập . Bây giờ hệ thống của bạn sẽ rất an toàn và bạn có một mã định danh phiên duy nhất làm cộng.

+8

+1 Để cung cấp giải pháp và không chỉ là câu trả lời. –

+0

Tại sao không phải OAuth? – Victor

1

Ngoài ra còn có một giải pháp khác mà tôi đang cố gắng. Bạn có thể sử dụng trình xử lý PHP cho phiên làm việc, để lưu trữ dữ liệu phiên trực tiếp vào cơ sở dữ liệu của bạn dưới dạng chuỗi dễ dàng với các trình xử lý của nó. Bạn sẽ cần một bảng phiên trong DB của bạn với thời gian hết hạn. Khi bạn gửi dữ liệu đăng nhập HTTPS, nếu đúng, bạn có thể lưu nó trong biến $ _SESSION và nếu bạn làm tốt giao diện, nó sẽ chuyển đến DB của bạn. Vì điều này không được hiển thị bên ngoài PHP, bạn sẽ có một hệ thống đăng nhập mạnh mẽ và trong cookie của khách hàng, chỉ có ID phiên được lưu trữ thay vì mã thông báo, tài khoản hoặc dữ liệu nhạy cảm khác.

Tham chiếu: http://es.php.net/manual/en/function.session-set-save-handler.php

Các vấn đề liên quan