Denial-of-service attacks, some of the most difficult attacks to protect against, are characterized by an explicit attempt by attackers to prevent legitimate users of a service from using that service. Common denial-of-service attacks include the following:
· Application crash
· CPU starvation
· Memory starvation
· Resource starvation
· Network bandwidth attacks
Out of the categories identified, CPU starvation, memory starvation, resource starvation, and network bandwidth attacks will be tested during the end-to-end stress runs. Thus, we will focus the test cases on application crash denial of service attacks.
1. Perform fuzz testing in an attempt to crash an application component.
2. Identify web service and runtime API that take an input that will cause a server exception. Then repeatedly call the method in a loop, in an attempt to starve the CPU, memory, or a server resource.
3. Generate load by simulating concurrent usage of all the web services, as well as the runtime site. Analyze the server and look for components that allocate large amount of memory. This can be done during the stress testing.
4. Repeatedly refresh the Server caches to look for potential for denial of service threat.
5. In the IIS log files, insert problematic characters, smartly crafted bad input, and really long URL strings. Run the log import DTS task, and look for possible denial of service or information disclosure threats.
6. Send large XML blobs to all web service API in continuous fashion (in a loop or multithreaded environment). Send really small XML blobs to the API in continuous fashion. When testing XML entry points, we can try DTD expansion attacks.
7. In an XML blob, alter the XML so it does an external namespace lookup. Attempt to crash the application leveraging this.
8. In addition, try “algorithm adversary” attacks – feeding data in a way that chokes the algorithm. For instance, binary trees are subject to disordering attacks (making the tree degenerate into a linked list), but balanced trees are not.