2010-03-30 26 views
14

Chỉ là một câu hỏi nhanh cho bất kỳ chuyên gia nào. Tôi có một trang web cho phép người dùng tương tác thông qua tin nhắn và đăng ký bạn chỉ cần tạo tên người dùng và mật khẩu, xác minh tuổi của bạn và tùy chọn thêm email. Không có bất kỳ thông tin nhạy cảm nào mà tôi cho là. Có đáng sử dụng https không. Nó sẽ ngăn chặn phiên hi jacking và nó sẽ cản trở hiệu suất?Có đáng sử dụng https nếu bạn không thực hiện các giao dịch tài chính không?

+0

BTW, Bạn nhận được câu trả lời sai. Nó đi ngược lại top 10 của OWASP để bảo mật phiên.Toàn bộ phiên phải được bảo vệ bằng https hoặc không có điểm. – rook

+0

@ The Rook: Bởi lý do đó, khóa cửa trước của tôi hoàn toàn vô dụng, vì có nhiều cách để vượt qua nó. Nó sẽ ngăn chặn tên trộm thường không muốn làm hại có thể nhìn thấy, và đó là một lợi thế. Sẽ tốt hơn nếu toàn bộ phiên là https (mặc dù đó là điều dễ bị tổn thương đối với man-in-the-middle với hầu hết các chứng chỉ), nhưng thực hiện nó chỉ để đăng nhập và như vậy sẽ ngăn chặn một số cuộc tấn công. –

+0

@david, Trên thực tế có cửa trước của bạn là vô dụng nó có thể được chọn khá dễ dàng, pin tumblers là một công nghệ khủng khiếp. Ngoài ra, tôi đồng ý với owasp, nếu bạn bị rò rỉ id phiên của bạn thì kẻ tấn công có thể sử dụng nó như thể họ đã có mật khẩu. Ngoài ra SSL/TLS dừng MITM, đó là những gì nó được xây dựng cho. (Bỏ qua SSLStrip vì lợi ích của đối số;) – rook

Trả lời

20

Bất cứ khi nào bạn sử dụng tên người dùng/mật khẩu, bạn hoàn toàn nên bảo toàn toàn bộ phiên bằng HTTPS. Chi phí cho bạn là khá nhỏ so với chi phí tiềm năng cho người dùng của bạn nếu mật khẩu của họ được tiếp xúc. Nghiên cứu consistently shows mà mọi người sử dụng cùng một mật khẩu cho hầu hết mọi hệ thống họ truy cập.

Ngoài ra, ngoài nguy cơ tiếp xúc mật khẩu, hãy xem xét trang web của bạn là công cụ liên lạc. Nguy cơ hoặc nguy cơ tiềm ẩn cho người dùng của bạn bị mạo danh là gì? Có tin nhắn độc hại được gửi dưới danh tính của họ?

Nó không đáng để mạo hiểm. Đảm bảo vận chuyển ít nhất.

+1

câu trả lời tuyệt vời, cảm ơn người đàn ông – Scarface

+0

-1 Sau khi người dùng đăng nhập vào kẻ tấn công sẽ chỉ chiếm đoạt ID phiên. Toàn bộ phiên phải được bảo vệ bằng https, đây là trong đầu OWASP 10. – rook

+0

rook bạn đang nói về cái gì, bạn có thể cụ thể hơn lol không. Làm thế nào bạn có thể sử dụng https thông qua một cổng cụ thể, và chỉ bảo vệ một phần của một phiên. Làm thế nào là câu trả lời sai, ông chỉ đề xuất bảo vệ tương tác máy chủ thông qua một giao thức được mã hóa. Không phải phiên được tự động bảo vệ bằng https nếu đó là những gì máy chủ của bạn đang sử dụng để giao tiếp? – Scarface

3

Nó rất đáng giá ít nhất nếu bạn truyền mật khẩu và địa chỉ email hoặc bất kỳ thông tin nhận dạng cá nhân hoặc cá nhân nào khác. Có thể cướp quyền truy cập phiên nếu có bất kỳ giao tiếp không phải HTTPS nào là nhưng đó là rủi ro mà nhiều trang web sẵn sàng chấp nhận và tùy thuộc vào tình huống của bạn.

Sự cố về hiệu suất phụ thuộc vào phần cứng và ngăn xếp của bạn, nhưng sẽ có một số "hiệu suất" được truy cập từ HTTPS và HTTP. Nó không đủ để ngăn bạn bảo vệ mật khẩu và thông tin người dùng nhạy cảm.

+0

cảm ơn lời khuyên. – Scarface

0

Tôi cũng đã nghĩ về điều này trước đây. Tôi nghĩ bạn sẽ muốn có kết nối an toàn khi người dùng đăng nhập hoặc thay đổi thông tin.

14

Tôi nghĩ rằng ngay sau khi bạn có một số loại xử lý đăng nhập, bạn nên bảo vệ mật khẩu của người dùng. Bạn có thể thực hiện điều đó thông qua https hoặc bằng cách sử dụng xác thực thông báo http.

Điểm chính của tôi để mã hóa là khá nhiều người dùng của bạn sẽ có cùng một mật khẩu cho trang web của bạn khi họ có vào tài khoản ngân hàng hoặc tài khoản tương tự. Mặc dù thông tin tại trang web của bạn không nhạy cảm, nhưng mật khẩu thực sự có thể bảo vệ điều gì đó quan trọng.

+0

đánh giá cao chuyên môn, tôi nghĩ cả câu trả lời của bạn và câu chuyện của dan đều tuyệt vời, tôi đã bình chọn cho các bạn. – Scarface

+0

-1 Sau khi người dùng đăng nhập vào kẻ tấn công sẽ chỉ chiếm đoạt ID phiên. Toàn bộ phiên phải được bảo vệ bằng https, đây là trong đầu OWASP 10. Tôi ước tôi có thể cung cấp cho -1 khác cho auth tiêu hóa, bởi vì nó thậm chí còn kém an toàn hơn. – rook

+0

xem nhận xét của tôi về câu trả lời. – Scarface

-2

Tuy nhiên, đối với một số người, mật khẩu và tuổi sẽ được coi là thông tin nhạy cảm. Bạn đã chuẩn bị để đối phó với một số người có thể có một quan điểm khác với bạn?

4

Có, SSL/TLS là bắt buộc để duy trì phiên được xác thực an toàn. Nếu bạn có thông tin đăng nhập, thì bài đăng của người đăng nhập và PHIÊN BẢN TOÀN BỘ phải được bảo vệ bằng https. Nó dễ dàng hơn và an toàn hơn để chuyển tiếp tất cả lưu lượng truy cập đến https, ngay cả khi bạn có một ứng dụng web đơn giản.

Vấn đề là một id phiên (cookie) có thể bị rò rỉ nếu bạn sử dụng http. Nếu phiên đó được xác thực thì hacker có thể sử dụng id phiên đó để xác thực với máy chủ mà không có tên người dùng và mật khẩu.

Đây là yêu cầu rõ ràng của The OWASP top 10 A3: "Broken Authentication và Quản lý Session" http://www.owasp.org/images/0/0f/OWASP_T10_-_2010_rc1.pdf

Gửi một cookie trên http cũng là một vi phạm CWE-614CWE-311.

+0

cảm ơn bạn đã phá vỡ nó. – Scarface

+0

@Scarface Chào mừng bạn, bạn nên trao giải đáp cho tôi. Bởi vì top 2 là không chính xác, ai đó có thể bị tấn công. – rook

+0

Lưu ý rằng điều này quan trọng nhất nếu ai quan tâm nếu có một chút giả mạo đang diễn ra. –

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