Here, we will combine the most common error handling vulnerabilities, allowing attackers to explore your line of defense and collect all the necessary technical information about your services for further steps, aiming at authentication/authorization weaknesses. The methods are quite obvious:

The important thing is that whatever hacking technique is employed by the attacker, the initial step is always the same: gather as much information from your service response message as possible. Your Error Handler is the major supplier of this information.

Regarding the following vulnerability list, feel free to use your own labels (alphanumerical codes) for all kinds of vulnerabilities. As you go further, you will need them as flags to mark potential weaknesses on the technical infrastructure map.

catch (Exception ex){
ex.printStackTrace();
System.out.println(ex);
}

try {
          provideService();
}
catch (SomeUnusualException ex){
       // our system is quite resilient and we do not care about low-probability cases
}

Object ObjectHandlingMethod() {
        Object o = null;
         ....
        try {
      o = MethodErrorThrower(); 
        }
        finally {
      CleanUpRoutines();
      return o;
  }
     }
  Object HandlerErrorThrower(){
          ...
          if (size == 0) {
        throw new EmptyStackException();
         }
        catch{
          logerror()
       }
    ...
  }

Here we mostly talk about API authentication (System-to-System) and not just about human and web page interactions (although it's also based on SOAP and REST services, serving direct and brokered authentication). In this case, arguably, you can assume the main authentication weakness of all time—the password strength can be finally tamed as the API is not affected by typical human factors, that is, the ability to remember passwords (or leaving yellow sticky notes on the monitor). Indeed, just from a password strength calculator (you will find a lot of them on the Web), we can see that a four-character password, which is common for humans, can be brute forced in a couple of minutes, while a 20-character API key will take ages (with adequate OS (Linux/Unix/Windows) file protection in place, of course).

Well, our optimism should be very cautious about that though. Not too long ago, we were able to use Amazon S3 and EC2 cloud services (actually, AMIs with all our assets) to log in with our regular Amazon shopping account. So naturally, as mentioned earlier, using signature-wrapping (stripping) and cross-site scripting (XSS) attacks, pentesters were able to compromise these Shopping and EC2 credentials and gain total control over the victim's account with virtual machines containing stored code and data. Should we mention the victim's shopping cart? Should we also mention that EC2 is probably the most popular sandbox for developers from several leading companies?

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:

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 following tasks:

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, delete xpsql70.dll, drop EXEC sp_dropextendedproc @functname='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 attack as well as an invitation to gain full control over all your resources. These types of attacks are well documented and included in OWASP. Countermeasures that have already been mentioned include not giving your service account more privileges than is really necessary. (Frankly, we all know where it comes from—on a Dev server, our developers focus on functionality first and security granularity later. Please do peer review for the component's code and installation scripts including DB.) In addition to the already mentioned vulnerabilities, the most common authentication and authorization (AA) vulnerabilities are gathered in the following sections.

String plainText = new String(plainTextIn)
   MessageDigestencer = MessageDigest.getInstance("SHA");
   encer.update(plainTextIn);
   byte[] digest = password.digest();
    if (digest==secret_password()){
//log me in
    }

import java.net.InetAddress;
public class Authenticator {
public boolean authByHostname (String clientIP) throws Exception {
      booleansafe = false;
     InetAddress address =InetAddress.getByName(clientIP);
      String hostname=address.getHostName();
String canonicalhostname = address.getCanonicalHostName();
                        If (canonicalhostname.endsWith("trustedsite.com")) {
                             safe = true;
                        }
                        return safe;
  }
}

Anything that can be inserted, implanted, or simply added to the command line or DB query string could not only break data consistency or add unwanted data portion to the dataset, but also execute some DB or OS command, allowing the attacker at the end to gain complete control of the victim's system.

At the very least, the system will respond with an error message, and it is the architect's responsibility to balance the SOA security, abstraction, and discoverability requirements.

Several factors make this risk number one in the top 10: difficulties in mitigation, number of attack-automation tools, and potential devastation.

The following are the suggested patterns to apply:

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 repeatedly 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 bypassing of the service contract and accessing the service resources directly.

The following are the suggested patterns to apply:

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. Intercepted (the man-in-the-middle attack) and forged in certain parts, impersonating trusted parties (see Trusted Subsystem pattern, http://soapatterns.org/design_patterns/trusted_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 separately. Yet again, Amazon is quite protected now against XSS. Are you?

The following are the suggested patterns to apply:

The usage of FSO configuration elements is inevitable (for example, XML, INI, or property 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 adequate file protection from the OS side? What if the attacker, by executing a buffer overflow 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 infrastructure (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 interactions (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 finding the real problem.

The following are the suggested patterns to apply:

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 run a service under the root privileges? Do you keep your firewall ports configured by default (it's still not a problem to find which are opened, but we do not want to give the bad guys a chance to slack)? Still believe that WEP is unbreakable (in addition, allowing guest WEP-based Wi-Fi access to corporate data)?

This sanity checklist is not complete, but we have no intention to publish a corporate red book with all security do's and don'ts.

Another noteworthy point is that you can play and have a lot of fun with honeypots and honeynets, but please make sure that they are completely (better still, physically) separated from any of your actual environments.

There is no pattern called diligence or vigilance; that's the state of mind of security ops. You, as an architect, must assist with the proper security configuration of the following elements of the SOA infrastructure:

In fact, every single element of your SOA infrastructure must not go amiss. An obvious thing to say is that highly reusable components, service engines, and most common service agents must be checked first and on a regular basis.

You also have to include into your Ops red book (security response plan) and orange book (backup/recovery plan), a drill schedule, usually performed on your honeynet.

From a perspective of common sense, this is not a vulnerability, but primarily a negligence similar to the security misconfiguration discussed earlier and quite common to web applications (remember, we are not accusing anyone). However, for SOA, it has a broader context. Data is not only exposed on static web via AJAX/REST API. More often than not, it is insufficient crypto-strength or the lack of crypto-protection on sensitive elements of a SOAP message.

Reliance on TLS when intermediaries are on the message path is another example of such exposure, especially if the intermediary is active, that is, involved in message transformation. Even behind the Secure Gateway, in IPC-certified organizations, message data should be encrypted all the way to the ultimate receiver.

The following are the suggested patterns to apply:

Missing function-level access control vulnerability denotes insufficient authorization. It is not enough to just check whether the user is valid; a system must guarantee that this user will be allowed to call only permitted operations.

The Entitlement Server is an essential part of identity management, and for API management, Oracle Enterprise Repository with Registry (UDDI) synchronization is highly important. In terms of authorization, all your policy definition points should be supplied with connectivity to the IAM Rights/Entitlement store. Needless to say, any client-based validations for authorization do not make sense.

The following are the suggested patterns to apply:

This is a kind of manipulation, that is, when a legitimate client is forced to send a request to the service on behalf of a forger. A request can include session-related information including cookies.

Distributing session cookies is a common practice, for instance, in a multiscreen IP TV, when a valid user wants to transmit active session data from the big screen to or her tablet (or vice versa). This situation can be emulated by an attacker in order to catch and analyze the session data.

The following is the suggested pattern to apply:

Similar to XSS, this kind of design flaw is quite harmful for distributed service activities (although, OWASP considers it as a moderate threat). The dynamic nature of service compositions makes SOA architecture quite susceptible to these kinds of attacks.

Going further, the implementation of the absolutely valid Endpoint Redirection SOA pattern (http://soapatterns.org/design_patterns/endpoint_redirection), used for version control and service load balancing, can open the door for such attacks if redirection is done by simple mapping on LB without any perimeter protection with message scanning.

The following are the suggested patterns to apply:

Make sure that all redirects originated and orchestrated by your composition controller (destination endpoints taken from the service repository, the external API URL) are validated separately by SG. Do not accept any redirect parameters from the response message belonging to previous invocations.

If you maintain an invocation list in a message header (message tracking data), make sure that it is assembled from trusted sources.

The attack code for the reflection attack is AT01. A typical attack sequence is listed in the following steps:

The attack code for identity spoofing is AT02.

The identity associated with the message or resource must be removable or modifiable in an undetectable way for the attacker to perform this attack.

For example, after authentication, the valid REST service user will have their token as a part of the URL query string for an extended session. Resource access permission is validated using this token. The user with less privileges from the parallel valid session will obtain this query string (man-in-the-middle, https://www.owasp.org/index.php/Man-in-the-middle_attack and eavesdropping, https://www.owasp.org/index.php/Network_Eavesdropping and modify the session using the obtained token (or user ID if it is open). They will have time until the session expires to illegally access the resources.

In the query string, the entire static section of it must be signed. The signed digest can be in the HTTP header and enforced by a contracts policy (in the security gateway). In the case of SOAP messages, WS-Security elements for the digital signature and encryption must be applied.

The attack code for the replay attack is AT03.

As we demonstrated earlier, replay attack is the attacker's bread and butter. Having constructed using your XSD or intercepted message, the attacker modifies the time range in the message (if applicable), and the sequence numbers (if necessary), and resends it, sometimes stripping the signatures (if the policy allows).

This attack has many variations and is not always intended to be successful at the very beginning; gathering response info is the initial target, including session data (as almost any SOA message exists in a certain session context). An attacker will explore the predictability and randomness of the session ID in order to repeat this attack with a more accurate IDs. Needless to say that the sequential IDs and reliance on date or time ranges is not a really good idea.

This attack can be combined with buffer overflow attacks in order to crash the service completely. An attacker can assume that after the service restarts, cache will be nullified as well, so the new session ID (possibly starting with zero) will be accepted for the same old message. Oracle's distributed cache and clustered environment with many OFM nodes can prevent this, but an attacker could try to shutdown all nodes at at once, or try to get to the Node Manager (especially if it's in a single-node mode).

If the distribution of cookies is involved, cookies reverse engineering can be employed in order to make the reply attack successful.

The attack code for SQL injection is AT04.

The true and, therefore, bitter irony here is that due to a lot of DB abstraction layers (including X/O mapping, persistence layers, and even migration to NoSQL DB types) in a service's internal architecture, some experts openly proclaimed a couple of years ago the Death of SQL Injection. As you can see, it's a present-day top risk and all the old techniques we used for old ASP pages are quite powerful for REST and SOAP.

Even if the replay attack fails the information about the backend DB is gathered, such as the version, patches, platform, and possibly constraints, DB name and tables name. It is quite a good start to look for a violation of your Contract Centralization SOA pattern implementation (http://soapatterns.org/design_patterns/contract_centralization), look for open DB connections available at the service location, and carry on with the injections.

Interestingly, SOAP messages can be a good carrier of SQL injection attacks and an overenthusiastic Error Handler can provide perfect assistance in it. A simplified SOAP request will look like the following code:

<soapenv:Body>
           <pci:getCreditCard   soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
                         <id xsi:type="xsd:string">1 or 1=1</id>
           </pci:getCreditCard>
</soapenv:Body>

Yes, the same old 1 or 1=1, exactly as in old HTML/ASP times. The pci namespace is pointing to the webgoat.owasp.org test application, which is open to such a direct approach. You might think that your application is far better protected than OWASP WebGoat application (which is in fact deliberately unsecured). We hope so, but let's not jump to conclusions right away. All we know (from the preceding code) is that the XML SOAP message can be used for the SQL injection directly. There are three classes of SQL injections: Inband, Out-of-band, and Inferential. The difference is how you get the response (if you ever get it). If you see the response immediately, that's Inband, and in the SOA world, it's the most common. What if you shut down the error handler, block all responses and return nothing, and redirect everything back to a 404 page? Can you be safe? Sorry fellow architect, the answer is no. Jumping ahead, we can say that an Inferential or Blind SQL injection technique is the hardest one, but it can still do the trick. The following is a simplified modification of the previous code example:

<id xsi:type="xsd:string">id=1; if not(select system_user)<>'sa' waitfor delay '0:0:10' </id>

So, what we are actually asking is what privileges your service account has on the underlying resources. If it's a MS SQL system admin, please return your "unbreakable" 404 page after 10 seconds. One way or another, we will get the answer, but it will take just a little longer.

All these attacks are so common and effective that they have a lots of tools to support most of the attack types. Firstly, to find the victim (entity service, potentially with DB), public Seekda Web Service search engine or WSindex can be used. For official UDDI crawling of public services, http://www.soapclient.com/uddisearch.html is useful.

To probe and test the targeted service, SoapUI is amazingly good (you can try it together with WebGoat first). However, if someone wants command-line tools to fire constructed SOAP messages with injections, then SOAPClient4XG (Java), CURL, and SOAP::Lite (Perl) prove to be handy. If you need something for all occasions, Burp Suite is an obvious choice and you will learn a lot about injection attack patterns and much more. Talking about injections, specifically with proxy assistance, look at the following list:

We are sure that you will find more, but at the time of writing this, these were active and quite helpful. Still, if you are going to use them as a verification tool, remember that they do not cover all three types of injections and you have to do a lot of manual work to identify service weaknesses (we will not go into the basics of injection as it's not the subject of this chapter).

So an attacker gets the error message (or whatever—system silence is also a message). The injection point is identified. The next step is to identify what type of data is behind. That's simple, because your XSD will clearly say that. If not, it is not that difficult to learn after a series of reply attacks. Why is it important? Because attackers will learn, should they use a single quote for 1=1, and the type of evasion technique will be necessary to bypass signature scanners at the Security Gateway:

…>id=1 having 1=1... or   …>id=X' having 1=1 …

An attacker wants your data. Thus, union-based constructs will be used along the way. If your service stays passive, the last resort is blind injection.

What's important here is that this technique is almost identical for REST, SOAP, or command-line (direct) attacks in terms of construction of the injection syntax. In REST, you (or the attacker) can use the following:

http://[victim_site]/[victim_resource_page]?id=1%20or%20 1=convert(int,(CREDITCARD_NUM))

If error messages are on, the system will respond with an error saying that the conversion to int failed, but it will give you (or the attacker) the actual column name. So, you can collect all the column names from the REST service DB (guesswork here is exceedingly easy).

If that doesn't work, you can identify the number of columns first using a union-based technique, such as UNION, SELECT ALL, 1, 2, 3...N, where N is the number of columns and you have to try it N times (just some guess work). After that, you can start replacing the numbers with possible column names and watch the response. A lot of the previously mentioned hacking tools can do this for you.

Blind injection is the hardest because all that you can simulate usually is how quick the blank error page (404, or whatever) will be returned. So, it's basically just "Yes" or "No"; however, with some persistence, that would be enough. The sqlmap.org site uses blind injection, so it will help you in the hardest cases.

For an attacker (or you, if you pentest your security perimeter), life is a bit more complex than breaking into a WebGoat site and the actual REST injection query string could contain something like the following code (depending on DB and its version) as well as 200 more characters, presenting conditional branching, redirecting, and calls for recreation of the earlier deleted xp_cmdshell stored procedure. (Yes! It can be restored by SQL injection in the REST service query!):

...OPENROWSET('SQLOLEDB',";'sa';'<password>','select 1; DECLARE@resultint,@OLEResultint, .... EXECUTE @OLEResult=sp_OACreate "WScipt.Shell", ...... "CreateObject%0X",...

An attacker can change the privileges, call standard packages, or stored procedures (Oracle or MS SQL). Even using a blind injection, it is possible to extract a sys password and the current service account into the DBA group.

We will touch upon countermeasures in the following section, but while we are in the attacker's shoes, we will briefly explain how they can be dodged:

The last thing to mention is that SQL injection is still the most popular, but don't count on it alone. The attacker will unleash a complex multivector attacks the injection's support. One of the possible combinations could be as follows:

By the way, if you think that SQL injections are possible because someone is concatenating the SQL string before executing the query, be aware that the SQL procedure injection is quite possible as well. Prepared statements are more resilient though.

The conclusion is that the attacker has an advantage, not you. Your task is to prepare a multilayered defense.

The attack code for XPATH injection is AT05.

The underlying idea behind XPath (and XQuery) is to see XML as a kind of systematic storage (similar DB) and have similar ways of accessing data.

So, as in SQL, user supplied information can be used for the construction of the XPath query string. The hacking methods are almost identical to those previously explained.

The standard path to employees' XML data, /employees/employee[@id='EMPLOYEE_ID'], can be easily supplied with the classic '%20or%20'1'='1 and all the employee data (including CEO) will be dumped to the browser. You can add any XPath-related function you like, such as:

'%20or%20fn:contains(fn:lower-case(@lastname),'your_CEO_lastname')%20or%20'

The counter-countermeasures are similar to an SQL injection. The most hard to break are the prepared statements for XPath expressions.

The attack code for JSON and JavaScript injections is AT06.

Imagine your service accepts the JSON documents (or constructs them based on user input) and stores them for public use. For big and bulky JSONs, you would dedicate a NoSQL database, hoping that NoSQL means NoSQL injections.

JSON itself is brilliant, as it's simple, and it can be injected (in a positive way) in any software/site capable of handling JavaScript. The flexibility is immense, thanks to AJAX and shared DOM. We can manipulate web page elements almost effortlessly using, for instance, the Chrome extension API (chrome.extension.getURL()). JSON content will be included directly into the <script> tag of the targeted page. You will find all the necessary instructions on the jQuery site, including manifest.json and a sample of the <injected.js> files.

Fellow architects, the preceding paragraphs are from the Chrome Extension API and jQuery documentation (https://developer.chrome.com/extensions/extension#method-getURL and http://jquery.com/), that's not a joke. You will even find the following examples:

document.head.appendChild(script);
document.body.setAttribute("onLoad", "injected_main();");

At first glance, nothing is wrong, except the potential JSON parser/deserializer's strength. Also, we know that the standard eval() function, used for conversion JSON into a JS object, is full of holes. The eval() function in many cases (five conditions that can prevent this from happening, some of which are based on filtering) can execute the embedded JavaScript code. Also JSON's array vulnerability has been exploited many times. The most well-known victims are Gmail and Twitter.

The attack code for schema poisoning is AT07.

Poisoning, that is, injecting malicious code into a single document, XML or JSON, is bad enough, but the corruption of your entire service data blueprint is a disaster, one that attackers will try to hide from you as long as they can, sneaking in and out unchallenged. It could be the result of a long-planned attack, when an attacker watched your dev repository site, got into it, modified schema or its include elements, and then waited for the opportunity in production.

A bit complex isn't it? Most common for the complex schemas is having different XSDs at different locations, sometimes public for common QDT/namespaces; an attacker can get into the weakest location and change the element type of the XSD instruction. Sometimes, just changing the level of data granularity could be enough—an unlimited string in a key element can open enough room for injections.

Another way of poisoning is having entire schema as <any>. Yes, we used this type of declaration for the demonstration of the universal message container for the agnostic controller, but we did it behind the perimeter protection. We all know many SOAP-like endpoints that accept <any message> because there are so many message/schemas, types of data, and vendor's versions, so it seems to be easier to parse messages on the backend without initial validation. So many opportunities for the attacker!

The attack code for forced browsing is AT08.

As described by OWASP, forced browsing is an attack where the aim is to enumerate and access resources that are not referenced by the application but are still accessible.

This is quite a nasty thing and really dangerous. You have SOAP/WSDL, or more commonly, the REST service infrastructure with plenty of handy services available. It's so easy to build the REST service, as demonstrated earlier. When you start, it's almost impossible to stop. You have them for the internal purposes of accounting/finance, delivery and warehouse, procurement and provisioning, and those OrderRequest and getInvoice services that you decided to make public. Or do you just think only two of these are public?

Some of the scanners mentioned earlier are capable of traversing the victims' server in order to find those that are not declared but still exposed resources with a much less secure model. Brute force guessing could work as well.

Indisputably, Oracle is one of the leaders in directory product offerings (LDAP directories). The Oracle Internet Directory (OID) was the first product in this group and now, we have a highly efficient Oracle Unified Directory (OUD), which includes both a highly scalable LDAP directory service based on Java and a Oracle Virtual Directory (OVD) product. OUD comes with the following three main components:

The Directory Server essentially is a highly scalable and top-performing LDAP. The Proxy Server contributes to LDAP's high-performance proxy requests and responses and the Replication Server is responsible for the data replication from one OUD to another.

This list of products is just an indication that Oracle has everything necessary for the proper implementation of all eight SOA security patterns. Now it is your responsibility to enforce the security of your services by addressing error handling vulnerabilities (these are what makes your services leak and opens the door for injection-type attacks).

As an option, javac will warn you about the return in the finally block if a compiler's argument is set as -Xlint:finally. Use of the Ant <compilerarg> element as follows:

<javacsrcdir="${src.dir}" destdir="${classes.dir}" classpathref="libraries">
<compilerarg value="-Xlint"/>
</javac>

Correct cleaning is always important, but you should be extra careful with threads. Please look at the following code samples. They can help you to mitigate at least two types of attacks, bases of buffer overflow and information leakages:

private static final long SLEEP_INTERVAL = 100;
private static void removeGarbage() {
 try {
     System.gc();
    //give a thread chance if you can
    Thread.sleep(SLEEP_INTERVAL);
     System.runFinalization();
  }
  catch (InterruptedExceptionie){
    //handle threads properly, log exception clearly,
     //DO NOT JUST print stack trace !
     // Try to exit neatly, do not just kill it by  .stop()  method
      Thread.interrupt();
    }
//Other errors
   catch (Exception ix){
      //same as above, DO NOT JUST print stack trace !
      // use Runtime.getRuntime().totalMemory(), maxMemory() and freeMemory()
      // in logging procedure for recording the JVM memory state at the moment of
      //error.  Use simple equation  usedJVMMemory = totalMemory() – 
      // freeMemory()  for  calculating amount of used memory.
    }
}

Although samples in this paragraph are Java-related (strategic Oracle language), make sure that you have the proper PL/SQL exception handlers as well. All data handling code should be on PL/SQL. (This is for a relational DB, of course; for NoSQL, it depends on realization but is close to data.) Use PL/SQL packages for better modularity and EH centralization. The statement in packages must be prepared. That's it. These are the most effective measures to make injection attacks as hard as possible. Oracle provides complete guidance on how to write injection-proof PL/SQL code. You can find the documentation at http://www.oracle.com/technetwork/database/features/plsql/overview/how-to-write-injection-proof-plsql-1-129572.pdf.