Java Security   «Prev  Next»

Protecting Application Code

DOS Attacks

In the lecture we are going to look at preventing DOS Attacks. (Denial of Service Attacks)
See the following page for the Oracle Guidelines Oracle Guidelines

How DOS is initiated

A Denial of Service attack is usually accomplished by flooding the targeted machine or resource with superfluous requests, Internet temps to overload the system, thereby disrupting the service ability to handle legitimate requests from valid clients. Commonly affected resources are CPU cycles, memory, disk space, and file descriptors.
The goal in this instance is to identify situations that might lead to excessive resource consumption, either maliciously intended or inadvertently introduced by sloppy code. You can prevent attacks, by monitoring situations where it is known to occur, and putting limits on resource consumption.
The document specifies three guidelines as shown in the table below.

Guideline 1. Beware of activities that may use disproportionate resources. Excessive resource consumption can come in many forms.
  1. Decompressing zip, GIF, gzip files. Set limits on the compressed data size rather than relying upon compressed size or meta-data .
  2. Deserialization of Java Objects or XML objects.

3. XML/XSLT/XPath Code

  1. X path expressions may consume large amounts of memory
  2. Parsing XML document could lead to XML entity expansion causing dramatic growth, set a limit with XML constants FEATURE_SECURE_PROCESSING


XMLConstants 4.Review application code for these potential issues:
  1. Regular expressions to prevent catastrophic backtracking
  2. Integer overflow errors
  3. Detailed logging which may create excessive log files
  4. Infinite loops: Check that loops make progress
  5. Too many keys inserted into hash table, turning an algorithm of O(n) into O(n2).

Guideline 1

Release resource in all cases. Important Points: Files, locks and manually allocated memory require every acquire operation to be paired with a definite release. When exceptions occur, it can be difficult to determine if the release occurred.
  1. Use the try-with resources syntax wherever possible
  2. Ensure that any output buffers are flushed when output was successful
  3. Code inside of the try statements (or finally block) could indefinitely block while attempting to access a resource. Review with care or use timeout feature .

Guideline 2:

Resource limit checks should not suffer from integer overflow. Some operations on primitive Integral Types silently overflow.
1. Java SE 8 introduce the java.lang.Math class which contains methods that throw an ArithmeticException if the result overflows the given type.

Protecting the Application
Moving on to Accessibility and extensibility, the goal here is to protect application code by reducing the “attack surface”, limiting what is exposed with stricter access privileges, and preventing code from being extended.
Some of the Java object oriented features you have grown to enjoy (inheritance and evolving interfaces) come ripe with security risks. You may need to adjust your design in some cases.
Guideline 3:
Limits the Accessibility of classes, interfaces , methods and fields.
Important Points:
  1. Declare a members private or package-private to avoid exposing the implementation, remembering however that classes loaded by different class loaders do not have package private access to one another.
  2. It is recommended that packages are marked as sealed in the jar file manifest.

Guideline 4:

Limit the Accessibility of packages 1. Add package.access security property to containers to further hide implementation. This can be done programmatically.

Guideline 5:

Isolate unrelated code:
Important Points:
  1. You can apply security checks on direct access to some code, but you cannot prevent indirect access through the use of the system classloader in thread context class loader.
  2. Beware of mutable statics.
  3. Library code should be carefully written such that it is safely usable by less trusted code.

Guideline 6:

Limit exposure of ClassLoader instances. Allowing access to ClassLoader instances has these undesirable effects
  1. Access to classes that client code would deny
  2. Possible leak of secure information in the URL's of resources
  3. The instance may be cast to a subclass, see next point.

Guideline 7:

Limit the extensibility of classes and methods.
Design classes and methods for inheritance or declare them final.
  1. A class or method that is not final is a candidate for a malicious attack through overriding.
  2. A final class is easier to implement and verify that it is secure.
  3. Prefer composition to inheritance.
  4. Class instances are scoped by their class name AND the class loader that defined the class, confirming an object’s class loader that defined the class, confirming an object's class type by just using Class.getName may not be sufficient.

Guideline 8

Understand how a superclass can affect subclass behavior.
Important Points: Even if it is a class overrides all inherited methods, a superclass can still affect subclasses behavior by introducing a new method which can lead to security vulnerabilities. This includes classes that implement interfaces .
  1. Malicious subclasses may implement java.lang.Clonable and create a clone of the victim object creating a shallow copy with different locks and fields, but reference to objects will be the same type.
  2. For a security sensitive class, all interfaces implemented by the class and it's subclasses) needs to be monitored for interface evolution by the addition of default methods.
In this module, I covered at a high level that the two topics related to protecting the application code from excessive resource consumption and unintended accessibility and extensibility.