JSON is a method for representing arbitrary JavaScript data types as a string safe for HTTP communications. For example, a web-based email site might use JSON to retrieve messages or contact lists. Other sites use it to send and receive commands and data from databases. JSON is a method for representing arbitrary JavaScript data types as a string safe for HTTP communications. For example, a web-based email site might use JSON to retrieve messages or contact lists. Other sites use it to send and receive commands and data from databases. In addition to JSON, data formats like CSV and XML also play critical roles in web data exchanges, with each format offering distinct advantages and considerations based on the use case. Sonra provides a useful comparison of CSV, JSON, and XML for those looking to understand the differences and practical applications across various data handling needs. In 2006 Gmail had a very interesting cross-site request forgery vulnerability, recognized in its JSON-based contact list handling (http://www.cyber-knowledge.net/blog/gmail-vulnerable-tocontact-list-hijacking/). An e-commerce site might use JSON to track product information.
JSON’s format is basically a series of key/value pairs separated by colons. This makes neither easier nor harder for an attacker to manipulate, just different from the typical name=value found in query strings. The following code displays a very simple JSON string that is completely legitimate. It’s up to the server to verify the validity of the name and email values.
{“name”:”octopus”, “email”:”octo@alert(9)”}
The feature of passing content through JSON parsers and eval() functions bring a different set of security concerns because of the ease with which JavaScript objections and functions can be modified. The best approach to protecting sites that use JSON is to depend on JavaScript development frameworks.
These frameworks not only offer secure methods for handling untrusted content, but they also have extensive unit tests and security-conscious developers working on them. Well-tested code alone should be a compelling reason for adopting a framework rather than writing one from scratch.
These frameworks concentrate on building dynamic, highly interactive websites. They do not secure the JavaScript environment from other malicious scripting content. Another reason to be aware of frameworks in use by a web site is that HTML injection payloads might use any of the framework’s functions to execute JavaScript rather than depend on <script> tags or event handlers.