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

We believe that this vulnerability is already mended by Amazon, but we can add several
good recommendations to our list of security design rules from the preceding case:
• Using the same password could be convenient, but that's not the idea behind SSO,
especially if cross-system authentication is based on such weak possession or
knowledge. Do not mix human- and system-based AA approaches.
• Single-factor authentication should be avoided; two-factor (by the way, Amazon
claims to have multifactor authentication, MFA) with one easily compromised
factor will give you a false sense of protection. In fact, any systems based on
something you know (password) should be enforced with something you possess
(token), something you are (for example, fingerprint), or better, password trans-
mission should be avoided completely.
Generally, gaining direct access by exploiting or resending SOAP/REST messages is a
kind of gamble and will require not only inefficiency in security design, but also a little
luck as well, and usually attackers do not count on that. After the identification of the
backend system's types by studying response messages, the attacker will perform the fol-
lowing tasks:
• Try to obtain credential information from service resources (DB and config files)
directly.
• If the credentials for this service are obtained, check the system privileges associ-
ated with them.
• Explore the possibility to bypass the service contract and directly get to the ser-
vice resources. Use the known weaknesses of the technical platform (missing
latest security patches for Oracle DB, MSSQL, and so on).
For some reason (for instance, license policy), you can decide to use an MS SQL database
as the backend for certain critical products such as the Oracle Enterprise Repository.
That's perfectly fine, but you (your DBA) forgot to disable xp_cmdshell (or better, de-
lete xpsql70.dll , drop EXEC sp_dropextendedproc @funct-
name='xp_cmdshell' , and forget about its existence). What's worse is that the
backend resources are shared (which is common) and some services are used as a Trusted
Subsystem with SA privileges. This is the perfect recipe for a successful SQL injection at-
tack as well as an invitation to gain full control over all your resources. These types of at-
tacks are well documented and included in OWASP. Countermeasures that have already
been mentioned include not giving your service account more privileges than is really ne-
cessary. (Frankly, we all know where it comes from—on a Dev server, our developers fo-
cus on functionality first and security granularity later. Please do peer review for the com-
ponent's code and installation scripts including DB.) In addition to the already mentioned