it-swarm-vi.com

Các nhà phát triển ứng dụng web nên bảo vệ chống lại việc chiếm quyền điều khiển JSON như thế nào?

Cách phòng thủ tốt nhất chống lại chiếm quyền điều khiển JSON là gì?

Bất cứ ai cũng có thể liệt kê các phòng thủ tiêu chuẩn, và giải thích điểm mạnh và điểm yếu của họ? Dưới đây là một số biện pháp phòng vệ mà tôi thấy được đề xuất:

  1. Nếu phản hồi JSON chứa bất kỳ dữ liệu bí mật/không công khai nào, chỉ phục vụ phản hồi nếu yêu cầu được xác thực (ví dụ: đi kèm với cookie cho biết phiên xác thực).
  2. Nếu dữ liệu JSON chứa bất cứ điều gì bí mật hoặc không công khai, hãy lưu trữ dữ liệu đó tại một URL không thể truy cập bí mật (ví dụ: URL chứa số ngẫu nhiên chất lượng mật mã 128 bit) và chỉ chia sẻ URL bí mật này với người dùng/khách hàng được ủy quyền để xem dữ liệu.
  3. Đặt while(1); khi bắt đầu phản hồi JSON và yêu cầu khách hàng loại bỏ nó trước khi phân tích cú pháp JSON.
  4. Yêu cầu khách hàng gửi các yêu cầu cho dữ liệu JSON dưới dạng POST (không phải là GET) và để máy chủ bỏ qua các yêu cầu GET cho dữ liệu JSON.

Tất cả có an toàn không? Có bất kỳ lý do để chọn một trong những điều này hơn những người khác? Có bất kỳ phòng thủ khác tôi đang thiếu?

42
D.W.

Cách phòng thủ đầu tiên là bám sát đặc tả bằng cách sử dụng JSON hợp lệ yêu cầu một đối tượng là thực thể cấp cao nhất . Tất cả các cuộc tấn công đã biết đều dựa trên thực tế là nếu đối tượng cấp cao nhất là một mảng, phản hồi là hợp lệ Java Mã tập lệnh có thể được phân tích cú pháp bằng thẻ <script>.

Nếu phản hồi JSON chứa bất kỳ dữ liệu bí mật/không công khai nào, chỉ phục vụ phản hồi nếu yêu cầu được xác thực (ví dụ: đi kèm với cookie cho biết phiên xác thực).

Đó là điều kiện tiên quyết cho cuộc tấn công , không phải là giảm nhẹ. Nếu trình duyệt có cookie cho trang A, nó sẽ bao gồm nó trong tất cả các yêu cầu đến trang A. Điều này đúng ngay cả khi yêu cầu được kích hoạt bởi thẻ <script> trên trang B.

Nếu dữ liệu JSON chứa bất cứ điều gì bí mật hoặc không công khai, hãy lưu trữ dữ liệu đó tại một URL không thể truy cập bí mật (ví dụ: URL chứa số ngẫu nhiên chất lượng mật mã 128 bit) và chỉ chia sẻ URL bí mật này với người dùng/khách hàng được ủy quyền để xem dữ liệu.

URL không được coi là một tính năng bảo mật . Tất cả các công cụ tìm kiếm phổ biến đều có addons/thanh công cụ trình duyệt báo cáo mọi URL đã truy cập trở lại nhà cung cấp công cụ tìm kiếm. Mặc dù họ chỉ có thể báo cáo các URL được truy cập rõ ràng, nhưng tôi cũng không mạo hiểm điều này đối với URL JSONS.

Yêu cầu khách hàng gửi các yêu cầu cho dữ liệu JSON dưới dạng POST (không phải là GET) và để máy chủ bỏ qua các yêu cầu GET cho dữ liệu JSON.

Điều này sẽ ngăn <script> bao gồm.

Đặt trong khi (1); khi bắt đầu phản hồi JSON và yêu cầu khách hàng loại bỏ nó trước khi phân tích cú pháp JSON.

Tôi đề xuất một phiên bản sửa đổi của phương pháp này: Thêm </* Ở đầu . while(1) có vấn đề vì hai lý do: Đầu tiên, nó có khả năng kích hoạt trình quét phần mềm độc hại (trên máy khách, proxy và công cụ tìm kiếm). Thứ hai, nó có thể được sử dụng cho các cuộc tấn công DoS chống lại CPU của người lướt web. Những cuộc tấn công rõ ràng bắt nguồn từ máy chủ của bạn.

28
Hendrik Brummermann

Google sử dụng " cruft không thể nhìn thấy " để tự vệ trước loại tấn công này. Lỗ hổng này là đã sửa trong firefox . Lỗ hổng phát sinh từ cách các trình duyệt triển khai đặc tả JSON.

3
rook

1) Nếu phản hồi JSON chứa bất kỳ dữ liệu bí mật/không công khai nào, chỉ phục vụ phản hồi nếu yêu cầu được xác thực (ví dụ: đi kèm với cookie cho biết phiên xác thực). 2) Nếu dữ liệu JSON chứa bất kỳ điều gì bí mật hoặc không công khai, hãy lưu trữ dữ liệu đó tại một URL không thể truy cập bí mật (ví dụ: URL chứa số ngẫu nhiên chất lượng mật mã 128 bit) và chỉ chia sẻ URL bí mật này với người dùng/khách hàng được ủy quyền xem dữ liệu.

Không có lý do chính đáng để làm cả (1) và (2).

Đầu tiên là ABAC và thứ hai là ZBAC. Cố gắng để có được phòng thủ chuyên sâu bằng cách sử dụng nhiều sơ đồ kiểm soát truy cập chỉ là những điều quá phức tạp.

3) Đặt while(1); khi bắt đầu phản hồi JSON và yêu cầu khách hàng loại bỏ nó trước khi phân tích cú pháp JSON.

4) Yêu cầu khách hàng gửi yêu cầu dữ liệu JSON dưới dạng POST (không phải là GET) và để máy chủ bỏ qua các yêu cầu GET cho dữ liệu JSON.

Những âm thanh này giống như ý tưởng hay và thêm phần bảo vệ theo chiều sâu vì nó giúp đảm bảo rằng thông tin đăng nhập không thể bị chiếm dụng.

Ngoài ra,

5) Chỉ phục vụ JSON với dữ liệu nhạy cảm qua SSL hoặc một số kênh bảo mật khác.

để ngăn chặn dữ liệu rò rỉ qua MITM.

2
Mike Samuel