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

From the proven SOA Pattern Catalog, we have eight security patterns: four for service
implementation (Group I for static service implementation, starting from Exception
Shielding ; http://soapatterns.org/design_patterns/exception_shielding ) and four to protect
service interactions (Group II for service messages in transit). Some of the patterns such
as Data Confidentiality and Data Origin Authentication (group II, see ht-
tp://soapatterns.org/design_patterns/data_confidentiality ) are in fact the direct realization
of the WS-Security standard, WSS (see https://www.oasis-open.org/committees/
tc_home.php?wg_abbrev=wss ) , covering two main W3C specifications: XML Encryp-
tion ( http://www.w3.org/TR/xmlenc-core/ ) and XML Signature ( http://www.w3.org/TR/
xmldsig-core/ ) . Since they are of the utmost importance, they are well covered in all the
topic we have already mentioned, so we will not focus on them much.
The Trusted Subsytem in its turn (group I) is a security-related extension of the Contract
Centralization pattern, designed to prevent access to service resources, bypassing the
standard service contract and associated security policies. Thus, there are five patterns
left: two related to Authentication and Authorization and three that can be implemented
(centralized) by the so-called Security Perimeter. To understand their roles and import-
ance, we will proceed with the most common vulnerabilities first.
Common SOA vulnerabilities
Think of military operations in close encounters. Your service domain has a certain edge
that is in one way or another exposed to the world outside. (If it's not exposed, you are the
lucky one! Why are you reading this?) This edge is actually the skirmish point, where the
attacker methodically shoots and observes, trying different weapons. A publicly exposed
contract (WSDL/REST) gives enough information for the imposter to devise the initial
weapon of choice, for example, service operations or an XSD structure—everything is
there, so an attacker has an undisputed tactical advantage. Vaguely defined XSD (types
any or string for all elements) just makes more room for experiments (in case your at-
tacker is bored) and intercepted valid messages can give the attacker a quite a good under-
standing of the possible data ranges.
One option is to not expose the WSDL definition (hide the API documentation or at least
remove all the comments from WSDL). Well, the secluded contract is not really inline
with the Composability principle. However, what about your UDDI? It is similar to the
DNS server for IP networks and susceptible to similar attacks. UDDI-crawling attacks can
turn your own versioning strategy against you if you keep old, less secure contracts avail-
able for backward compatibility.