Denial of Service
Denial-of-service (DoS) attacks attempt to make a computer resource unavailable or insufficiently available to its intended users. Distributed denial-of-service (DDoS) attacks are launched by two or more persons or bots. DoS and DDoS attacks are generally of greater concern for persistent, server-type systems than for desktop applications; nevertheless, denial of service issues can arise for all classes of application
There are several methods of causing a denial of service:
- Vulnerability attacks involve sending a few well-crafted packets that take advantage of an existing vulnerability in the target machine.
- Resource exhaustion attacks that consume computational resource such as bandwidth, memory, disk space, or processor time.
- Algorithmic attacks (such as on hash functions) by injecting values that force worst-case conditions to exist.
- Bandwidth consumption attacks that consume all available network bandwidth of the victim.
Denial of Service Through Resource Exhaustion
Denial of service can occur when resource usage is disproportionately large in comparison to the input data that causes the resource usage. Checking inputs for excessive resource consumption may be unjustified for client software that expects the user to handle resource-related problems. Even such client software, however, should check for inputs that could cause persistent denial of service, such as filling up the file system.
The Secure Coding Guidelines for the Java Programming Language [ SCG 2009 ] lists some examples of possible attacks:
- Requesting a large image size for vector graphics, for instance, SVG and font files.
- "Zip bombs" whereby a short file is very highly compressed, for instance, ZIPs, GIFs and gzip encoded HTTP content.
- "Billion laughs attack" whereby XML entity expansion causes an XML document to grow dramatically during parsing. Set the XMLConstants.FEATURE_SECURE_PROCESSING feature to enforce reasonable limits.
- Using excessive disc space.
- Inserting many keys with the same hash code into a hash table, consequently triggering worst-case performance (O(n 2 )) rather than typical-case performance (O(n)).
- Initiating many connections where the server allocates significant resources for each, for instance, the traditional "SYN flood" attack.
Rules regarding prevention of denial of service attacks resulting from resource exhaustion include:
- FIO03-J. Remove temporary files before termination
- FIO04-J. Release resources when they are no longer needed
- FIO07-J. Do not let external processes block on IO buffers
- FIO14-J. Perform proper cleanup at program termination
- IDS04-J. Safely extract files from ZipInputStream
- MET12-J. Do not use finalizers
- MSC04-J. Do not leak memory
- MSC05-J. Do not exhaust heap space
- OBJ52-J. Write garbage-collection-friendly code
- SER10-J. Avoid memory and resource leaks during serialization
- TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts
- TPS01-J. Do not execute interdependent tasks in a bounded thread pool
Concurrency-Related Denial of Service
Some denial of service attacks operate by attempting to induce concurrency-related problems such as thread deadlock, thread starvation, and race conditions.
Rules regarding prevention of denial of service attacks resulting from concurrency issues include:
- LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code
- LCK01-J. Do not synchronize on objects that may be reused
- LCK07-J. Avoid deadlock by requesting and releasing locks in the same order
- LCK08-J. Ensure actively held locks are released on exceptional conditions
- LCK09-J. Do not perform operations that can block while holding a lock
- LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy
- THI04-J. Ensure that threads performing blocking operations can be terminated
- TPS02-J. Ensure that tasks submitted to a thread pool are interruptible
- TSM02-J. Do not use background threads during class initialization
Other Denial of Service attacks
Additional rules regarding prevention of denial of service attacks include:
- ERR09-J. Do not allow untrusted code to terminate the JVM
- IDS00-J. Prevent SQL injection
- IDS06-J. Exclude unsanitized user input from format strings
- IDS08-J. Sanitize untrusted data included in a regular expression
- MSC54-J. Avoid inadvertent wrapping of loop counters
Precursors to Denial of Service
A number of additional rules address vulnerabilities that can enable denial of service attacks, but that are insufficient to cause denial of service on their own. These rules include:
- ERR01-J. Do not allow exceptions to expose sensitive information
- ERR02-J. Prevent exceptions while logging data
- EXP01-J. Do not use a null in a case where an object is required
- FIO00-J. Do not operate on files in shared directories
- NUM02-J. Ensure that division and remainder operations do not result in divide-by-zero errors
Bibliography
| [ Seacord 2015 ] |