JSON (JavaScript Object Notation) is fast becoming the most widely used data format in interactive web and mobile applications. AJAX started out as Asynchronous JavaScript + XML, but it’s increasingly implemented as Asynchronous JavaScript + JSON. This is because JSON is considered more efficient and lightweight than XML and blends more easily into JavaScript (shares similar syntax). It is also more “human-readable” and popular with REST API proponents.

Moreover, using REST/JSON is also now considered a best practice in mobile applications. Being more compact compared to XML, it takes up less bandwidth on wireless networks, which can be flaky or unpredictable. It also requires less CPU and memory to parse, and thus consumes less battery on mobile devices. In fact, many big names like Twitter, Foursquare, and a lot of Google products have deprecated their XML APIs in favor of JSON-only APIs.

While businesses have a strong motivation to create dynamic, mobile-friendly applications using JSON/REST interfaces, security often takes a backseat in a race to get it to market. Often, security that is properly baked in the original HTTP interfaces, is not properly implemented and tested in the JSON/REST interfaces.

XML has its own strengths in extensibility and namespaces which makes it de-facto in SOA architectures and web services. We have supported XML payload security for a long time. With the release of firmware 8.0, we are also introducing support for securing JSON payloads.

A very simple JSON example could look like the following in a HTTP POST request:

{"username": "John","password": "mypassword"}

A web application would normally parse this into structured data with key-value pairs like username=John. The keys or values could then be used just like URL query parameters or FORM parameters. An attacker could inject malicious inputs in the JSON key-value data that would result in the same attacks as those that would have resulted through query or FORM parameters. For example, by appending SQL commands to John above, (s)he could compromise the database if the web application generates an SQL query that embeds this value.

From firmware 8.0 onward, when you create a new HTTP/S service, a default JSON profile is auto-created for the whole URL space (/*) of that service. This profile applies JSON security policies automatically when the request MIME type indicates that the payload is JSON. For non-JSON MIME types, it does nothing, so performance is not affected. You can view JSON profiles on the WEBSITES > JSON Security page.

If the same Service (VIP) frontends multiple different applications with differing JSON protection needs, or if you want to relax or tighten the JSON security policy for different URL spaces, you can create multiple JSON profiles for the respective URL spaces using the Add JSON Profile dialog:

All the input validation checks for key-value pairs are specified in this dialog. This includes checks for SQL injections, XSS, etc. The JSON format-specific checks are specified through the JSON Policy control, which is set to default-policy above. You can view the details of this policy by finding and editing it at the bottom of the main page.

The policy allows you to specify JSON format-specific checks including max lengths, depth, siblings and the likes.

If you would like more information about the Barracuda Web Application Firewall, visit our corporate site here. You can get technical details, model information, case studies, and more. If you'd like to try the Barracuda Web Application Firewall risk-free for 30 days, click here and submit a request.