Code-Racing / brickyard

0 stars 0 forks source link

CONTRAST: Hardcoded Password in SpringInputPasswordFieldAttrProcessor.java #99

Open valvolineford opened 4 years ago

valvolineford commented 4 years ago

Vulnerability ID: 5P0R-KP7P-RH41-JSTB

Application Name: apple

Application Code: AAPL

Vulnerability Link: http://localhost:19080/Contrast/static/ng/index.html#/7c6cfec5-a187-4d5e-984a-d11d96d2ef63/applications/3c77ce97-6b6e-4335-ba9c-cba8465cae64/vulns/5P0R-KP7P-RH41-JSTB

What Happened?

The "PASSWORD_INPUT_TYPE_ATTR_VALUE" field in SpringInputPasswordFieldAttrProcessor.java (org.thymeleaf.spring4.processor.attr.SpringInputPasswordFieldAttrProcessor) looks like a hardcoded password:

public static String PASSWORD_INPUT_TYPE_ATTR_VALUE = "[hidden]";

What's the risk?

Hardcoded passwords are a dangerous practice for a few reasons.

First, having passwords in source code implicitly gives backend system access to anyone with access to the code repository or built binaries. Given the history of source code disclosure flaws in server software, and the possibility of compromise when using cloud-based source code repositories, assuming attacker access to your source code is a prudent philosophy.

Second, hardcoded passwords make responding to security events more difficult. If a backend password needs to be rotated, a new build must be elevated to compensate. If the value is pulled from a configuration file instead, the operations team can respond nearly instantaneously.

Recommendation

The password detected should be taken out of source code and made available via configuration management. An encrypted properties file like the one provided by ESAPI would allow the code to be taken out of the source code and be provided environment-specific values.

Alternatively, the value could be taken from System properties.

First Event

(no event)

Last Event

(no event)

HTTP Request

(No HTTP Request)

References

https://www.securecoding.cert.org/confluence/display/java/MSC03-J.+Never+hard+code+sensitive+information