Threats
The following sections describe some possible threats to Java Agent, which you can mitigate by following the instructions in this guide.
Out-of-date software
Prevent the exploitation of security vulnerabilities by using up-to-date versions of the agent and third-party software.
Review and follow the Ping Identity security advisories. Follow similar lists from all of your vendors.
Cached pages in browsers and web proxies
When browsers and web proxies cache pages that are accessed by a user, the cache can include sensitive information. Caching pages in browsers and web proxies increases risk of unwanted disclosure, especially in shared browsing environments.
Similarly, when web server responses are cached, sensitive information can be accessed by attackers. Caching web server responses is a common method to improve loading times and reduce server load.
To manage caching, set Custom Response Header Map so that HTTP responses generated by the agent include the Cache-Control HTTP header. This header tells browsers and web proxies whether they can be cached. For example, clients can set the following value clear existing cache responses, force the cache to revalidate with the server, and prevent new responses from being cached:
org.forgerock.agents.response.header.map[Cache-Control]=max-age=0, no-store
In your decision to set this property, consider the impact on the performance of customer applications. Setting this property can reduce performance because browser pages are not cached.
For more information about caching, refer to HTTP caching.
Reconnaissance
The initial phase of an attack sequence is often reconnaissance. Limit the amount of information available to attackers during reconnaissance, as follows:
-
Avoid using words that identify Java Agent in error messages.
When AM is not available, the related error message contains the agent profile name. Consider this in your choice of agent profile name.
-
Configure Agent Debug Level to use the lowest level of logging necessary. For example, consider logging at the
ERRORorWARNINGlevel, instead ofTRACEorMESSAGE. -
In custom login redirects, calls to the custom login URL include the parameter Login Reason Parameter Name to indicate why authentication is required, such as
NO_TOKENandTOKEN_EXPIRED. To reduce the risk of leaking useful information, use alternative strings for the authentication reason, by configuring Login Reason Value Map.
Cross-site scripting
|
Cross-site request forgery attacks (CSRF or XSRF) can be a cause of serious vulnerabilities in web applications. It is the responsibility of the protected application to implement countermeasures against such attacks, because Java Agent cannot provide generic protection against CSRF. Follow the latest guidance from the OWASP CSRF Prevention Cheat Sheet. When POST data preservation is enabled, captured POST data that is replayed appears to come from the same origin as the protected application, not from the site that originated the request. Therefore, CSRF defenses that rely solely on checking the origin of requests, such as SameSite cookies or Origin headers, are not reliable. Ping Identity strongly recommends using token-based mitigations against CSRF, and relying on other measures only as a defense in depth, in accordance with OWASP guidance. |
Configure the following properties to protect against cross-site scripting attacks:
POST data preservation
By default, POST data is stored in the in-memory cache. Consider the following points if you configure POST Data Preservation in Files or Cache to store POST data in the file system:
-
Payloads from unauthenticated users are stored in the agent file system. If your threat evaluation does not accept this risk, store the data in the cache, or set POST Data Preservation in Files or Cache to
false. -
Restrict access to the POST Data Preservation File Directory, to mitigate the risk of permissive access or leakage of personally identifiable information (PII).
-
Limit the amount of stored POST data to mitigate the risk of DoS attacks, by configuring POST Data Preservation Storage Size or Max Entries in POST Data Preservation Storage.
-
Remove expired POST data as soon as possible by configuring the POST Data Preservation Directory Sweep Interval.
-
Identify threats in POST data before it is deleted, by making sure that Intrusion Detection Systems inspect the data within the time specified by POST Data Preservation Directory Sweep Interval.
For information about configuration properties, refer to POST data preservation.
Compromised passwords
Use secure passwords for server administration.
For information about how to create the agent password, refer to Preinstallation tasks. The encrypted password is stored in the AgentPassword.properties file.
| Although the agent accepts any password length and content, you are strongly encouraged to generate secure passwords. This can be achieved in various ways, for example using a password manager or by using the command line tool agentadmin --key. |
Misconfiguration
Misconfiguration can arise from bad or mistaken configuration decisions, and from poor change management. Depending on the configuration error, features can stop working in obvious or subtle ways, and potentially introduce security vulnerabilities.
For example, if a configuration change prevents the server from making HTTPS connections, many applications can no longer connect, and the problem is detected immediately. However, if a configuration change allows insecure TLS protocol versions or cipher suites for HTTPS connections, some applications negotiate insecure TLS, but appear to continue to work properly.
-
Access policy is not correctly enforced.
Incorrect parameters for secure connections and incorrect Access Control Instructions (ACI) can lead to overly permissive access to data, and potentially to a security breach.
-
The server fails to restart.
Although failure to start a server is not directly a threat to security, it can affect service availability.
To guard against bad configuration decisions, implement good change management:
-
For all enabled features, document why they are enabled and what your configuration choices mean. This implies a review of configuration settings, including default settings that you accept.
-
Validate configuration decisions with thorough testing.
-
Maintain a record of your configurations and the changes applied.
For example, use a filtered audit log. Use version control software for any configuration scripts and to record changes to configuration files.
-
Maintain a record of external changes to the system, such as changes to operating system configuration, and updates to software, such as the JVM that introduces security changes.
Unauthorized access
Data theft can occur when access policies are too permissive, and when the credentials to gain access are too easily cracked. It can also occur when the data is not protected, when administrative roles are too permissive, and when administrative credentials are poorly managed.
Poor risk management
Threats can arise when plans fail to account for outside risks. To mitigate risk, develop appropriate answers to at least the following questions:
-
What happens when a server or an entire data center becomes unavailable?
-
How do you remedy a serious security issue in the service, either in the Java Agent software or the connected systems?
-
How do you validate mitigation plans and remedial actions?
-
How do client applications work when the Java Agent offline?
If client applications require always-on services, how do your operations ensure high availability, even when a server goes offline?
For critical services, test expected operation and disaster recovery operation.
Denial of service
To prevent memory exhaustion DOS attacks, configure Maximum Decompression Size to limit the maximum size to which a compressed JWT can be decompressed. This property reduces the risk of a decompressed JWT consuming too much available memory.
Log overflow attacks
To prevent log overflow attacks, add a custom agent-logback.xml with a
DuplicateMessageFilter. This filter detects duplicate messages,
and after the specified number of repetitions, drops repeated messages.
For more information, refer to
Limiting repetitive log messages.