2008-10-13 32 views
11

Vì vậy, cách tốt nhất để ngăn chặn một cuộc tấn công XSRF cho một ứng dụng GAE là gì? Hãy tưởng tượng những điều sau:Làm cách nào để ngăn chặn tốt nhất các cuộc tấn công CSRF trong ứng dụng GAE?

  1. Bất kỳ ai cũng có thể thấy đối tượng công khai của người dùng và id db.Model được sử dụng để yêu cầu tìm ra đối tượng cần hiển thị. Người dùng độc hại hiện có id.
  2. Người dùng độc hại tạo đối tượng của riêng họ và kiểm tra biểu mẫu xóa. Bây giờ họ biết làm thế nào để xóa một đối tượng với một id nhất định.
  3. Người dùng độc hại được người dùng vô tội gửi yêu cầu xóa cho đối tượng của người dùng đó.

Tôi có thể thêm các bước nào để ngăn chặn # 3? Lưu ý rằng khi tôi nói ID, tôi đang sử dụng phần ID thực tế của khóa. Một ý tưởng tôi có là sử dụng giá trị khóa đầy đủ trong các yêu cầu xóa, nhưng điều đó có ngăn cản người dùng độc hại không thể tìm ra điều này không? Theo như tôi biết, điều quan trọng là một số kết hợp của loại lớp mô hình, id ứng dụng và id đối tượng đối tượng, vì vậy chúng có thể lấy được khóa từ id nếu chúng muốn.

Bất kỳ ý tưởng nào khác? Jeff đã viết a post about this và đề xuất một vài phương pháp - giá trị biểu mẫu ẩn sẽ thay đổi theo từng yêu cầu và giá trị cookie được ghi qua js vào biểu mẫu. Tôi sẽ không muốn loại trừ người dùng không phải javascript, vì vậy giải pháp cookie không tốt - đối với giá trị biểu mẫu ẩn, tôi sẽ phải ghi dữ liệu trên mọi yêu cầu hiển thị đối tượng xóa - không phải là tình huống lý tưởng cho khả năng mở rộng ứng dụng!

Có ý tưởng nào khác không?

Trả lời

11

Khi bạn tạo trang cho phép người dùng xóa đối tượng, tạo một mã thông báo ngẫu nhiên và đưa nó vào trường biểu mẫu ẩn. Cũng đặt cookie chỉ có HTTP với giá trị đó. Khi bạn nhận được yêu cầu xóa, hãy kiểm tra mã thông báo ngẫu nhiên từ biểu mẫu và giá trị từ kết hợp cookie.

Mã thông báo ngẫu nhiên của bạn không chỉ là một số ngẫu nhiên. Bạn nên mã hóa sự kết hợp của một số ngẫu nhiên và danh tính của người dùng, để làm cho nó khó khăn cho kẻ tấn công để giả mạo thẻ của riêng họ. Bạn cũng nên sử dụng các khóa mã hóa khác nhau cho giá trị được lưu trữ trong biểu mẫu và giá trị được lưu trữ trong cookie, vì vậy nếu một trong các mã thông báo bị rò rỉ thì vẫn khó cho kẻ tấn công giả mạo mã thông báo khác.

Cách tiếp cận này xác minh rằng yêu cầu xóa bắt nguồn từ biểu mẫu của bạn, bởi sự hiện diện của mã thông báo bảo mật trong biểu mẫu; và không yêu cầu ghi vào kho dữ liệu.

Cách tiếp cận này vẫn dễ bị tấn công tập lệnh chéo trang, nơi kẻ tấn công có thể truy xuất giá trị ẩn từ biểu mẫu hoặc gửi biểu mẫu, kiểm tra kỹ trang web của bạn về lỗ hổng tập lệnh chéo trang. Cách tiếp cận này cũng dễ bị tổn thương đối với các cuộc tấn công "clickjacking".

+0

Tôi thích cách tiếp cận của macbirdie, nhưng tôi thích điều này cung cấp bảo mật hợp lý mà không cần lưu trữ phía máy chủ. –

5

Đơn giản: Kiểm tra người giới thiệu. Đó là (cố tình) không thể thiết lập điều này bằng cách sử dụng Javascript, HTML forms, vv Nếu nó trống (một số proxy và trình duyệt strip referers) hoặc từ trang web của riêng bạn - hoặc cụ thể hơn từ nguồn dự kiến ​​- cho phép nó. Nếu không, từ chối nó và đăng nhập nó.

Chỉnh sửa: Jeff đã viết followup article bằng một vài cách để ngăn chặn các cuộc tấn công CSRF.

+0

Vì vậy, nếu ai đó đang kết nối với trang web của tôi qua proxy và chạy vào tấn công XSRF, họ sẽ không được bảo vệ? Ngoài ra, Jeff đã đề cập rằng các liên kết giới thiệu rất dễ bị giả mạo. Tôi biết rằng với tư cách là một người dùng, tôi có thể dễ dàng thực hiện việc này, nhưng một trang web nào đó có thể khiến trình duyệt báo cáo một liên kết giới thiệu khác? –

+0

Chúng sẽ chỉ không được bảo vệ nếu proxy hoặc trình duyệt của họ chặn người giới thiệu. Rất ít làm điều này, và bằng cách bảo vệ tất cả những người bạn _can_ bảo vệ, bạn làm cho cuộc tấn công không hấp dẫn. Và có, người giới thiệu là giả mạo, nhưng không phải bởi bất kỳ mã nào mà kẻ tấn công có thể thuyết phục người dùng thực thi trong trình duyệt của họ. –

+1

Không cho phép tiêu đề Người giới thiệu trống! Nếu trang HTTP được yêu cầu từ một trang HTTPS, [Referer is not sent] (http://stackoverflow.com/a/1361720/691281). Vì vậy, nếu biểu mẫu của bạn nằm trên trang HTTP, kẻ tấn công có thể khiến người gửi bị trống trong một cuộc tấn công CSRF. Ngay cả khi biểu mẫu của bạn ở trên trang HTTPS, tôi sẽ rất nghi ngờ về tiêu đề Người giới thiệu trống. –

4

Trong phản hồi của máy chủ hiển thị biểu mẫu tạo một băm ma thuật (dựa trên client ip + date/time + random salt, bất cứ điều gì). Đặt nó vào một cookie và lưu trữ một nơi nào đó trên máy chủ. Trong quá trình xử lý tác vụ gửi kiểm tra hash cookie đối với mục nhập cơ sở dữ liệu.

Nếu không có mã băm nào khác nhau, hãy từ chối nội dung gửi.

Sau khi gửi thành công, bạn có thể xóa mục nhập băm, thay đổi trạng thái của nó để gửi - bất kỳ điều gì phù hợp với bạn.

Phương pháp đó nên bảo vệ bạn trong nhiều trường hợp, nhưng chắc chắn vẫn không thể chống đạn 100%.

Thực hiện tìm kiếm các bài viết về CSRF, có thể bạn sẽ tìm thấy một số câu trả lời hay về điều này Stack Overflow. ;)

Không thực hiện bất kỳ kiểm tra liên kết giới thiệu hoặc xác thực IP khách hàng nào - thông tin giới thiệu có thể bị xóa bởi tác nhân người dùng, proxy hoặc tùy chọn của người dùng) và IP của khách hàng có thể thay đổi giữa biểu mẫu tạo và gửi - không trừng phạt người dùng để phân bổ địa chỉ IP động.

+0

Trong ứng dụng-động cơ, không phải điều này đòi hỏi một kho dữ liệu viết mỗi khi tôi hiển thị các tùy chọn để xóa? Tôi rất lo lắng về việc này, vì có một tùy chọn xóa trên mọi trang mà người dùng sẽ truy cập. –

+1

Có, nó có thể tạo ra một ghi trên mỗi hiển thị trang, nhưng nó không thực sự phải. Nếu quá trình chuyển đổi băm diễn ra rất thường xuyên, bạn có thể lưu trữ chúng trong memcache, trừ khi trang web của bạn có tải trọng rất lớn. Tùy chọn khác là tạo băm chỉ khi người dùng thực sự nhấn nút "xóa", không đồng bộ. Tuy nhiên, điều này phải được suy nghĩ cẩn thận vì các vấn đề bảo mật mới có thể phát sinh. – macbirdie

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