Được bảo mật hơn và tại sao JSON hoặc XML

Question

Tôi muốn triển khai các dịch vụ web trong Java EE có phản hồi sẽ là JSON. Đây là nỗ lực đầu tiên của tôi để làm như vậy nhưng trước đó tôi chỉ muốn biết là có bất kỳ vấn đề an ninh với JSON bởi vì ở khắp mọi nơi trong nhiều blog tôi đọc nó được đề cập Giống như "JSON không được bảo đảm so với XML". JSON có một số ưu điểm như dễ sử dụng, tốc độ nhanh hơn.

Vì vậy, bất kỳ ai cũng có thể giải thích cho tôi sự thật liệu JSON có thực sự không an toàn hay không. Nếu vậy thì tại sao. Hãy giải thích với một ví dụ.

Có bài viết cũ vài về chủ đề này:

JSON vs XML - 2006

• lo ngại về eval

JSON is not as safe as people think it is

• bố chỉ bảo vệ cho dữ liệu ngoài công lập có sẵn vi JSON là sử dụng các url duy nhất.
• CSRF (Cross Site Request Fogery) - 2007
• Array hack phân tích cú pháp JavaScript cao theo trình duyệt.

Answer 1

Điều này là vô nghĩa. Cả hai, json và xml chỉ là các phương thức để trình bày dữ liệu có cấu trúc. Không ai trong số họ có thể được coi là "bảo đảm hơn" hoặc "ít được bảo đảm".

Answer 2

Không có phiên bản bảo mật nào khác. Có những tính năng khác để xem xét mặc dù:

Example 1

Example 2

Nó không quan trọng cho dù bạn làm việc với java, php hoặc perl. Tất cả đều có thể phân tích cú pháp json và xml. json có trọng lượng nhẹ, mặc dù xml có thể xử lý nhiều hơn. Tôi sẽ nói, bắt đầu với json trừ khi bạn thực sự cần các tính năng của xml.

Answer 3

Không có sự khác biệt về bảo mật giữa JSON và XML. "Sự bất an" được mọi người liên quan đến JSON phải làm theo cách mà JSON có thể (nhưng không bao giờ nên) được phân tích cú pháp trong Javascript.

JSON dựa trên cú pháp để mã hóa các đối tượng trong javascript, do đó việc đánh giá kết quả JSON trong javascript trả về một đối tượng hợp lệ.

Điều này có thể mở JSON cho nhiều lần khai thác javascript.

Cách để giải quyết vấn đề này: không sử dụng eval() để phân tích cú pháp JSON trong javascript, sử dụng trình phân tích cú pháp JSON và sửa bất kỳ vấn đề bảo mật nào trong máy chủ của bạn cho phép nội dung do người dùng tạo không thoát.

Answer 4

Cả hai định dạng đều đại diện cho dữ liệu do đó không có sự khác biệt về bảo mật, tôi đã sử dụng JSON trong nhiều năm và không bao giờ có bất kỳ vấn đề bảo mật nào.

Answer 5

Không có lợi ích bảo mật để đi với một hoặc khác. Cả hai định dạng đều có nghĩa là cung cấp một giao thức đơn giản để gửi dữ liệu và không sử dụng mã hóa theo mặc định (bạn có thể tự thêm một thứ gì đó). JSON thường được coi là nhanh hơn, vì phải mất ít ký tự hơn để lắp ráp. Nó cũng dễ sử dụng trong JavaScript, vì JSON chỉ đơn giản là Ký hiệu đối tượng JavaScript và tất cả các đối tượng JavaScript có thể được chuyển đổi thành hoặc từ biểu diễn JSON.

Nhiều nhà phát triển (đặc biệt là mới hơn) thích sử dụng XML vì tính dễ đọc của nó. Nó được cấu trúc theo cách dễ dàng hơn cho con người đọc qua nó. Điều này tất nhiên là những gì làm cho nó to hơn JSON, nhưng nó không có nghĩa là kém an toàn hơn.

Các lỗ hổng có thể xảy ra do các giao thức chuyển giao này là kết quả của việc phân tích cú pháp xấu. Các trình phân tích cú pháp cho các dịch vụ trên một mạng mở không thể chỉ đơn giản giả định rằng dữ liệu là hợp lệ, vì điều đó có thể dẫn đến các cuộc tấn công như tiêm mã - nhưng điều đó không liên quan gì đến JSON hoặc XML.

Answer 6

Bài đăng này thực hiện tốt công việc so sánh các vấn đề bảo mật được tìm thấy trong hai định dạng chia sẻ dữ liệu. Nó thậm chí còn có đoạn mã với các giải thích về cách các cuộc tấn công có thể được rút ra trên các lỗ hổng phổ biến như xác thực XXE và DTD. Sau đó, nó cho thấy làm thế nào để remediate/harden chống lại các vấn đề bảo mật để cả XML và JSON có thể được sử dụng một cách an toàn.

https://blog.securityevaluators.com/xml-vs-json-security-risks-22e5320cf529

Về mặt an ninh, phân tích cú pháp XML trong cấu hình mặc định của họ là mở cửa cho các cuộc tấn công tiêm XXE và tấn công xác nhận DTD, vì vậy sự trao đổi dữ liệu XML cần phải được cứng nếu được sử dụng.

JSON, mặt khác, là trong bản thân an toàn trong trạng thái mặc định của nó, nhưng càng sớm càng JSONP được sử dụng để vượt qua chính sách Same-Origin hạn chế (tấn công CSRF), nó trở nên dễ bị tổn thương vì:

nó cho phép trao đổi dữ liệu gốc.

Tác giả tóm tắt sự so sánh ở đây:

Về vấn đề đối với an ninh, xử lý tin cậy yêu cầu Internet phải đối mặt là một trong những chức năng cơ bản nhất của một XML hoặc JSON phân tích cú pháp. Thật không may, các trình phân tích cú pháp XML phổ biến không phù hợp với mục đích này trong cấu hình mặc định của chúng; chỉ với cứng để vô hiệu hóa mở rộng thực thể bên ngoài và xác nhận DTD bên ngoài là chúng an toàn. Ngược lại, phân tích cú pháp JSON hầu như luôn an toàn, miễn là lập trình viên sử dụng các kỹ thuật hiện đại hơn là JSONP. Miễn là các nhà phát triển web nhận thức được những rủi ro bảo mật và thực hiện các bước để bảo vệ chống lại họ, hoặc là tùy chọn hoàn toàn khả thi trong môi trường web hiện tại.

Answer 7

Cả JSON và XML đều là phương tiện cho giao tiếp ứng dụng khách của máy chủ. Vì vậy, tại sao mối quan tâm an ninh với một và không khác?

Sự khác biệt cơ bản là JSON (JavaScript Object Notation) như tên cho thấy rất gần và thân thiện với JavaScript và do đó thiết kế một số phương thức và chức năng JavaScript, JavaScript xử lý chuỗi JSON như là tách trà và cố gắng diễn giải nó trực tiếp, cung cấp giải pháp cho kẻ tấn công để đánh lừa trình thông dịch JavaScript để chạy JavaScript độc hại được nhúng trong chuỗi gây ra lỗ hổng, trong khi XML phải trải qua giai đoạn phân tích cú pháp để phân tích cú pháp thành đối tượng. 2 chức năng JavaScript như vậy là phương thức và thẻ eval().

Làm cách nào để tạo lỗ hổng bảo mật?

Mặc dù web theo chính sách cùng nguồn gốc, lịch sử đã có những sơ hở tìm thấy để vượt qua nó và các trang web độc hại sử dụng chúng để gửi yêu cầu qua trang web vào trang web người dùng xác thực, phá vỡ mục đích của chính sách cùng nguồn gốc.

Ví dụ: Mặc dù có chính sách cùng nguồn gốc, web đã cho phép một số thẻ như <img> <script> thực hiện yêu cầu GET gốc.

chúng ta hãy nói rằng bạn đang ở trên một trang web www.authenticatedwebsite.com, nhưng thu hút để mở một www.malicious.com trong đó có một thẻ trong html của nó <script src="www.authenticatedwebsite.com/get-user-order-history" />

Attacker từ www.malicious.com sử dụng kịch bản này thẻ hành vi để truy cập dữ liệu cá nhân của bạn từ www.authenticatedwebsite.com.

Bây giờ, làm cách nào để một thẻ tập lệnh gọi url src, lưu trữ đáp ứng url cho đối tượng javascript [để thực hiện các thao tác như POST vào máy chủ trang web độc hại]?

Dưới đây là vai trò của JSON và XML chứng minh là an toàn hơn ở đây. Vì JavaScript hiểu JSON khá tốt, một số trình thông dịch JavaScript diễn giải chuỗi JSON thô như một JavaScript hợp lệ và chạy nó.

Điều gì có thể chạy chuỗi JSON có khả năng làm, vì nó vẫn không được gán cho một biến?

Điều này có thể đạt được bằng một bản hack lạ mắt khác. Nếu chuỗi JSON được trả về đại diện cho một mảng. JavaScript sẽ cố gắng chạy hàm tạo của lớp Array. Bây giờ có thể ghi đè lên hàm tạo của mảng trong JavaScript. Bạn có thể làm một cái gì đó như:

Array = function(){ yourObject = this }; 

này về cơ bản là trọng Javascript mảng xây dựng, chẳng hạn bất cứ khi nào gọi JavaScript constructor, mảng giải thích hiện nay được gán cho yourObject, do đó đem lại độc hại truy cập trang web để dữ liệu cá nhân của bạn.

Bây giờ, cuộc tấn công này có thể được sử dụng với các biến thể của chuỗi JSON, với các lỗ hổng phức tạp hơn.

Mặc dù ở trên đại diện cho một tình huống hợp lệ, trong đó JSON có thể nguy hiểm như một định dạng trả về của các API GET của bạn. Điều này thực sự có thể chỉ trong một số phiên bản của một số trình duyệt, và như tôi biết, tất cả các phiên bản hiện đại của các trình duyệt nổi tiếng đã giảm thiểu nó, nhưng khi cơ sở người dùng của bạn có thể được chia trên các phiên bản của trình duyệt, bạn cần phải cẩn thận với GET API đưa ra thông tin riêng tư theo định dạng JSON khỏa thân.

Một trong những kỹ thuật được sử dụng để vượt qua điều này là thêm một thời gian (đúng) trước chuỗi trả lời JSON của bạn, sẽ không bao giờ cho phép trình thông dịch JavaScript tiếp cận chuỗi thực tế. Nhưng nó tạo ra phân tích chi phí trên phía khách hàng của bạn.

Một rủi ro có thể khác mà JSON có thể gây ra là sử dụng phương thức eval() trên phía máy khách trình duyệt để phân tích cú pháp JSON. Vì eval() có khả năng chạy tập lệnh, nếu chuỗi JSON của bạn chứa một số tập lệnh ẩn mà eval() chạy và thực hiện các hành động nguy hiểm mà tập lệnh tấn công được yêu cầu, có thể chứng minh là vấn đề bảo mật cho hệ thống của bạn.Nhưng như những người khác đã đề cập, cuộc tấn công này có thể dễ dàng ngăn chặn bằng cách bỏ hoàn toàn phương thức eval() làm trình phân tích cú pháp JSON của bạn ở mọi nơi trong mã máy khách. Lỗ hổng dễ bị tổn thương này rất quan trọng đối với các trang web lưu trữ nội dung do người dùng tạo.