POST data preservation
Use POST data preservation in environments where clients submit form data, and have short-lived sessions.
When POST data preservation is enabled, and an unauthenticated client posts data to a protected resource, the agent stores the POST data temporarily, and redirects the client to the login screen. The data can be any POST content, such as HTML form data or a file upload. After successful authentication, the agent recovers the stored POST data, and automatically submits it to the protected resource.
The following image shows a simplified data flow, when an unauthenticated client POSTs data to a protected web application:
Web Agent guarantees the integrity of the data, and the authenticity of the client as follows:
-
An unauthenticated client requests a POST to a protected resource.
-
The agent stores the POST data temporarily in the directory defined by POST Data Storage Directory, and saves data about the request in a standard pre-authentication cookie.
-
The agent sets a pre-authentication cookie in the browser, and redirects to the
/authorizeendpoint in AM. -
The client authenticates with AM.
-
AM sends an authentication response to the registered redirect URI.
-
The agent retrieves the original application URL from the pre-authentication cookie, and replays the request with its body content to the server. The authentication response includes an OIDC token, which the agent sets as a secure cookie in the browser.
-
The agent sends a self-submitting form to the client browser, that includes the form data the user attempted to post in step 1. The self-submitting form POSTs to the protected resource.
For information about configuration properties, refer to POST data preservation.
Security considerations for 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.
Defend against CSRF attacks when using POST data preservation
|
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. |
