Gotcha! Implementing Security Layers - Applied SOA Patterns on the Oracle Platform - page 455

At first glance, nothing is wrong, except the potential JSON parser/deserializer's strength.
Also, we know that the standard eval() function, used for conversion JSON into a JS
object, is full of holes. The eval() function in many cases (five conditions that can pre-
vent this from happening, some of which are based on filtering) can execute the embedded
JavaScript code. Also JSON's array vulnerability has been exploited many times. The
most well-known victims are Gmail and Twitter.
Tip
JSON is no less secure than XML. It's all about how you use data (encryption, digital sig-
nature, screening, validating against standards, use of reliable parsers instead of ev-
al() ). The preceding example with the injecting of potentially insecure JSON (which
also could be the subject of injection) is something you must strongly reconsider.
Schema poisoning
The attack code for schema poisoning is AT07 .
Poisoning, that is, injecting malicious code into a single document, XML or JSON, is bad
enough, but the corruption of your entire service data blueprint is a disaster, one that at-
tackers will try to hide from you as long as they can, sneaking in and out unchallenged. It
could be the result of a long-planned attack, when an attacker watched your dev repository
site, got into it, modified schema or its include elements, and then waited for the oppor-
tunity in production.
A bit complex isn't it? Most common for the complex schemas is having different XSDs
at different locations, sometimes public for common QDT/namespaces; an attacker can
get into the weakest location and change the element type of the XSD instruction. Some-
times, just changing the level of data granularity could be enough—an unlimited string in
a key element can open enough room for injections.
Another way of poisoning is having entire schema as <any> . Yes, we used this type of
declaration for the demonstration of the universal message container for the agnostic con-
troller, but we did it behind the perimeter protection. We all know many SOAP-like end-
points that accept <any message> because there are so many message/schemas, types
of data, and vendor's versions, so it seems to be easier to parse messages on the backend
without initial validation. So many opportunities for the attacker!