Database Reference
In-Depth Information
•
Exception Shielding for responses:
This is for an individual service at the time
of design, combined with the Service Broker (composition controller). In addi-
tion, it can be applied to the Service Perimeter Guard.
Broken authentication and session management
The factors that can lead to insufficient authentication are reliance on weak passwords,
single-factor authentications, unreliable/compromised protocols, algorithms (such as
MD5), the usage of digital signature without encryption (and vice versa), too short or re-
peatedly reused session keys, a simplified nonce, the possibility to compare protected and
unprotected messages, revealing/loss of private keys and certificates, storing passwords as
clear text in AIM DB, and misconfiguration of trusted subsystems that allow the by-
passing of the service contract and accessing the service resources directly.
The following are the suggested patterns to apply:
• Brokered and Direct Authentication:
◦ Identity DB/LDAP
◦ Policy Enforcement Point
◦ Policy Definition Point
◦ SOAP Header
◦ HTTP Header
◦ SAML elements
◦ PKI elements (such as CRL)
Cross-site scripting (XSS)
The distributed way of handling a service request is quite common. What's more is a
single message can be addressed to separate services in parallel or sequentially. Intercep-
ted (the man-in-the-middle attack) and forged in certain parts, impersonating trusted
parties (see Trusted Subsystem pattern,
http://soapatterns.org/design_patterns/trus-
ted_subsystem
)
, a message can cause session hijacking, malicious redirections, and the
exposure of sensitive data. As we mentioned earlier, an attack on Amazon was successful
because the application signature verification and XML interpretation were handled separ-
ately. Yet again, Amazon is quite protected now against XSS. Are you?
The following are the suggested patterns to apply:
•
Data Origin Authentication (digital signature)
: In this, Service Perimeter
Guard can be used as a pattern
Search WWH ::
Custom Search