Cách ngăn chặn tấn công phát lại biểu mẫu/man-in-the-middle trong PHP, csrf, xsrf

Question

Tôi có biểu mẫu web và tôi đang sử dụng PHP. Tôi biết rằng các biểu mẫu có thể được điều khiển (tôi tin rằng nó được gọi là tấn công phát lại hoặc một cuộc tấn công giữa người). Vì vậy, tôi muốn sử dụng mã thông báo xác thực như một trường ẩn.

Các khả năng đe dọa rằng tôi nhận thức được là:

• Attacker hijacks dạng của người sử dụng hợp pháp (điều này tôi tin là man-in-the-middle tấn công)
• người sử dụng hợp pháp là chính mình kẻ tấn công: anh ta nhận được biểu mẫu, đọc mã thông báo nhưng sử dụng nó để gửi dữ liệu nguy hiểm (điều này tôi tin là tấn công phát lại)

Trước khi tôi nhận được câu hỏi, hãy sửa tôi nếu bất cứ điều gì tôi đã nói cho đến nay là không chính xác, bởi vì có lẽ sự hiểu biết của tôi là thiếu sót.

Bây giờ đến câu hỏi:

• các thực hành tốt nhất để tạo ra dấu hiệu này để các hình thức mà không có nó bị từ chối là gì (ví dụ, muối?).
• Mọi người làm gì để đảm bảo mã thông báo không được phát lại.

mới hỏi nhỏ dựa trên nhận xét:

• là phiên tặc giống như man-in-the-middle tấn công?

Answer 1

Bạn đã đề cập đến CSRF trong tiêu đề nhưng không thực sự bao gồm nó trong câu hỏi của bạn.

Bạn có thể đọc chi tiết online, nhưng CSRF cơ bản là một cuộc tấn công cho phép người dùng hợp pháp gửi tới trang web một cách vô tình. Ví dụ, nếu SO không bảo vệ chống lại các cuộc tấn công như vậy, tôi có thể tạo ra một biểu mẫu khiến cho thông tin hồ sơ SO của bạn bị thay đổi khi bạn bấm vào biểu mẫu xấu của tôi, mong đợi điều gì đó khác xảy ra ("Kiếm một triệu đô la !! Bấm vào đây!!"). Biểu mẫu này sẽ sử dụng cookie trình duyệt của bạn để xác thực bạn với SO và làm cho nó xuất hiện để SO rằng bạn đã nộp các bản cập nhật hợp lệ cho tiểu sử của mình.

Để bảo vệ chống lại điều này, bạn thực sự muốn làm một vài điều:

• đảm bảo rằng GET không gây cập nhật (ví dụ, không đăng cập nhật trạng thái mới cho một lý lịch thành viên sử dụng tham số truy vấn trên GET)
• đảm bảo rằng tất cả POST được đi kèm với trường ẩn cho phép bạn xác thực rằng biểu mẫu đã được tạo bởi dịch vụ của bạn chứ không phải bởi người khác và biểu mẫu đó dành cho người dùng dự định. Vì vậy, trường ẩn này phải được tạo bởi máy chủ mỗi khi nó gửi xuống html cho biểu mẫu và phải là duy nhất cho người dùng đó cho phiên đó.

Một thay thế cho mục thứ hai đó là kiểm tra xem liên kết giới thiệu luôn là trang web của bạn hoặc trang web bạn mong đợi POST. Tôi không khuyến khích điều này cho các trang không phải HTTPS vì một số phần mềm trình duyệt/phần mềm mạng loại bỏ các liên kết giới thiệu và không phải luôn luôn đáng tin cậy khi có liên kết giới thiệu.

Answer 2

Phương pháp được sử dụng để tạo mã thông báo không quan trọng lắm. Điều quan trọng là mã thông báo chỉ được sử dụng một lần. Giữ một danh sách mã thông báo được tạo cho người dùng trong phiên của người dùng. Nếu người dùng gửi biểu mẫu và mã thông báo được gửi không có trong phiên, bạn có thể từ chối biểu mẫu.

Bảo vệ chống lại người ở giữa là một chút khó khăn. Một kỹ thuật phổ biến mà tôi đã thấy là bao gồm tất cả các trường biểu mẫu ẩn trong hàm băm để tạo mã thông báo, và sau đó tạo lại mã thông báo dựa trên các trường ẩn đã biết. Tuy nhiên, điều đó sẽ chỉ bảo vệ chống lại thao tác ẩn trường, mà có thể không phải là mục tiêu cuối cùng của người đàn ông ở giữa.

Khi người dùng gửi thành công biểu mẫu có mã thông báo, hãy xóa mã thông báo khỏi phiên, vì vậy, phát lại của lần gửi đó sẽ không thành công. Tuy nhiên, tất cả những gì nó cần là người dùng yêu cầu lại biểu mẫu để tạo một mã thông báo khác. Mã thông báo mới sau đó có thể được sử dụng trong các cuộc tấn công tự động tiếp theo. Nói cách khác, các thẻ biểu mẫu có ích đối với CSRF, nhưng không hiệu quả cao so với các lần phát lại tự động và các cuộc tấn công trung gian.

Tương tự như vậy, bạn sẽ muốn điều chỉnh ứng dụng của mình để không yêu cầu sử dụng nút quay lại của người dùng trên biểu mẫu. Nếu có vấn đề với nội dung gửi của họ, bạn sẽ cần phải trả lại biểu mẫu cho người dùng với dữ liệu của họ được điền. Nếu người dùng truy cập nút quay lại của mình để sửa lỗi, lần gửi của cô ấy sẽ không thành công do hiện không hợp lệ mã thông báo. Ngoài ra, để thẳng thắn, vào thời điểm bạn cần phải lo lắng về yêu cầu replay và tấn công man-in-the-middle, kết nối của người dùng của bạn đã bị xâm phạm, và có lẽ bạn không thể làm gì để giảm thiểu thiệt hại .SSL một mình là một mức độ bảo vệ đầy đủ chống lại MITM và phát lại, và nếu bạn đang lo lắng về nó, bạn sẽ chạy theo SSL ...

Answer 3

Để tạo mã thông báo đó, đây là chiến lược tôi sử dụng có vẻ hoạt động tốt.

• Đặt cookie thành giá trị ngẫu nhiên (được tạo trên máy chủ bằng thủ thuật thông thường) và đặt nó hết hạn theo nhu cầu của bạn.
• Khi phục vụ một trang có biểu mẫu, hãy nhúng trường ẩn có giá trị bằng với giá trị của cookie này.
• Khi xử lý các bưu điện, xác nhận rằng lĩnh vực này tồn tại, và rằng giá trị phù hợp với cookie của người dùng

Answer 4

CSRF-magic là một lớp học tuyệt vời cho thẻ CSRF, nó đặt chúng vào trang của bạn tự động

http://csrf.htmlpurifier.org/

"csrf-magic sử dụng khả năng đệm đầu ra của PHP để ghi đè động các biểu mẫu và tập lệnh trong tài liệu của bạn. Điều này có nghĩa, đối với một w truyền thống ebsite với các hình thức, bạn có thể thả csrf-ma thuật vào ứng dụng của bạn và quên nó đi! "