Java Developer Tools

Audit - Rules - Authentication

Description
This group contains audit rules that look for opportunities where malicious users may be able to gain access not intended by the application.

Rules:

Details

Anonymous Authentication in LDAP

Summary
Enforces authorized access to LDAP.

Description
This audit rule finds places where the Context.SECURITY_AUTHENTICATION property is set to "none", resulting in an anonymous binding.

Security Implications
When LDAP data is accessible with anonymous authentication, a malicious user can have access to information that would otherwise be inaccessible.

Example
The following method invocation would be flagged as a violation because it results in an anonymous bind:

    env.put(Context.SECURITY_AUTHENTICATION, "none");

Authentication By Hostname

Summary
Do not use hostnames to authenticate users.

Description
This rule looks for places where the method getCanonicalHostName() is used in a condition.

Security Implications
When security decisions are made based on trusting certain hostnames, DNS cache poisoning attack can be used to access secured parts of an application.

Example
The following check would be flagged as a violation because the decision is made based on a host name:

    if (addr.getCanonicalHostName().endsWith("trustme.com")) {
        trusted = true;
    }

Base64-Encoded Password

Summary
A password protected with a trivial encoding is as easy for an attacker to read as a plain text one.

Description
This audit rule violates all the usages of Base64 encoding to decode passwords.

Security Implications
Base64 is a common, familiar and easily decrypted encoding. Using it for password encoding provides no real protection. You should use more strong encodings instead.

Example
The following code will be marked as a violation because it uses Base64 to decode a password read from a file:

    String password = props.getProperty("password");
    byte[] decodedPassword = Base64.decodeBase64(password.getBytes());

Blank Password

Summary
Blank passwords are a security threat that can be used by an attacker to access secure information.

Description
This audit rule violates blank password properties in a property files.

Security Implications
A blank password is usually the first one to be tried when trying to guess or brute-force a password protection. It should never be used.

Example
The following entry in the property file will be marked as a violation because it declares a blank password:

    invalidPassword=

Hardcoded Password

Summary
Passwords should not be hardcoded.

Description
This audit rule violates any instance where a hardcoded password is passed to java.util.Properties or java.sql.DriverManager. If a such a password is found, and it is also empty, a violation is thrown to create a password.

Security Implications
When a password is hardcoded in an application, not only can other developers see the password, but the password can also be extracted from the java byte code.

Example
The line "properties.setProperty("password", "somePassword");" would be flagged as "somePassword" is a hardcoded password.

    Properties properties = new Properties();
    properties.setProperty("user", "someUserName");
    properties.setProperty("password", "somePassword");
    DriverManager.getConnection(..., properties);

Password in File

Summary
Storing passwords in a configuration file is a security risk.

Description
This audit rule violates all instances of the password retrieval from a property file.

Security Implications
Storing passwords in a configuration file can provide an attacker with the data that can be used to access a protected resource.

Example
The following code retrieves password from a file and is thus marked as a violation:

    Properties props = new Properties();
    props.load(new FileReader("app.properties"));
    String password = props.getProperty("password");

Plain Text Password

Summary
Storing passwords as plain text makes them easily accessible by an attacker.

Description
This audit rule violates all usages of an unencrypted password retrieved from a property file.

Security Implications
Storing passwords in a configuration file as plain text can provide a malicious user or an attacker with a password that can be later used to access secured data. Passwords should be stored in an encoded state and decoded using some strong encryption algorithm.

Example
The following code retrieves a password from a file and uses it directly to access a database without decoding. It is thus marked as a violation:

    Properties props = new Properties();
    props.load(new FileReader("security.properties"));
    String username = props.getProperty("username");
    String password = props.getProperty("password");
    Connection c = source.getConnection(username, password);

Redirected With Password

Summary
Passwords should not be passed in redirect URLs.

Description
This audit rule violates usage of a password in the construction of a HTTP GET request URL.

Security Implications
Sending redirect to the browser will result in a HTTP GET request. Because the GET request is not considered to be security-sensitive data, it will be easily accessible - it could be sniffed, logged by a proxy, or by an HTTP server itself. This adds more places that could be later used by an attacker to retrieve the password and the data it protects.

Example
The following code sends a password in the redirect and will be marked as a violation.

    resp.sendRedirect(req.getRequestURI() + "&myPassword=" + myPassword);

Use Of Broken Or Risky Cryptographic Algorithm

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.