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

• Data Confidentiality (encryption) : In this, a service message prompts you to
make sure that every individual part of the SOAP message is supplied with the
signed digest; the nonce is crypto resilient
Insecure direct object references
The usage of FSO configuration elements is inevitable (for example, XML, INI, or prop-
erty files), especially close to the skirmish point. The developer's logic is simple: "I cannot
use full-fledged DB in DMZ; it's too heavy and has many weaknesses. The amount of
config data I will use in my utility service (or agent) dynamically is insignificant and I can
use simple XML instead, staying flexible and configurable at the same time." The logic is
flawless, but do we have file consistency checks every time we access it? Do we have ad-
equate file protection from the OS side? What if the attacker, by executing a buffer over-
flow attack, causes a segmentation fault, halts the program execution (exits abnormally),
gains control over the program's resources (not exactly root!), substitutes/modifies the
file, and lets the system restart the process? This means that the service agent infrastruc-
ture (part of the SOA architecture) is equally vulnerable to attacks as are common entity
services because agents are common event-driven programs utilized in all service interac-
tions (imagine the agent checking the elements of the <string> type for the acceptable
length) and, sometimes, their log footprint is so small that you will have a hard time find-
ing the real problem.
The following are the suggested patterns to apply:
• Trusted Subsystem
This pattern will be applied to every service and agent in the SOA infrastructure.
This is a joint task for an architect, OS administrator, and security specialist, and
must be performed during a peer review. Every single call to a resource shall be
validated and tested. As most common attacks here will be related to buffer over-
flows, you have to decide on want type of code (that is, language) you want to
implement your protection, especially close to DMZ—managed (Java) or unman-
aged (C).
Security misconfiguration
Speaking of mandatory configuration routines, please do the basic sanity check by asking
yourself the following questions: has LDAP synchronization managed with open protocol
(not SSL)? Have you applied security patches or are you afraid of breaking something in
production (alternatively, have you applied the wrong patch)? Do you encrypt HD with
sensitive data? Have you forgotten to update the Certificate Revocation List? Have you