inputs to try to flush out all possible exceptions, then examine how the service responds to each exception. If you wanted to verify that hackers could not place Java .jar files in your application and/or CLASSPATH, you would design test cases that attempt to add such files through every possible service entry point, then see whether these attempts fail. If you find these or other security holes during the testing phase, you have the opportunity to fix the problem before an actual security breach occurs.
How do you determine how much testing is enough? Ideally, you want to check whether any possible input causes unexpected access, but testing every possible input to a method is typically not feasible. A more practical goal is to try to cover each path through the unit at least once.
Establishing a Final Defense with Design by Contract
If a security breach would have very serious consequences for your application, you might want to consider building a final layer of security into the code itself. If your Web service is built using Java, you can do this with Design by Contract (DbC).
DbC was designed to express and enforce a contract between a piece of code and its caller. This contract specifies what the callee expects and what the caller can expect (for example, expectations about what inputs will be passed to a method or conditions that a particular class or method should always satisfy). DbC tools generally have developers incorporate contract information into comment tags and then instrument the code with a special compiler to create assertion-like expressions out of the contract keywords. When the instrumented code is run, contract violations are typically sent to a monitor or logged to a file. The degree of program interference varies. You can often choose 1) nonintrusive monitoring (problems are reported, but program execution is not affected), 2) having the program throw an exception when a contract is violated, or 3) having the program perform a user-defined action when a contract is violated.
DbC can enforce security boundaries by ensuring that the application never accepts inputs known to lead to security problems or enters a state known to compromise security. The first step in creating an infrastructure that provides these safeguards is to use unit testing to determine what inputs and situations can make the service vulnerable to security breaches, then writing contracts that explicitly forbid these inputs and situations. Next, you configure the program so that whenever the conditions specified in the contract are not satisfied, the code fires an exception and the requested action (for example, a method invocation) is not allowed to occur. When this infrastructure is developed after thorough unit testing, it provides a very effective last layer
Unless the industry develops an easy way to ensure Web service security, I fear that the security issues inherent in the very nature of Web services will make it difficult (though not impossible) to apply them in situations where security is of utmost importance. However, Web services can nevertheless be applied easily and profitably in many situations where security concerns are irrelevant. I predict that Web services will enjoy the most success and acceptance in the variety of possible implementations that do not involve security issues.