Database Reference
In-Depth Information
Initial analysis
We would like to begin our analysis with an old saying: a chain is no stronger than its
weakest link. Banal, isn't it? Sorry about that, but indeed with four architectural SOA
levels, everything comes down to the resiliency of the single-service implementation,
which is in the lowest architectural service layer. As long as any particular service is a
composition of services (Task or Task-orchestrated service), the three basic building blocks
of SOA infrastructure can be identified. The first two are Utility and Entity service models,
usually employed to compose the Task service(s). The third is a Service engine (which is
not a small thing, but you will probably rely on an existing one instead of inventing your
own for commercial realization). An Entity service's internal architecture is usually more
complex than a Utility service, as it commonly involves DB as the entity's persistence stor-
age. Therefore, from the static implementation standpoint, all four enterprise SOA layers
will be protected proportionally to the level of security resilience of the Entity service ana-
tomy, and you certainly remember its every single block:
• The core logic is encapsulated into single or several components. How are you
handling exceptions, including NullPointerException ? Is your code thread-
safe? How about memory utilization and stack control, global variables, and so on?
If you do not know this, how can you be sure that your main architectural block is
safe? A stack/buffer overflow attack is one of the most popular ways of breaking
into your system and is commonly focused on components' implementation.
• We already mentioned DB's presence in the service anatomy. The ways of service
persistence implementation are utterly crucial for the entire SOA implementation.
The absolute champion among all types of attacks is SQL injection, and it has been
for years. Combined with improper error handling in the component (see the previ-
ous point), it will present grave danger for your business. Another quick check is
of the DB account that you assigned for this service. What privilege options are
available? DBA, XDB, or both? Another obvious question is: does anyone else ac-
cess the Service data bypassing the Service Contract (just because it is faster and
someone decided to cut some corners)?
• The Service Contract presents quite a substantial set of internal service Facades
and Agents, performing service data serialization/deserialization, exposing a com-
ponent's functions, and enforcing the internal policies. Usually, most of this func-
tionality is easily available from libraries or IDEs, but its openness is not exactly a
good thing. Attack spearheads will be pointing to XML/JSON parsers and mar-
shallers, exploiting existing or possible vulnerabilities in standard libraries and
XSD syntax.
Search WWH ::




Custom Search