Threats
The following sections describe some possible threats to Web 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 Add Cache-Control Headers so that HTTP responses generated by the agent include the Cache-Control HTTP header.
When the Cache-Control HTTP header is present, the response cannot be cached.
The header uses
the following values: max-age=0, no-cache, no-store, must-revalidate.
If you need the Cache-Control header for each page, set it in the application or in the web server.
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, see 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 help to identify Web 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.
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 Web Agent cannot provide generic protection against CSRF. ForgeRock recommends following 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. To defend against CSRF attacks when POST data preservation is enabled, the agent uses a secure cookie and a nonce. The nonce must correspond to the authentication response from AM. This defense during authentication is specified in Cross-Site Request Forgery. ForgeRock strongly recommend using token-based mitigations against CSRF, and relying on other measures only as a defense in depth, in accordance with OWASP guidance. |
For more protection against cross-site scripting attacks, configure Composite Advice Encode.
POST data preservation
POST data is stored temporarily in the agent file system before a user is authenticated. Therefore, any unauthenticated user can POST a file that is then stored by the agent. Consider the following points when you configure POST data preservation:
-
Payloads from unauthenticated users are stored in the agent files system. If your threat evaluation does not accept this risk, do not use POST data preservation; set Enable POST Data Preservation to
false. -
By default, POST data is stored in the installation log directory,
/path/to/web_agents/agent_type/instances/agent_n/log. Although the log directory is considered secure, using it for POST data can cause the following risks:-
Permissive access to POST data.
Log directories can have relatively permissive read or copy permissions compared to other directories.
-
Leakage of personally identifiable information (PII).
If POST data in log directories is processed by log applications, it could be included in a log view.
To store POST data in a dedicated directory, set POST Data Storage Directory.
-
-
POST data is stored for the time defined by POST Data Entries Cache Period and then deleted. To identify threats in POST data before it is deleted, make sure that Intrusion Detection Systems inspect the data within the specified time.
For information about configuration properties, see POST data preservation.
Compromised passwords
Use secure passwords for server administration. For information about how to create the agent profile password, see Preinstallation tasks.
| 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, by using a password manager. |
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 Web Agent software or the connected systems?
-
How do you validate mitigation plans and remedial actions?
-
How do client applications work when the Web 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.