URL https với thông số mã thông báo: nó an toàn như thế nào?

Trên trang web của chúng tôi, chúng tôi cung cấp cho người dùng mô phỏng dựa trên thông tin cá nhân của họ (được cung cấp thông qua biểu mẫu). Chúng tôi muốn cho phép họ lấy lại kết quả mô phỏng sau này, nhưng không buộc họ phải tạo tài khoản đăng nhập / mật khẩu.

Chúng tôi đã nghĩ đến việc gửi cho họ một email có liên kết, từ đó họ có thể lấy lại kết quả của mình. Tuy nhiên, theo lẽ tự nhiên, chúng tôi phải bảo mật URL này, vì dữ liệu cá nhân đang bị đe dọa.

Vì vậy, chúng tôi đang có ý định chuyển một mã thông báo (như sự kết hợp 40 ký tự của các chữ cái và chữ số, hoặc MD5 Hash) trong URL và sử dụng SSL.

Cuối cùng, họ sẽ nhận được một email như vậy:

Xin chào,
Lấy lại kết quả của bạn trên https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

Bạn nghĩ gì về nó? Nó có đủ an toàn không? Bạn sẽ khuyên tôi điều gì cho việc tạo mã thông báo? Điều gì về việc chuyển các tham số URL trong một yêu cầu https?

SSL sẽ bảo vệ các tham số truy vấn khi chuyển tiếp; tuy nhiên, bản thân email không an toàn và email có thể bị trả lại dọc theo bất kỳ số lượng máy chủ nào trước khi đến đích.

Cũng tùy thuộc vào máy chủ web của bạn, URL đầy đủ có thể được ghi vào các tệp nhật ký của nó. Tùy thuộc vào mức độ nhạy cảm của dữ liệu, bạn có thể không muốn nhân viên CNTT của mình có quyền truy cập vào tất cả các mã thông báo.

Ngoài ra, URL với chuỗi truy vấn sẽ được lưu trong lịch sử người dùng của bạn, cho phép những người dùng khác trên cùng một máy truy cập vào URL.

Cuối cùng và điều làm cho điều này trở nên rất không an toàn là, URL được gửi trong tiêu đề Người giới thiệu của tất cả các yêu cầu cho bất kỳ tài nguyên nào, ngay cả tài nguyên của bên thứ ba. Vì vậy, nếu bạn đang sử dụng Google Analytics chẳng hạn, bạn sẽ gửi cho Google mã thông báo URL trong và tất cả cho họ.

Theo tôi đây là một ý kiến ​​tồi.

Tôi sẽ sử dụng một cookie cho điều đó. Quy trình làm việc phải như thế này:

1. Người dùng đến trang web của bạn lần đầu tiên.
2. Trang web đặt một cookie
3. Người dùng nhập dữ liệu. Dữ liệu được lưu trữ trong DB bằng một số khóa được lưu trữ trong cookie.
4. Khi người dùng rời đi, bạn sẽ gửi cho họ một email có liên kết https:
5. Khi người dùng quay lại, trang web phát hiện ra cookie và có thể hiển thị cho người dùng dữ liệu cũ.

Bây giờ, người dùng muốn sử dụng một trình duyệt khác trên một máy khác. Trong trường hợp này, hãy đưa ra một nút "chuyển". Khi người dùng nhấp vào nút này, cô ấy sẽ nhận được một "mã thông báo". Cô ấy có thể sử dụng mã thông báo này trên một máy tính khác để đặt lại cookie. Bằng cách này, người dùng quyết định mức độ an toàn mà họ muốn chuyển mã thông báo.

SSL bảo mật nội dung của dữ liệu khi chuyển tiếp, nhưng tôi không chắc về URL.

Bất kể, một cách để giảm thiểu kẻ tấn công sử dụng lại mã thông báo URL đó là đảm bảo mỗi mã thông báo chỉ có thể được sử dụng một lần. Bạn thậm chí có thể đặt một cookie để người dùng hợp pháp có thể tiếp tục sử dụng liên kết, nhưng sau lần truy cập đầu tiên, nó sẽ chỉ hoạt động đối với người có cookie.

Nếu email của người dùng bị xâm phạm và kẻ tấn công lấy được liên kết trước tiên thì bạn đã bị tấn công. Nhưng người dùng còn có những vấn đề lớn hơn.

Thư điện tử vốn dĩ không an toàn. Nếu ai đó có thể nhấp vào liên kết đó và truy cập vào dữ liệu, bạn không thực sự bảo vệ nó.

Mã thông báo được bảo mật khi được chuyển qua SSL. Vấn đề bạn sẽ gặp phải là nó có thể sử dụng được cho mọi người (những người không dành cho nó) bằng cách có thể xem URL.

Nếu đó là thông tin riêng tư như SSN, tôi không nghĩ mình sẽ gửi URL qua email. Tôi muốn họ tạo tên người dùng và mật khẩu cho trang web. Quá dễ dàng để thỏa hiệp một email với loại thông tin đó đang bị đe dọa cho bạn và cho họ. Nếu tài khoản của ai đó bị so sánh, nó sẽ rơi vào tình trạng khó xử, đó thực sự là lỗi của ai. Bạn càng an toàn càng tốt theo quan điểm CYA nghiêm ngặt.

Tôi thực sự sẽ không cho rằng điều đó đủ an toàn cho tình huống có các vấn đề nghiêm trọng về quyền riêng tư. Thực tế là bạn đang gửi URL trong một email (có thể là văn bản rõ ràng) cho đến nay là liên kết yếu nhất. Sau đó là nguy cơ bị tấn công vũ phu vào các mã thông báo (thiếu cấu trúc của cơ chế xác thực thực) có khả năng dễ bị tấn công hơn so với tên người dùng và mật khẩu được xây dựng tốt.

Không có vấn đề gì với các tham số trong một yêu cầu https, ngẫu nhiên.

Đúng như vậy, đó sẽ là một ý tưởng tồi. Bạn sẽ xác minh bảo mật với cách sử dụng dễ dàng. Như đã nói trước đây, SSL sẽ chỉ bảo vệ việc truyền thông tin giữa máy chủ và trình duyệt máy khách và sẽ chỉ ngăn chặn cuộc tấn công của kẻ trung gian. Email rất rủi ro và không an toàn.

Tốt nhất là xác thực tên người dùng và mật khẩu để truy cập thông tin.

Tôi thích ý tưởng cookie ít nhiều. Bạn cũng nên mã hóa thông tin cookie. Bạn cũng nên tạo mã thông báo với muối và cụm từ khóa cộng với $ _SERVER ['HTTP_USER_AGENT'] để hạn chế xác suất bị tấn công. Lưu trữ càng nhiều thông tin vô nghĩa về khách hàng trong cookie để sử dụng xác minh.

Cụm từ khóa có thể được lưu trong cookie để dễ sử dụng nhưng hãy nhớ rằng cookie cũng có thể bị đánh cắp = (.

Tốt hơn hãy để khách hàng nhập cụm từ khóa mà anh ta đã cung cấp, cụm từ này cũng được lưu trữ trong cơ sở dữ liệu cùng với dữ liệu của anh ta.

Hoặc, khóa có thể được sử dụng trong trường hợp một người sử dụng một máy khác có thông số $ _SERVER ['HTTP_USER_AGENT'] hoặc đơn giản là bỏ lỡ cookie. Vì vậy, cookie có thể được chuyển giao hoặc thiết lập.

Cũng đảm bảo rằng dữ liệu nhạy cảm được mã hóa trong cơ sở dữ liệu. Bạn không bao giờ biết ;)

Bạn có biết rằng nếu bất kỳ hacker nào truy cập vào cơ sở dữ liệu của bạn thì rất nhiều thông tin cá nhân có thể được cung cấp miễn phí?

Sau đó, tôi sẽ nói rằng điều này không tồi như ý tưởng. Tôi sẽ không sử dụng MD5 hoặc SHA1 vì chúng không an toàn lắm để băm. Chúng có thể được "giải mã" (tôi biết đó không phải là mã hóa) khá dễ dàng.

Nếu không, tôi có thể sử dụng thông tin thứ hai không được gửi qua email như một loại mật khẩu. Lý do khá đơn giản, nếu ai đó có quyền truy cập vào email của người dùng (khá dễ dàng với hotmail nếu bạn không giết phiên của mình) thì người đó sẽ có quyền truy cập vào bất kỳ thông tin nào mà người dùng đã gửi.

Lưu ý rằng HTTPS sẽ bảo mật và mã hóa dữ liệu được gửi từ trang web của bạn đến người dùng cuối. Không có gì khác, hãy coi nó như một tunel an toàn. Không có gì hơn nothign ít hơn.

Theo những gì tôi hiểu về ý tưởng của bạn, về lý thuyết, ai đó có thể nhập một chuỗi 40 ký tự ngẫu nhiên hoặc mã băm MD5 và nhận được thông tin chi tiết của ai đó. Trong khi điều này có thể rất khó xảy ra nhưng chỉ cần xảy ra một lần.

Một cách độc lập tốt hơn có thể là gửi cho người dùng một mã thông báo sau đó yêu cầu họ nhập một số thông tin chi tiết, chẳng hạn như tên, mã bưu điện, ssn hoặc kết hợp các thông tin này.