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.
Learn more in 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 isn’t 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. Ping Identity 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. 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. |
For more protection against cross-site scripting attacks, configure Composite Advice Encode.
Client IP addresses
The agent doesn’t have access to client side IP addresses at the TCP/IP level. Instead, it accesses client IP addresses from the address of the last proxy or client.
You can change the HTTP header used to identify the client IP address by
setting the Client IP Address Header
property. If you set this property, make sure you use a trusted header. For example, there are
security and privacy concerns associated with using the X-Forwarded-For HTTP header. Learn
more in the MDN Web Docs X-Forwarded-For.
Security issues can occur if the client IP address is spoofed, particularly if the spoofed IP address is included in a not-enforced rule. Learn more about IP spoofing in OWASP’s IP Spoofing via HTTP Headers.
To protect your deployment, you should only set the Not-Enforced IP List and Not-Enforced URL from IP Processing List properties if you have considered the risks of client IP address spoofing and mitigated for them. Typically, you would only specify IP addresses from a private network that you have control over.
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 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 directory,
/path/to/web_agents/agent_type/instances/agent_n/pdp-cache. To store POST data in a dedicated directory, set POST Data Storage Directory. Make sure that the new directory has the correct read/write permissions for the ID that the server uses. -
Set the directory permissions to minimize the following risks:
-
Permissive access to POST data.
-
Leakage of personally identifiable information (PII).
-
-
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 Intrusion Detection Systems inspect the data within the specified time.
Learn more in POST data preservation.
Compromised passwords
Use secure passwords for server administration. You can find information on creating the agent profile password in 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 isn’t 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 isn’t 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.
Path traversal attempts
Some Java servers, such as those based on J2EE and Spring, use path parameters (also known as matrix parameters) in URL paths. These servers can process requests in a non-standard way that is unsafe for the agent forwarding the request. As a result, bad actors can make use of these parameters for path traversal attempts to access protected resources.
The agent requires the URL path to be normalized consistently to be able to effectively enforce rules.
Web Agent rejects unsafe uses of path parameters with an HTTP 400 in the following scenarios:
-
The request contains one or more
%2For%2f(encoded forward slash) characters in the path parameters. -
The request contains one or more
%5Cor%5c(encoded backslash) characters in the path parameters on a Windows server. -
The request includes empty path segments or dot path segments with path parameters. Some example unsafe uses include:
-
/;/ -
/..; -
/.; -
/..;parameter/
Legitimate uses of
;as a path parameter are still permitted. For example, the agent won’t reject this request with thejessionidparameter:/segment1/segment2/;jsessionid=1234 -
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 isn’t 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.