Hi @Srinivas_Opti ,
To address the Fortify scan issues you're encountering in AEM 6.5, let's break down the solutions for each of the issues:
1. Error Logging (Sink: org.slf4j.Logger.error())
Fortify is flagging the logging as a potential security issue because logging sensitive information can lead to information leakage. Here are some best practices to follow for secure logging:
- Avoid logging sensitive information: Ensure you are not logging sensitive data such as passwords, personal information, or detailed error messages that could be useful to an attacker.
- Log Exceptions Securely: When logging exceptions, avoid logging the full stack trace directly. Instead, log a unique error identifier and handle the detailed logging securely.
Example Solution
Instead of logging the exception message directly, you could log a generic error message and the exception's stack trace separately, ensuring you do not expose sensitive details.
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class YourClass {
private static final Logger log = LoggerFactory.getLogger(YourClass.class);
public void yourMethod() {
try {
// Your code here
} catch (CryptoException e) {
log.error("An error occurred while processing the request: {}", e.getMessage()); // Avoid this pattern
log.debug("Detailed error: ", e); // Use debug or trace level to log the stack trace
}
}
}
In this approach:
- The log.error statement provides a generic message, avoiding exposure of sensitive details.
- The log.debug statement logs the detailed exception stack trace at a lower log level (debug), which can be disabled in production environments.
2. Hidden Field Issue in HTML
Fortify is flagging the hidden input field because hidden fields can be manipulated by attackers. Hidden fields should not contain sensitive data. To resolve this, ensure that hidden fields are used securely and consider server-side validation.
Example Solution
- Avoid storing sensitive data in hidden fields.
- Validate all input, including hidden fields, on the server-side to ensure they haven't been tampered with.
For instance, if you need to include a hidden field in your form, ensure that it does not contain sensitive information and always validate it on the server-side:
<form action="/submit-form" method="post">
<!-- Non-sensitive hidden field -->
<input type="hidden" name="nonSensitiveParameter" value="12345" />
<!-- Other form fields -->
<input type="submit" value="Submit" />
</form>
On the server-side, validate the hidden field value:
protected void doPost(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
String hiddenFieldValue = request.getParameter("nonSensitiveParameter");
// Validate the hidden field value
if (hiddenFieldValue != null && hiddenFieldValue.matches("\\d+")) {
// Process the form
} else {
// Handle invalid input
response.sendError(HttpServletResponse.SC_BAD_REQUEST, "Invalid input");
}
}
By ensuring hidden fields are used appropriately and validating them on the server-side, you can mitigate the security risks flagged by Fortify.
Error Logging:
- Avoid logging sensitive information.
- Log exceptions with a generic message and use debug level for detailed stack traces.
Hidden Field:
- Do not store sensitive data in hidden fields.
- Validate hidden field values on the server-side to ensure they haven't been tampered with.
Implementing these best practices should help resolve the issues flagged by Fortify in your AEM 6.5 environment.
