E1: JAS: Enhancement Request for E1 to Protect Against Cross-Site Request Forgery Vulnerabilities
(Doc ID 2710451.1)
Last updated on JANUARY 03, 2023
Applies to:
JD Edwards EnterpriseOne Tools - Version 9.2 and laterInformation in this document applies to any platform.
Symptoms
EnterpriseOne relies solely on HTTP cookies or Basic Authentication to identify the user that issued a request, which basic authentication may leave it open to Cross-Site Request Forgery vulnerabilities.
If the application places session-related tokens elsewhere within the request, then it may not be vulnerable. The attacker can determine all the parameters required to construct a request
that performs the action. If the request contains any values that the attacker cannot determine or predict, then it is not vulnerable.
The most effective way to protect against CSRF vulnerabilities is to include within relevant requests an additional token that is not transmitted in a
cookie: for example, a parameter in a hidden form field. This additional token should contain sufficient entropy, and be generated using a cryptographic random number generator, such that it is not feasible for an attacker to determine or predict the value of any token that was issued to another user. The token should be associated with the user's session, and the application should validate that the correct token is received before performing any action resulting from the request.
An alternative approach, which may be easier to implement, is to validate that Host and Referer headers in relevant requests are both present and contain the same domain name. However, this approach is somewhat less robust: historically, quirks in browsers and plugins have often enabled attackers to forge cross-domain requests that manipulate these headers to bypass such defenses.
Changes
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
Symptoms |
Changes |
Cause |
Solution |
References |