Protecting Against JSON-Bourne Attacks

Mobile has become the new #1 target for hackers and cyberattacks. As more consumers and businesses become more comfortable conducting business over mobile devices, this becomes a natural target for the baddies who want to steal personal information, or just disrupt business. And if you believe what the experts are saying, you need to be prepared that your mobile phone will eventually be hacked…  With the number of incidents of malicious code (particularly on Android) increasing by the day, it is vital that your organization is prepared.

That's JSON-bourne, not Jason Bourne...

That’s JSON-bourne, not Jason Bourne…

One of the main targets is not actually what is sitting on the phone, but instead the services that the app is accessing on the back end. These services present APIs that mobile apps invoke to get and put information into back end systems. In the mobile world, most of these APIs use a simple and concise data format called JSON to transmit this data and these requests. While most organizations protect these APIs using traditional firewall technologies, many are not doing enough to protect themselves from malicious content hidden in the JSON. According to IDC, “signature-based tools (antivirus, firewalls, and intrusion prevention) are only effective against 30–50% of current security threats.”

A similar issue arose in the height of SOA adoption, where protection against XML-bourne attacks became standard practice, but with the rise of mobile and lighter weight RESTful services, organizations need to shift to make sure they are protecting themselves against new threats.

The problem is that it is fairly easy to inject malicious content, buried in JSON data, into a seemingly innocuous REST call. Unless the malicious content matches one of the signatures that your firewall is watching for, the content will get through to the server, where it can be made to automatically execute as server-side Javascript. Since this code is generally executed in a less-protected area, it often has access to sensitive back-end systems, where it can do more damage or compromise private information.

Luckily, there is a way to protect against these threats without relying solely on good programming practices. Some of the same security gateways that organizations use to protect Web services can be easily extended to protect JSON/REST services. The best of these (like WebSphere DataPower) can be delivered as secure hardware appliances that prevent unauthorized tampering and provide FIPS 140-2 Level 3 certified protection. These gateways work by inspecting the data payloads and finding and filtering out suspect JSON data (among other things), providing a much deeper level of protection than traditional firewalls alone.

When you take a look at the OWASP top 10 threats, many of these remain relevant in JSON-centric applications. For example Cross-Site Scripting (XSS) and Cross-Site Request Forgeries (CSRF) are still concerns. In addition, hackers can inject very large JSON documents that can cause massive slow-downs in the systems that process those messages. However, the biggest threat is script injection – one that is a bit more specific to how JSON is processed in Javascript, and one that enables direct execution of functions on infected servers.

With all of the focus and spending on Mobile security, organizations need to be considering this threat as much as they are the threats to what is resident on the phone itself. I don’t think this has sunk in for many organizations, yet. Is your organization ready?

Advertisements
Tagged , , ,

One thought on “Protecting Against JSON-Bourne Attacks

  1. Matt McLarty says:

    This is the JSON-Bourne attack I fear the most… Don’t forget to do some pen testing! 🙂 http://www.youtube.com/watch?v=UFnmq5PPScA

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: