2010-07-15 28 views
14

Điều này sẽ hơi khó giải thích nhưng tôi sẽ cố hết sức.

Có một trang web có biểu mẫu đăng nhập trên mọi trang có trường tên người dùng/mật khẩu. Các trang này không sử dụng SSL. Sau khi người dùng điền vào tên người dùng/mật khẩu và gửi biểu mẫu, biểu mẫu được gửi đến trang xác thực là https.Sau khi đăng nhập, tất cả các trang có phải là https không?

Tôi có một vài câu hỏi về tình huống này.

  1. Khi gửi biểu mẫu đến trang https, dữ liệu có được mã hóa không? Hoặc chỉ sau khi đi từ một trang https (tôi giả định chỉ đi từ)?
  2. Nếu câu trả lời cho số một là bậc thang, điều này có nghĩa là tôi sẽ cần sử dụng https cho tất cả các trang vì biểu mẫu đăng nhập đang được chuyển hướng từ đó?
  3. Sau khi người dùng được xác thực bằng https, người dùng có thể được chuyển hướng trở lại http và tiếp tục sử dụng dữ liệu phiên không? Hoặc người dùng có nên ở dạng https không?
  4. Tốt hơn/tệ hơn là để người dùng ở dạng https?

Cảm ơn bạn rất nhiều vì đã trợ giúp!
Metropolis

KẾT LUẬN

Ok, vì vậy sau khi suy nghĩ về vấn đề này cho một lúc tôi đã quyết định chỉ làm cho toàn bộ điều https. @Mathew + @Rook, câu trả lời của bạn đều tuyệt vời và tôi nghĩ cả hai bạn đều có những điểm tuyệt vời. Nếu tôi ở trong một tình huống khác, tôi có thể đã làm điều này một cách khác nhau, nhưng đây là lý do của tôi để làm cho toàn bộ điều https.

  1. Sẽ dễ dàng hơn để kiểm soát các yêu cầu trang vì tôi chỉ phải ở lại https.
  2. Im không quá quan tâm với performace (trong một tình huống tôi có thể có được)
  3. tôi sẽ không cần phải tự hỏi, nếu các dữ liệu người dùng được bảo đảm ở mọi nơi
  4. tôi sẽ được sau phương châm OWASP như Rook nói

Trả lời

10

Theo The OWASP top 10 tại thời điểm không thể sử dụng id phiên được xác thực qua HTTP. Vì vậy, bạn tạo một phiên trên HTTP và sau đó phiên đó được xác thực, sau đó bạn đã vi phạm The OWASP Top 10 và bạn đang cho phép người dùng của bạn dễ bị tấn công.

Tôi khuyên bạn nên đặt secure flag on your cookie. Đây là một tên khủng khiếp cho tính năng này nhưng nó buộc cookie chỉ là https. Điều này không nên nhầm lẫn với "cookie Httponly", đó là một cờ khác nhau hữu ích trong việc giảm thiểu tác động từ xss.

Để đảm bảo người dùng của bạn an toàn, tôi sẽ buộc sử dụng HTTPS mọi lúc. ssl là một giao thức rất nhẹ, nếu bạn gặp phải các vấn đề về tài nguyên, hãy xem xét việc chuỗi các chính sách https của bạn.

+0

Tại sao trang web này sử dụng http mọi lúc, ngoại trừ khi đăng nhập? Tôi sẽ phải giả định họ đang sử dụng phiên? – Metropolis

+0

Vâng, như tôi đã nói đó là một sự đánh đổi. Có thể chặn và ăn cắp cookie phiên StackOverflow. Họ quyết định họ sẵn lòng mạo hiểm khả năng đó. –

+0

@ Thủ đô vì đây là một vi phạm owasp rất phổ biến. SO cũng không an toàn 100% (http://meta.stackexchange.com/questions/46671/captcha-bypass) – rook

6
  1. Có. Nếu URL hành động là https, dữ liệu biểu mẫu được mã hóa.
  2. Vì # 1 bạn không phải tạo trang https, nhưng bạn có thể nhận được cảnh báo nội dung hỗn hợp. Và tất nhiên, kẻ tấn công trung gian có thể thao túng trang đăng nhập để trỏ đến một URL hành động khác.
  3. Đây là quyết định để bạn thực hiện. Rõ ràng, bất kỳ dữ liệu nào được truyền qua HTTP, cho dù cookie (bao gồm cookie phiên) hay dữ liệu người dùng, đều có thể bị chặn và thao tác.
  4. Một lần nữa, đây là sự cân bằng dựa trên hiệu suất và bảo mật.
+0

# 3 là một vi phạm nợ. Tôi sẽ cung cấp cho bạn một -1 cho điều đó. – rook

+3

@ The Rook, tôi không bao giờ nói rằng nó sẽ là OWASP tuân thủ một trong hai cách. I * đã * nói rằng HTTP cho phép mọi người chặn và thao tác dữ liệu phiên. –

+0

Vâng, tôi không nghĩ bạn đang dẫn đầu người lạc lối. – rook

3

Ngoài những gì The Rook nói, nộp một mẫu đơn từ http đến https là một nguy cơ cho một vài lý do:

  1. Không có "khóa" biểu tượng trên trang nơi người gõ vào tên người dùng và mật khẩu của họ, vì vậy họ không có cách nào để biết chi tiết của họ được mã hóa (ngoại trừ bằng cách "tin tưởng bạn")
  2. Nếu ai đó xâm nhập trang của bạn, người dùng của bạn sẽ không biết cách họ sắp nhập tên người dùng và mật khẩu của họ và được chuyển hướng đến một trang độc hại (điều này phần nào là một hệ quả của # 1).

Đây là một cuộc tấn công đơn giản hơn nhiều so với http Cookie đánh chặn, do đó, nó thực sự là một nguy cơ lớn hơn ...

Nhưng điểm của Rook là quan trọng: bạn nên bao giờ trộn http và https giao thông. Trên trang web của chúng tôi, ngay sau khi bạn đăng nhập, mọi thứ là https từ thời điểm đó trở đi.

2

Ngoài các câu trả lời trước, vì mọi người có xu hướng muốn chuyển từ HTTPS sang HTTP vì lý do hiệu suất, this article about HTTPS at Google có thể được quan tâm. Thông điệp chính của nó là:

SSL/TLS không được tính toán đắt hơn nữa.

+0

Liên kết tới imperialviolet.org không phải với Google như tôi mong đợi từ "tại Google" và liên kết bị hỏng. –

+0

@Stephen P, vâng, rất tiếc, liên kết hiện không hoạt động. Nếu bạn google liên kết, bạn sẽ có thể tìm thấy bài viết trong bộ nhớ cache. Mặc dù thật khó để xác minh thực sự, họ nói về công việc "[của họ] tại Google". Bài viết bắt đầu bằng "(Đây là một bài viết mà tôi đã đưa ra tại [Velocity 2010] (http://conferences.oreilly.com/velocity) Thứ năm tuần trước. Đây là một tác phẩm chung của bản thân tôi, Nagendra Modadugu và Wan -Teh Chang.) ", Xem http://en.oreilly.com/velocity2010/public/schedule/detail/14217 – Bruno

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