2012-03-07 33 views
12

Có lỗ hổng bảo mật nào đã biết với trình gỡ lỗi JSON của Django không? Về các giao thức deserializing Python, sự đồng thuận chung dường như là chúng hoàn toàn không an toàn, do đó, tránh phân tích cú pháp dữ liệu không đáng tin cậy.Bảo mật De-serialization Django JSON

Tuy nhiên, tôi đang xem xét một ứng dụng web phân tán nơi các máy chủ khác nhau trao đổi các bản ghi mô hình, được định dạng dưới dạng JSON. Bản thân các bản ghi không chứa dữ liệu nhạy cảm, nhưng tôi lo ngại về khả năng máy chủ bị tấn công vi phạm một máy chủ khác bằng cách gửi JSON có định dạng độc hại. Điều này có thể không?

Tôi thường thấy bộ nối tiếp JSON của Django trong môi trường công khai, vì vậy tôi hy vọng nó sẽ được chống lại loại điều này, nhưng tôi không thể tìm thấy bất kỳ tài liệu nào giải quyết bất kỳ vấn đề bảo mật nào.

+0

Bạn có bật tính năng bảo vệ CSRF không? Điều đó sẽ đi một chặng đường dài hướng tới đảm bảo an ninh. –

+0

"json được định dạng độc hại" là gì? – Marcin

+1

@Marcin, JSON được định dạng để khai thác một số lỗ hổng trong trình phân tích cú pháp, cho phép thực hiện các hướng dẫn tùy ý trên máy chủ. – Cerin

Trả lời

3

Tôi đang gặp khó khăn trong việc tìm ra suy nghĩ của bạn có thể không an toàn (hoặc bảo mật) về JSON.

JSON là định dạng trao đổi dữ liệu dựa trên văn bản. Nó không có bất kỳ bảo mật tích hợp. Django đi kèm với một số chức năng để tuần tự hóa và deserialize querysets để JSON. Nhưng chúng không thể "độc hại" hoặc "không an toàn" - chúng chỉ là dữ liệu.

Một số giao thức tuần tự hóa, ví dụ như tẩy, có thể không an toàn vì chúng có thể chứa mã, vì vậy có thể được deserialized để chạy một cái gì đó gây hại cho hệ thống của bạn. Các mô hình được tuần tự hóa không có vấn đề đó, bởi vì chúng không chứa mã. Tất nhiên, nếu bạn đang sử dụng JSON để (ví dụ) chuyển danh sách các ID mô hình bị xóa, thì có khả năng người dùng độc hại bao gồm toàn bộ các ID mà bạn không muốn xóa. Nhưng một lần nữa đây không phải là lỗi của JSON - điều đó tùy thuộc vào bạn để đảm bảo rằng logic nghiệp vụ của bạn xác định chính xác yếu tố nào người dùng được phép xóa hoặc sửa đổi.

+8

Nhưng nếu bộ giải mã bị thiếu sót thì [thậm chí] (http://www.securityfocus.com/bid/17365) [dữ liệu] (http://technet.microsoft.com/en-us/security/bulletin/ms04- 028) [có thể] (http://technet.microsoft.com/en-us/security/bulletin/ms04-025) [độc hại] (http://www.securityfocus.com/bid/51292). –

+0

@Ignacio, Chính xác. Rất nhiều ứng dụng chỉ đọc dữ liệu (ví dụ: người xem hình ảnh, trình phát nhạc, v.v.) đôi khi có loại lỗ hổng này. Tôi không muốn tự động giả định Django được miễn. – Cerin

3

Theo mặc định khi sử dụng simplejson, là trình gỡ rối mặc định được Django sử dụng, các loại đối tượng có thể được chuyển đổi từ JSON thành đối tượng Python bị giới hạn. Cách duy nhất này không phải là trường hợp, là nếu bạn đang làm một số loại giải mã chuyên ngành sử dụng các đối số tùy chọn cho các phương pháp loads() hoặc load() hoặc đối tượng JSONDecoder của riêng bạn.

Vì vậy, miễn là bạn đang sử dụng giải mã mặc định, bạn khá an toàn. Nhưng, nếu bạn thực sự quan tâm, bạn nên xác thực dữ liệu JSON đã nạp TRƯỚC KHI bạn thực sự làm bất cứ điều gì với nó.

+0

OK, đây là một lời khuyên rất hay, quá chung chung: "xác thực JSON đã tải" - tôi phải xác thực nó bằng cách nào? Cụm từ thông dụng? Kiểm tra xem kích thước nhỏ hơn X? Pickle không an toàn bởi thiết kế, bởi vì nó có thể gọi các hàm tạo của các đối tượng tùy ý và JSON khá thụ động. Tuy nhiên, lịch sử biết các trường hợp như thế này: http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/ (điều này thực sự là do sử dụng một trình phân tích cú pháp quá chung chung: không phải là JSON cụ thể). Chúng ta không thể yên tâm hoàn toàn nếu không có một phân tích cú pháp rất nặng như vậy. –