Các ngôn ngữ lập trình hỗ trợ JSON

Mỗi ngôn ngữ lập trình chính có thể kết hợp JSON, có thể thông qua thư viện hoặc hỗ trợ gốc. Tuy nhiên, không có ngôn ngữ nào có thể vượt qua JavaScript để phân tích định dạng trao đổi dữ liệu này.
dịch nó trực tiếp thành một đối tượng bằng chữ JSON cũng phổ biến như XML. Do đó, mỗi ngôn ngữ chính đều có một hoặc nhiều thư viện mạnh mẽ được sử dụng phổ biến để định dạng và phân tích dữ liệu ở định dạng JSON. Thông thường, chỉ cần có hai chức năng cốt lõi sau:

Phân tích cú pháp (parse): Chuyển đổi dữ liệu JSON thành cấu trúc dữ liệu được hỗ trợ của ngôn ngữ tương ứng, chẳng hạn như mảng, hàm băm hoặc từ điển.
Định dạng (format): Chuyển đổi mảng, hàm băm hoặc từ điển thành văn bản JSON

Các nhà phát triển có thể dễ dàng tìm thấy các chức năng này cho hầu hết mọi ngôn ngữ hiện đại. Chẳng hạn, Ruby kết hợp JSON gem, Objective-C hỗ trợ JSONKit và Microsoft .NET Framework có Json.NET.
Hầu hết các thư viện này đều nhanh và hiệu quả, xét đến việc chúng được sử dụng rộng rãi và thường xuyên tối ưu hóa theo thời gian.

Khi so sánh các ngôn ngữ khác nhau, một số nhà phát triển có thể chỉ ra rằng việc sử dụng JSON trong ngôn ngữ C# hoặc Java là không thực tế. Điều này là do các thành ngữ hỗ trợ các lớp xác định chứ không phải các đối tượng thuộc kiểu Dictionary hoặc HashMap. Do đó, để tạo dữ liệu JSON, nhà phát triển bắt buộc phải sử dụng thư viện cùng với mã tùy chỉnh để chuyển đổi các cấu trúc dữ liệu này thành phiên bản dữ liệu tương ứng. Do đó, có một số thư viện được tạo ra cho mục đích này. Chẳng hạn, thư viện Gson của Google được thiết kế để chuyển đổi trực tiếp dữ liệu JSON sang các đối tượng Java.

Gson

Gson là một thư viện Java mã nguồn mở để chuyển đổi một đối tượng trong Java sang dữ liệu JSON và ngược lại. Với mục đích này, nó cung cấp các phương tiện dễ dàng như hàm khởi tạo và toString(). Thư viện này cũng hoạt động tốt với các đối tượng Java tùy ý, bao gồm cả những đối tượng có sẵn mà mã nguồn của bạn không có sẵn. Sau đây là các mục tiêu của Gson:

• Chuyển đổi các đối tượng không thể sửa đổi hiện có sang và từ JSON
• Cho phép biểu diễn tùy chỉnh cho các đối tượng
• Xuất dữ liệu JSON nhỏ gọn và dễ đọc

Gson có khả năng giải tuần tự hóa các chuỗi có dung lượng hơn 25 MB, giải tuần tự hóa 87.000 đối tượng và tuần tự hóa 1,4 triệu đối tượng mà không gặp vấn đề gì. Phiên bản 1.4 của nó đã tăng khả năng khử tuần tự hóa từ 80 KB lên hơn 11 MB, áp dụng cho array và collection bytes.

Thật thuận tiện để học và sử dụng Gson. Nhà phát triển chỉ cần biết hai phương thức là toJson() và fromJson(). Phương thức toJson() được sử dụng để chuyển đổi một đối tượng Java thành dữ liệu JSON trong khi đó, fromJson() để chuyển đổi dữ liệu JSON thành một đối tượng trong Java.

Json trong PHP

PHP cũng cho phép mã hóa và giải mã cấu trúc dữ liệu JSON. Từ phiên bản 5.2.0 trở đi của PHP, theo mặc định, tiện ích mở rộng cho JSON được đóng gói thành PHP.

Xem thêm bài viết https://hocvietcode.com/lam-viec-voi-json-trong-php/ để tìm hiểu.

MIME type của JSON

Còn được gọi là loại phương tiện hoặc loại nội dung, MIME type đề cập đến mã định danh gồm hai phần bao gồm một loại được phân tách khỏi loại phụ sau bằng dấu gạch chéo. Nó giúp xác định loại nội dung được định dạng hoặc định dạng của tệp được gửi qua Web. Theo đó, trình duyệt sau đó sẽ dễ dàng xử lý dữ liệu. Đối với văn bản JSON, MIME type chính thức là ‘application/json’, biểu thị rằng loại phụ ‘json’ thuộc về loại ‘ứng dụng’. Trong khi phần lớn các ứng dụng hiện đại đã chấp nhận MIME type này, một số ứng dụng khác vẫn mở rộng hỗ trợ kế thừa cho các loại khác.

Một số thư viện, trình duyệt, ứng dụng Web và máy chủ hỗ trợ loại MIME ‘text/json’ hoặc ‘text/Javascript’ (không chính thức). Các ví dụ nổi bật bao gồm API Facebook, Yahoo! và API tìm kiếm của Google.

Ứng dụng của JSON

Có một số ứng dụng hữu ích của JSON, chẳng hạn như trong API, cơ sở dữ liệu NoSQL, phát triển Web và gói ứng dụng.

API

JSON thường được sử dụng để trao đổi dữ liệu đến và đi từ các API. Các ứng dụng web, đặc biệt là các trang mạng xã hội phổ biến, có API để thu thập lượng dữ liệu khổng lồ mà các nhà phát triển thiết kế các ứng dụng phái sinh sử dụng. Các ứng dụng xã hội, chẳng hạn như LinkedIn, Facebook, Flickr và Twitter triển khai API sử dụng JSON để gửi dữ liệu cho nhà phát triển. Một số API này hỗ trợ XML cũng như JSON, trong khi số còn lại chỉ sử dụng JSON.

NoSQL

Định dạng JSON cũng được sử dụng trong cơ sở dữ liệu NoSQL, chẳng hạn như CouchDb và MongoDb, để lưu trữ dữ liệu. Khá dễ dàng để sử dụng JSON để lưu trữ dữ liệu vào các cơ sở dữ liệu này. Điều này là do có thể chuyển đổi cấu trúc JSON thành cấu trúc dữ liệu đối tượng của JavaScript trong môi trường trình duyệt. Ngoài ra, có thể tích hợp cấu trúc với JavaScript phía máy chủ.

JavaScript và JSON bất đồng bộ (AJAJ)

AJAJ Tương tự như AJAX nhưng sử dụng JSON thay vì XML. Phương pháp phát triển Web động này cho phép một trang Web được tải yêu cầu dữ liệu mới. Thông thường, dữ liệu mới được gửi từ máy chủ dưới dạng phản hồi cho hành động của người dùng trên trang đó. Ví dụ: khi người dùng bắt đầu nhập các ký tự vào hộp tìm kiếm, nó sẽ được gửi đến máy chủ thông qua mã phía máy khách. Sau đó, máy chủ phản hồi ngay lập tức bằng cách đưa ra danh sách các mục phù hợp từ cơ sở dữ liệu mà trình duyệt hiển thị trong danh sách thả xuống (drop-down list)

JSON-RPC

JSON-RPC là một giao thức nhẹ và đơn giản dành cho Cuộc gọi thủ tục từ xa (RPC). Nó được phát triển trên JSON để thay thế Giao thức truy cập đối tượng đơn giản (SOAP) hoặc XML-RPC. Giao thức chỉ xác định một số lệnh cùng với một số loại dữ liệu để cho phép hệ thống gửi nhiều cuộc gọi và thông báo đến máy chủ. Mặc dù thông báo không chờ phản hồi nhưng các cuộc gọi sẽ được phản hồi mà không cần bất kỳ mệnh lệnh nào.

Quản lý gói (Package Management)

Do sự phức tạp ngày càng tăng trong quá trình phát triển Web, các nhà phát triển đã bắt đầu sử dụng các công cụ để xây dựng các gói ứng dụng của họ. Các gói này giúp triển khai các ứng dụng tương ứng dễ dàng hơn. Chúng cũng giúp việc sửa đổi và tích hợp mọi thay đổi sau này trở nên dễ dàng hơn. Bằng cách này, không chỉ việc phát triển mà cả việc bảo trì cũng trở nên dễ dàng hơn thông qua các gói.

Hiện tại, một số công cụ quản lý gói được cung cấp, chẳng hạn như Trình quản lý gói Node (NPM), Yomen và Bower. Hầu hết các công cụ này triển khai tệp pack.json chứa siêu dữ liệu như phiên bản, tên, mô tả, chi tiết giấy phép, phần phụ thuộc và cấu trúc tệp.

Giao thức truyền siêu văn bản JSON (HTTP) và tệp

Xem bài viết https://hocvietcode.com/ky-thuat-ajax-trong-php/ để hểu rõ hơn cách giao tiếp và làm việc với JSON thông qua HTTP.

Sử dụng JSON để lưu trữ dữ liệu

Ban đầu được giới thiệu là ký hiệu đối tượng được tuần tự hóa cho các ứng dụng Web, JSON hiện đang được sử dụng ngoài Web. Ví dụ: nó được sử dụng để lưu trữ dữ liệu được lấy từ các dịch vụ và ứng dụng. Điều này có lẽ là do tính đơn giản và cấu trúc linh hoạt của nó.

Sự thống trị lâu dài của RDBMS và Ngôn ngữ truy vấn có cấu trúc (SQL) đã kết thúc với sự ra đời của một số cơ sở dữ liệu NoSQL, đặc biệt phục vụ các nhà phát triển thích JSON. Với việc triển khai JSON ngày càng tăng, các nhà cung cấp cơ sở dữ liệu cũng đã bắt đầu cung cấp cơ sở dữ liệu tài liệu lấy JSON làm trung tâm. Theo xu hướng hiện nay, ngày càng có nhiều RDBMS truyền thống kết hợp các tính năng JSON, mang lại lợi ích không chỉ cho nhà phát triển mà còn cho cả quản trị viên cơ sở dữ liệu. Những lợi ích này bao gồm tính linh hoạt và thân thiện với nhà phát triển.

Thân thiện với nhà phát triển

Rõ ràng là các nhà phát triển cần xử lý mã cũng như dữ liệu. Trong khi mã đóng vai trò là động từ để mô tả hoặc hướng dẫn cách thực hiện một tác vụ thì dữ liệu đóng vai trò là danh từ để xác định các thực thể như người dùng cùng với thông tin chi tiết của họ.
Khi ngày càng nhiều nhà phát triển ưa chuộng JSON làm định dạng dữ liệu chính, việc có cơ sở dữ liệu thân thiện với JSON là điều không thể tránh khỏi. Do đó, nhiều nhà cung cấp cơ sở dữ liệu NoSQL đang chọn JSON thay vì các lược đồ quan hệ thông thường trong Oracle, MS SQL Server, VoltDB, MySQL và PostgreSQL. Điều này phù hợp hơn với các nhà phát triển ưa thích định dạng JSON cho ứng dụng của họ.

Tính nhanh gọn

Bản ghi JSON không chỉ có cấu trúc rõ ràng mà còn có thể mở rộng dễ dàng, giúp định dạng trở nên linh hoạt. Điều này tạo nên sự hấp dẫn đáng kể đối với các nhà phát triển, những người không muốn gặp rắc rối khi di chuyển lược đồ cơ sở dữ liệu trong môi trường động. Về mặt khối lượng, có thể khó thay đổi cả dữ liệu và lược đồ. Hơn nữa, việc ghi lại một bản ghi lớn được lưu trữ trên đĩa trong khi duy trì các ứng dụng được liên kết có lẽ là một công việc tốn thời gian đòi hỏi vài ngày xử lý nền. Ngược lại, việc không có lược đồ được xác định trước trong JSON cho phép nâng cấp dễ dàng hơn. Các nhà phát triển có thể lưu và cập nhật tài liệu mà không có bất kỳ giới hạn nào.

Tài liệu và Cơ sở dữ liệu quan hệ

Thực tế là việc loại bỏ các hạn chế và cho phép dữ liệu tùy ý trong cơ sở dữ liệu có thể gây ra những hạn chế riêng. Việc từ bỏ mô hình cơ sở dữ liệu quan hệ có những hạn chế riêng đối với các nhà phát triển, doanh nghiệp và kiến trúc sư doanh nghiệp. Trên thực tế, cơ sở dữ liệu quan hệ được ra đời để thay thế các hệ thống có cấu trúc tương tự như tệp JSON. Nói tóm lại, cơ sở dữ liệu hướng tài liệu có một số sai sót cố hữu như sau:

• Cần điều hướng tài liệu trong khi truy vấn, dẫn đến sự liên kết chặt chẽ hơn giữa ứng dụng và cơ sở dữ liệu
• Giới thiệu ngôn ngữ truy vấn mới cho mỗi kho tài liệu, làm suy yếu một cách không cần thiết
• tiêu chuẩn hóa, không giống như lõi truy vấn SQL được xác định rõ ràng, đảm bảo tính di động trên các hệ thống cơ sở dữ liệu
• Loại bỏ sự trừu tượng quan trọng giữa cấu trúc dữ liệu logic và bộ lưu trữ vật lý của nó, điều này hạn chế việc tối ưu hóa; không giống như một hệ thống quan hệ làm cho việc định nghĩa dữ liệu được lưu trữ trở nên dễ truy vấn hơn thông qua sự trừu tượng hóa như vậy
• Không hỗ trợ các ràng buộc thực thi tính nhất quán và chuẩn hóa để chỉ lưu trữ thông tin dư thừa một lần, điều này đặt gánh nặng đảm bảo điều tương tự lên nhà phát triển

Tuy nhiên, các nhà cung cấp cơ sở dữ liệu đang chấp nhận tiện ích và mức độ phổ biến ngày càng tăng của JSON cùng với sự tích hợp của nó với các hệ thống quan hệ thông thường của họ. Trong các hệ thống này, việc kết hợp cơ chế lưu trữ và truy vấn các bản ghi JSON mang lại lợi thế là sự lựa chọn mạnh mẽ cho các nhà phát triển. Họ có thể dễ dàng quyết định các phần dữ liệu sẽ được trừu tượng hóa, các lĩnh vực mà tính linh hoạt quan trọng hơn việc kiểm tra tính nhất quán và các vị trí cần có lược đồ và ràng buộc nghiêm ngặt. Điều này là do việc tích hợp JSON trong cơ sở dữ liệu quan hệ thông thường mang lại lợi ích tốt nhất cho cả hai thế giới.

Hơn nữa, việc tích hợp như vậy cho phép truy vấn JSON trở thành một phần mở rộng SQL gốc, cho phép thực hiện các truy vấn mạnh mẽ trên các bộ sưu tập bản ghi JSON ngẫu nhiên được hợp nhất với dữ liệu trong các ô bảng thông thường. Trong thực tế, các nhà cung cấp RDBMS sẽ dễ dàng hơn nhiều trong việc mở rộng hệ thống của họ để kết hợp JSON so với các nhà cung cấp kho lưu trữ tài liệu mới. Các nhà cung cấp CSDL tài liệu, bằng cách kết hợp JSON, sẵn sàng khôi phục các tính năng đã bị mất khi họ chuyển đổi từ các cấu trúc quan hệ mạnh mẽ nhưng JSON lại có nhu cầu rất lớn về cơ sở dữ liệu quan hệ mạnh mẽ như vậy. Điều này là do đây là một định dạng nhỏ không chỉ ảnh hưởng đến các mô hình lập trình dựa trên Web mà còn ảnh hưởng đến các tầng quản lý dữ liệu. JSON đã giới thiệu các nhà cung cấp mới phục vụ sự lựa chọn của các nhà phát triển hiện đại. Cuối cùng, JSON có thể mang lại những tiến bộ mới trong cơ sở dữ liệu quan hệ.

So sánh JSON với Cơ sở dữ liệu quan hệ

Mặc dù ngay cả JSON cũng lưu trữ hoặc biểu thị dữ liệu, nhưng nó khác biệt đáng kể so với mô hình cơ sở dữ liệu quan hệ thông thường được triển khai trong các ứng dụng RDBMS như SQL Server và MySQL. Biết những khác biệt này có thể giúp bạn thích JSON hơn RDBMS hoặc ngược lại, tùy theo cấu trúc và loại dữ liệu. Sau đây là những khác biệt cơ bản:

Cấu trúc: Bảng lưu trữ dữ liệu trong cơ sở dữ liệu quan hệ, trong khi JSON sử dụng mảng và đối tượng để lưu trữ , có thể được lồng đệ quy.

Siêu dữ liệu (metadata): Lược đồ lưu trữ dữ liệu về loại cũng như cấu trúc của dữ liệu được lưu trữ trong cơ sở dữ liệu quan hệ. Hơn nữa, các lược đồ được tạo trong khi tạo cơ sở dữ liệu và bảng chứ không phải tại thời điểm lưu trữ dữ liệu. Ngay cả JSON cũng có thể sử dụng lược đồ nhưng nó không được tạo trước như trong cơ sở dữ liệu quan hệ. Thông thường, cấu trúc JSON có khả năng tự mô tả nhưng nếu sử dụng lược đồ, nó sẽ đảm bảo tính linh hoạt hơn lược đồ trong cơ sở dữ liệu quan hệ.

Truy xuất dữ liệu: Cơ sở dữ liệu quan hệ sử dụng SQL, một ngôn ngữ mạnh mẽ dựa trên đại số quan hệ, để lấy dữ liệu từ các bảng. Mặt khác, JSON không sử dụng bất kỳ ngôn ngữ phổ biến nào như vậy. Trên thực tế, nó sử dụng Ngôn ngữ truy vấn JSON (JAQL) và JSONiq, những ngôn ngữ này vẫn đang phát triển.

Sắp xếp: Trong cơ sở dữ liệu quan hệ, SQL dễ dàng giúp truy xuất dữ liệu và hiển thị dữ liệu theo thứ tự tăng dần hoặc giảm dần. Trong JSON, nhà phát triển có thể sắp xếp mảng.

Đường cong học tập: JSON có đường cong học tập rất suôn sẻ. Điều này là do các kiểu dữ liệu và cấu trúc được hỗ trợ ở đây được sử dụng trong một số ngôn ngữ lập trình. Do đó, một nhà phát triển có nền tảng lập trình cơ bản nắm bắt các khái niệm JSON và mã hóa khá nhanh. Mặt khác, RDBMS là một lĩnh vực riêng biệt để tìm hiểu và khám phá, cần có thời gian để thành thạo. Tuy nhiên, một khi đã thành thạo, nó sẽ có những cơ hội và lợi ích riêng.

Ứng dụng: Thị trường có một số cơ sở dữ liệu quan hệ thương mại cũng như nguồn mở để cung cấp. Ngoài ra còn có cơ sở dữ liệu NoSQL nhưng chúng sử dụng JSON để lưu trữ dữ liệu. JSON thường được triển khai bằng một số ngôn ngữ lập trình.

Các vấn đề về bảo mật và khả năng di chuyển dữ liệu của JSON

JSON là một định dạng tuần tự hóa dữ liệu nhưng nó cũng là một tập hợp con linh hoạt của JavaScript, điều này gây ra một số vấn đề bảo mật. Các vấn đề này tập trung vào trình thông dịch JavaScript thực thi dữ liệu JSON dưới dạng JavaScript được nhúng. Nói một cách đơn giản, khả năng tương thích của JSON được khai thác với hàm eval(). Điều này làm cho ứng dụng dễ bị tấn công bởi các tập lệnh độc hại, đây là mối lo ngại nghiêm trọng khi xử lý dữ liệu thu được từ Web. Tương tự, còn có những vấn đề khác liên quan đến việc triển khai.

Các vấn đề liên quan đến hàm Eval() để thực thi văn bản JSON

Hầu hết văn bản JSON có cú pháp là JavaScript, điều này giúp hàm eval() dễ dàng phân tích cú pháp dữ liệu JSON. Thay vì trình phân tích cú pháp dựa trên JSON, trình thông dịch JavaScript sẽ thực thi dữ liệu JSON để tạo các đối tượng JavaScript tương ứng. Điều này thực sự nguy hiểm, trừ khi dữ liệu được xác thực lần đầu trước khi phân tích cú pháp.
Việc sử dụng phương pháp eval() làm cho dữ liệu chưa được xác thực như vậy dễ gặp phải các vấn đề bảo mật khi môi trường và dữ liệu JavaScript đầy đủ nằm ngoài tầm kiểm soát của một nguồn đáng tin cậy. Ví dụ: nếu dữ liệu không đáng tin cậy, nó có thể bị tấn công bằng cách tiêm mã độc. Những vi phạm như vậy sau đó có thể dẫn đến giả mạo xác thực, đánh cắp dữ liệu và danh tính cũng như lạm dụng tài nguyên. Nói tóm lại, đoạn mã sau là một mối lo ngại lớn về bảo mật.

Vì vậy JSON.parse() được giới thiệu như một giải pháp thay thế đáng tin cậy hơn. Hàm chỉ xử lý văn bản ở định dạng JSON.

Các trình duyệt web đang có ý định bao gồm hoặc đã bao gồm hỗ trợ cho chức năng gốc này để mã hóa và giải mã văn bản JSON. Điều này loại bỏ vi phạm eval() cũng như tăng hiệu suất so với các thư viện được sử dụng trước đây trong JavaScript. Hầu hết các trình duyệt hiện nay đều hỗ trợ phương thức này.

Một thư viện JavaScript nổi tiếng đã cam kết triển khai JSON gốc:

• jQuery
• Dojo Toolkit
• Prototype
• YUI Library
• MooTools

Một vấn đề khác khi sử dụng hàm eval() là cần phải extra escaping (xử lý chuỗi) trong một số trường hợp. Điều này là do một số ký tự Unicode hợp pháp trong chuỗi JSON bị coi là bất hợp pháp trong JavaScript. Bằng cách thực thi dữ liệu JSON dưới dạng mã JavaScript, hàm này sẽ khiến ứng dụng gặp phải một số vi phạm bảo mật như tập lệnh chéo trang (Cross Site Scripting – XSS) và Giả mạo yêu cầu chéo trang (Cross-site Request Forgery – SRF).

Các vấn đề về XSS và CSRF

XSS đề cập đến việc chèn HTML ngẫu nhiên (cùng với JavaScript) vào các trang Web để thường bỏ qua các cơ chế kiểm soát truy cập. Để giải quyết vấn đề này, các nhà phát triển phải thoát khỏi văn bản một cách khéo léo để nó không thể có các thẻ HTML ngẫu nhiên. Có nhiều sơ đồ thoát mà nhà phát triển chọn tùy thuộc vào vị trí đặt chuỗi không đáng tin cậy (thoát) trong tài liệu HTML. Các lược đồ này thoát khỏi chuỗi được đề cập.

Một vấn đề khác là CSRF hoặc XSRF, thậm chí có thể áp dụng được cho JSON, chủ yếu là do cách thức hoạt động của trình duyệt. Trong CSRF, các lệnh trái phép được gửi từ người dùng có vẻ đáng tin cậy đối với trang web. Không giống như XSS trong đó sự tin cậy của người dùng đối với một trang web cụ thể bị khai thác, sự tin cậy của trang web được phát triển cho trình duyệt của người dùng bị khai thác trong CSRF.

May mắn là một phần đặc tả JavaScript có thể giải quyết vấn đề này một cách dễ dàng nhưng điều đó chỉ áp dụng được nếu nhà phát triển sử dụng hàm jsonfy() để tạo cấu trúc JSON. Điều này chỉ ra rõ ràng rằng rủi ro vẫn chiếm ưu thế nếu sử dụng các phương pháp tạo cấu trúc JSON khác.

Các vấn đề về triển khai

Trước đây, một số quá trình triển khai trình phân tích cú pháp JSON đã gặp phải nguy cơ bị tấn công từ chối dịch vụ (DoS) và lỗ hổng phân bổ hàng loạt.

Tấn công DoS: Đề cập đến nỗ lực khiến tài nguyên hoặc máy trên mạng không khả dụng đối với người dùng mục tiêu. Ví dụ: những người dùng này nhận được thông báo, chẳng hạn như tạm thời bị tạm dừng hoặc dịch vụ bị gián đoạn, trong khi kết nối Internet. Đôi khi, Từ chối dịch vụ phân tán (DDoS) cũng tấn công trong đó nguồn tấn công không phải là một mà là nhiều, thường là hàng trăm địa chỉ IP. Điều này tương tự như việc tụ tập nhiều người chen chúc trước cổng tòa nhà văn phòng. Đám đông này đông đến mức những người hợp pháp, chẳng hạn như quản trị viên hệ thống, không có cơ hội đến văn phòng đúng giờ, điều này làm trì hoãn các công việc bình thường. Ngoài lỗ hổng này, JSON còn dễ bị lỗ hổng bảo mật bỏ qua, trong đó kẻ tấn công bỏ qua một số quy tắc bảo mật, điều này làm tăng nguy cơ xảy ra các cuộc tấn công khác. Các phiên bản JSON trước 1.55, 1.6.8 và 1.77 dễ bị tấn công như vậy.

Lỗ hổng phân công hàng loạt: Đề cập đến việc xử lý sai mẫu bản ghi hoạt động trong ứng dụng Web để thay đổi các mục dữ liệu bí mật, chẳng hạn như quyền truy cập tệp và mật khẩu, theo cách trái phép. Khung của một số ứng dụng Web hỗ trợ khả năng ánh xạ quan hệ đối tượng và bản ghi thông qua đó dữ liệu ngoài được tuần tự hóa được chuyển đổi thành các đối tượng bên trong và do đó ghi lại các trường trong cơ sở dữ liệu. Trong trường hợp giao diện của framework
quá tự do cho việc trao đổi đó, kẻ tấn công có thể dễ dàng ghi đè lên các trường như quyền của quản trị viên.

Vấn đề liên quan đến khả năng di chuyển dữ liệu

Mặc dù JavaScript cấm sử dụng các dấu kết thúc dòng Unicode mà không được thoát trong chuỗi, JSON lại cho phép chúng. Các dấu kết thúc này là dấu phân cách dòng (U+2028) và dấu phân cách đoạn (+2029). JSON chỉ cấm các ký tự điều khiển, đó là lý do tại sao nó chấp nhận các dấu kết thúc này. Để đảm bảo tính di động tối ưu, điều cần thiết là các đầu cuối này phải được thoát dấu gạch chéo ngược.

ISON cho phép ký tự null (U+0000) trong chuỗi nếu thoát là “\u0000”. Tuy nhiên, ký tự null tạo ra vấn đề với một số cách triển khai JSON, đặc biệt là với các chuỗi trong ngôn ngữ C.

Một vấn đề khác là mã hóa UTF. Nhà phát triển có thể mã hóa tệp JSON bằng UTF-8, UTF-16 hoặc UTF-32. Trong số này, UTF-8 là chuẩn mã hóa mặc định. Tất cả các bảng mã bao gồm toàn bộ bộ ký tự Unicode, bao gồm các ký tự bên ngoài Mặt phẳng đa ngôn ngữ cơ bản. Các ký tự này từ U+10000 đến U+10FFFF. Khi thoát, điều cần thiết là phải viết các ký tự này bằng cách sử dụng các cặp thay thế của tiêu chuẩn UTF-16.

Ví dụ: để biểu diễn ký tự Biểu tượng cảm xúc U+1F606, trong JSON, mã sẽ như sau:

{ "face" : "0xD83D 0xDE06" }

Tuy nhiên, một số trình phân tích cú pháp JSON không có thông tin chi tiết về các cặp này. Một vấn đề khác là việc biểu diễn các số JSON liên quan đến ngôn ngữ lập trình. Không có sự khác biệt giữa giá trị dấu phẩy động và số nguyên, một số cách triển khai không coi 32, 32.0 và 3.2E+1 là giống hệt nhau, trong khi những cách khác lại coi chúng giống nhau.

Ngoài ra, không có thông số kỹ thuật nào tồn tại cho các vấn đề triển khai khác, chẳng hạn như làm tròn, tràn hoặc số mũ quá lớn, tràn hoặc số mũ quá nhỏ và mất độ chính xác. Cũng không có yêu cầu nào được nêu để xử lý các số 0 có dấu, chẳng hạn như 0,0 và -0,0. Mặc dù hầu hết các cách triển khai bao gồm JavaScript đều tuân theo tiêu chuẩn IEEE 754 floating-point và bảo toàn các số 0 có dấu, nhưng tất cả các cách triển khai JSON không nhất thiết làm như vậy.

Tính di động cũng bị ảnh hưởng vì JavaScript có nhiều loại dữ liệu gốc mà JSON không hỗ trợ. Các loại dữ liệu này là Error, Date, undefined, function và regular expression. Để thể hiện các loại dữ liệu này, một số định dạng dữ liệu phải được các ứng dụng ở cả hai phía (máy khách và máy chủ) chấp nhận. Một số giải pháp vẫn tồn tại, chẳng hạn như chấp nhận Ngày làm kiểu Chuỗi nhưng không có giải pháp nào trong số đó được nhất trí chấp nhận. Tuy nhiên, một số ngôn ngữ có thể hỗ trợ các kiểu gốc riêng biệt, cần được sắp xếp thứ tự phù hợp cho các chuyển đổi như vậy.

Xử lý JSON an toàn

Mặc dù hàm eval() ảnh hưởng bảo mật nhưng các biện pháp phòng ngừa thích hợp có thể đảm bảo dữ liệu JSON được bảo mật. Với mục đích này, có hai cách tiếp cận là tránh sử dụng chức năng này hoặc để đảm bảo rằng dữ liệu được an toàn. Nhà phát triển có thể chọn bất kỳ một hoặc cả hai cách tiếp cận cho một ứng dụng.

Tránh eval(): Điều này có thể thực hiện được bằng cách sử dụng thư viện JavaScript thay thế. Hãy ghi nhớ lợi thế bảo mật bổ sung của việc trực tiếp không sử dụng eval(), không có lý do gì để không chuyển sang một trong các thư viện phân tích cú pháp khác.

Đảm bảo tính toàn vẹn dữ liệu JSON: Đây là cách tiếp cận thứ hai, xuất phát từ XMLHttpRequests. Chỉ có thể thực hiện những yêu cầu này trên cùng một miền, điều này cho thấy một số khả năng toàn vẹn được tích hợp. Mặc dù vậy, mã phía máy khách vẫn phụ thuộc vào tính bảo mật của mã ở phía máy chủ. Hơn nữa, nếu nhà phát triển không sử dụng XMLHttpRequests, thì vẫn có thể đảm bảo tính bảo mật bằng cách sao chép quy tắc cùng một miền. Điều này được thực hiện bằng cách làm cho cả máy chủ và máy khách chuyển mã thông báo cho nhau. Việc xác thực mã thông báo sẽ xác minh rằng giao tiếp là hợp lệ và không nhằm mục đích tấn công độc hại.

Để tăng cường bảo mật, nhà phát triển thậm chí có thể sử dụng các kết nối Bảo mật Giao thức Truyền Siêu văn bản (HTTPS), xác thực dựa trên cookie hoặc Điều khiển trực tiếp Web Từ xa (Direct Web Remoting DWR). Thư viện DWR được viết bằng Java để tương tác với JavaScript của trình duyệt khi chạy trên máy chủ.