فا

‫ Java Secure Coding - Denial of Service

IRCAR201306177
Date: 25/06/2013
Denial of service attacks attempt to make a computer resource unavailable or insufficiently available to its intended users. Such 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.
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
· 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
· VNA03-J. Do not assume that a group of calls to independently atomic methods is atomic
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. Sanitize untrusted data passed across a trust boundary
· IDS06-J. Exclude user input from format strings
· IDS08-J. Sanitize untrusted data passed to a regex
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. Never dereference null pointers
· FIO00-J. Do not operate on files in shared directories
· NUM02-J. Ensure that division and modulo operations do not result in divide-by-zero errors
Related Topics:

نظرات

بدون نظر
شما برای نظر دادن باید وارد شوید

نوشته

 
تاریخ ایجاد: 18 مرداد 1393

دسته‌ها

امتیاز

امتیاز شما
تعداد امتیازها: 0