A brief overview of OWASP top 10 risks and what it takes to minimize them in java.(Part -3)

Insecure direct object references is a common form of risk associated with sensitive information. Just by iterating through some input data an attacker can retrieve sensitive data if a web site is having insecure direct object references.

Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw.

An attacker, who is an authorized system user, simply changes a parameter value that directly refers to a system object to another object the user isn’t authorized for.

1. Implementing proper access controls is the primary defence mechanism used against insecure direct object reference attacks.
2. Using indirect references for internal data without exposing the internal keys.
3. Avoid using predictable keys where applicable. ( eg: bank account id’s)

Implementing a mechanism like hashing can prevent the actual values being exposed in the presentation layer.

The OWASP ESAPI AccessReferenceMap interface is used to map from a set of internal direct object references to a set of indirect references.

5 Security Misconfiguration

Security misconfigurations cover a broad domain of risks. It is commonly seen in many of the exploits since it is easy to exploit.

The basic form of attack is an attacker discovering and gaining access into an insecure resource. Following are some reasons which leads to attackers exploiting weaknesses in security misconfigurations.

1. Usage of software without being updated properly.
2. Unnecessary features being enabled or installed.
3. Using default account usernames and passwords.
4. The error handling revealing stack traces or other overly informative error messages to users.
5. The security settings in development frameworks (e.g., Struts, Spring) and libraries has not been set to secure values.
6. Turning off or choosing not to install the features which are not needed and applying the principle of “least privilege [3] “
7. Changing the security configurations as necessary and not using the default security configurations which are known to everybody.
8. Making sure the packages used are up to date.

Proper error handling and not exposing error information which can inreturn be traced back to implementation of the system and its vulnerabilities can be a useful weapon.

Detailed error handling, where inducing an error displays too much information, such as stack traces, failed SQL statements, or other debugging information.

Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user.

The finally method is guaranteed to always be called. The finally method can be used to release resources referenced by the method that threw the exception. This is very important. An example would be if a method gained a database connection from a pool of connections and an exception occurred without finally the connection object shall not be returned to the pool for some time (until the timeout). This can lead to pool exhaustion. finally() is called even if no exception is thrown.

3. configure an exception handler in the web.xml configuration file.

This is a very simple solution to handle any subclass of java.lang.Throwable (which covers all types of exceptions) that gets bubbled up through the application, whether by a servlet, jsp, or some framework specific code and preventing the user from seeing it.

What it will do then is redirect the user for any previously unhandled exception it catches to /error.jsp. This page should have some generic text on it stating that an error occurred, and should not give specifics as to what that error is.

Up next : Sensitive Data Exposure 🙂

Originally published at http://neatrick.wordpress.com on September 29, 2015.