Các vectơ tấn công cho mật khẩu được gửi qua http là gì?

Tôi đang cố gắng thuyết phục một khách hàng trả tiền SSL cho một trang web yêu cầu đăng nhập. Tôi muốn đảm bảo rằng tôi hiểu chính xác các kịch bản chính trong đó ai đó có thể thấy mật khẩu đang được gửi.

Hiểu biết của tôi là tại bất kỳ bước nhảy nào trên đường đi đều có thể sử dụng bộ phân tích gói để xem những gì đang được gửi. Điều này dường như yêu cầu bất kỳ tin tặc nào (hoặc phần mềm độc hại / botnet của chúng) phải ở trên cùng một mạng con như bất kỳ bước nhảy nào mà gói tin sẽ đến đích. Có đúng không?

Giả sử một số hương vị của yêu cầu mạng con này là đúng, tôi có cần phải lo lắng về tất cả các bước nhảy hay chỉ là bước đầu tiên? Điều đầu tiên tôi rõ ràng có thể lo lắng nếu chúng ở trên mạng Wifi công cộng vì bất kỳ ai cũng có thể nghe. Tôi có nên lo lắng về những gì đang diễn ra trong các mạng con mà các gói sẽ truyền qua bên ngoài này không? Tôi không biết nhiều về lưu lượng truy cập mạng, nhưng tôi sẽ cho rằng nó chảy qua các trung tâm dữ liệu của các nhà mạng lớn và không có nhiều vectơ tấn công ngon ngọt ở đó, nhưng vui lòng sửa cho tôi nếu tôi sai.

Có các vectơ khác phải lo lắng về việc bên ngoài ai đó đang nghe với một bộ phân tích gói không?

Tôi là một noob mạng và bảo mật, vì vậy xin vui lòng đặt thẳng cho tôi nếu tôi sử dụng thuật ngữ sai trong bất kỳ điều này.

Một điều cần lưu ý mà những người khác chưa đề cập ở đây là một số trình duyệt lưu dữ liệu biểu mẫu của bạn. Hành vi mặc định trên các trang SSL thường là không lưu trữ bất cứ thứ gì trừ khi bạn chọn "lưu mật khẩu của tôi". Thông thường, các trường mật khẩu không lưu cache, nhưng tôi đã thấy một số điều kỳ lạ (thường là thông tin thẻ tín dụng, mà tôi biết không thực sự là chủ đề của câu hỏi).

Một điều khác cần lưu ý là Mã hóa SSL bắt đầu khi bắt tay TCP. Khi ở dưới SSL, bạn không thể phân biệt HTTP qua SSL với FTP qua SSL (ngoài các giả định được thực hiện qua số cổng).

Bạn cũng không thể phân biệt yêu cầu đăng nhập với yêu cầu "Tôi chỉ duyệt", điều này làm xáo trộn luồng trang từ tin tặc và cũng đảm bảo không chỉ dữ liệu mật khẩu của bạn an toàn, mà cả lịch sử duyệt web / dữ liệu cookie / và bất kỳ thông tin cá nhân đi cùng với tài khoản của bạn.

Tất cả trong tất cả nếu bạn loại bỏ các cuộc tấn công trung gian khỏi phổ bạn đã cắt giảm rất nhiều các cuộc tấn công tiềm năng, điều đó không có nghĩa là trang web của bạn là "an toàn". Ngoài ra chính sách phân vùng sẽ giúp bảo vệ bạn khỏi các cuộc tấn công XSS vì bạn sẽ thực hiện thay đổi vùng nếu người dùng của bạn được chuyển hướng ra khỏi trang web của bạn.

Dữ liệu dễ bị tổn thương ở bất cứ đâu dọc theo tuyến đường, không chỉ giai đoạn đầu tiên hoặc cuối cùng. Một điều khá dễ hiểu là một hệ thống liên quan đến việc chuyển tìm kiếm tên người dùng, mật khẩu và dữ liệu nhạy cảm khác. Do đó, dữ liệu nhạy cảm chỉ nên truyền qua một liên kết được bảo mật mọi cách và tất nhiên đó chính xác là những gì SSL dành cho. Tùy thuộc vào dữ liệu nào có liên quan, có thể có luật pháp địa phương áp đặt SSL.

Có máy chủ proxy có thể lưu trữ dữ liệu.

Nhưng cũng có nghĩa vụ giữ an toàn mật khẩu của người dùng. Nhiều người dùng sử dụng một bộ mật khẩu giới hạn, vì vậy một trang web không an toàn có thể làm tổn hại mật khẩu homebank của họ chẳng hạn.

Phân tích của bạn là hợp lý, IMHO.

Điều cần lưu ý, tôi cho rằng, có thể có bộ nhớ cache trên đường đi của bạn. Vì vậy, nó có thể là yêu cầu được đăng nhập ở đâu đó (đặc biệt là nếu đăng nhập qua GET, sẽ rất tệ).

Có lẽ điều cần xem xét là hầu hết các truy cập mạng diễn ra trong một khu vực có rất nhiều người khác trên cùng một mạng. Work / Uni / School là những ví dụ chính. Ở nhà bạn có thể tranh luận rằng nó ít rủi ro hơn, bởi vì đó chỉ là những con đường trở lên mà bạn cần phải quan tâm.

Nhưng thực sự, không có câu hỏi ở đây. Bạn sử dụng SSL khi đăng nhập. Có lẽ lý lẽ hấp dẫn nhất đối với anh chàng sẽ là nó làm cho trang web của bạn có vẻ đáng tin hơn, vì - lý tưởng - công chúng sẽ không bao giờ đăng nhập vào một trang web không có màn hình đăng nhập dựa trên SSL .

Nhưng hãy thực tế. Gần như chắc chắn vectơ tấn công này không phải là cách hệ thống hoặc người dùng của anh ta sẽ bị xâm phạm.

HTH.

Tôi có thể đồng ý với suy nghĩ của KevinM về việc trả lời các câu hỏi của chính mình và John Gardeniers đang chỉ đúng hướng. Tôi cũng phải đồng ý với những gì silky nói, "lý tưởng - công chúng nói chung sẽ không bao giờ đăng nhập vào một trang web không có màn hình đăng nhập dựa trên SSL.", Và chỉ ra rằng, tuy nhiên, đây không phải là trường hợp đương đại ở tất cả.

Tôi không đồng ý với giọng điệu của silky (có thể là vô tình), dẫn đến nhận thức phổ biến rằng, "công chúng nói chung", là ngu ngốc. Khách hàng của KevinM rõ ràng không có khái niệm về nhu cầu SSL và đó là người bình thường của bạn một cách ngắn gọn. Họ không ngu ngốc, đơn giản là họ không biết. Nói rằng, "bạn cần điều này", sẽ phản hồi bất hợp pháp, "Tôi đã sống x năm mà không có nó, và tôi sẽ sống tốt hơn nữa", hoặc thậm chí là một phản ứng tồi tệ hơn, "Tôi ghét bị nói những gì tôi cần . " Vì vậy, hãy cẩn thận!

Mối quan tâm của bạn là hợp pháp, Kevin. Khách hàng của bạn không cần chứng chỉ SSL. Tôi nghĩ rằng mối quan tâm thực sự của bạn nên làm thế nào để bán chúng. Không phải chỉ có thông tin đăng nhập người dùng mới quan tâm, mà là thông tin đăng nhập của quản trị viên và nhà điều hành cũng sẽ được hưởng lợi từ việc được bảo vệ bởi SSL.

Vâng, có những điều khác cần quan tâm về vấn đề này, thậm chí còn hơn cả việc đánh hơi gói tin, chẳng hạn như XSS . Chúng rất nhiều, và được ghi chép lại .

trong toàn bộ tuyến đường được theo sau bởi gói, nếu có thể đánh hơi qua HTTP và dữ liệu có thể được nhìn thấy ... ngay cả khi bạn sử dụng HTTP trong Proxy như TOR ... bằng cách sử dụng thu thập tấn công, v.v. người ta có thể lừa Proxy để rò rỉ các gói dữ liệu ... vì vậy nếu có bất kỳ thứ gì nhạy cảm (mật khẩu, chi tiết cá nhân, hình ảnh riêng tư, v.v.) ... thì chỉ phù hợp để chuyển chúng qua HTTPS.

Điều đó cũng vậy, ngay cả HTTPS cũng dễ bị tổn thương khi triển khai sai và chúng là một số Tấn công SSL được áp dụng trên đó ... vẫn có thể tránh được những điều đó khi thực hiện cẩn thận.

Nhưng, sử dụng HTTP cho văn bản đơn giản cũng giống như mời ngay cả những đứa trẻ mới bắt đầu đánh hơi mật khẩu.