Over the years, Oracle has run web scanning tools such as AppScan and WebInspect against Oracle E-Business Suite and a number of our customers have also submitted reports generated by these tools.
In this section we will share some of the experience we have gained through this process.
To get the best value of the effort you invest in the pen test, you should first secure your Oracle E-Business Suite instance as described in this document. In particular, you should ensure that the security settings that directly affect the web interface are set properly.
Refer to the following table and set the recommended values for the profile options.
| Profile Option Name | Code (Internal Name) | Recommended Value |
|---|---|---|
| Utilities:Diagnostics | DIAGNOSTICS | No |
| FND: Diagnostics | FND_DIAGNOSTICS | No |
| Restrict Text Input | FND_RESTRICT_INPUT | Y |
| Attachment File Upload Restriction Default | FND_SECURITY_FILETYPE_RESTRICT _DFLT | Y |
| FND: Disable Antisamy Filter | FND_DISABLE_ANTISAMY_FILTER | No |
My Oracle Support Knowledge Document 946372.1, Secure Configuration of E-Business Suite Profiles, describes the Diagnostics and Validation profiles in more detail.
FND_DIAGNOSTICS=N
If you set diagnostics to "Yes", you will receive numerous reported issues concerning "Information Leakage." This is because when in diagnostics mode, Oracle E-Business Suite will return stack traces to the client to help in diagnosing problems.
FND_RESTRICT_INPUT=Y
Setting this to "Y" activates the input scanner; the input scanner will check the input parameters for common malicious patterns and block the request if any are found.
FND_SECURITY_FILETYPE_RESTRICT_DFLT=N
Setting this to "N" enables an allowlist of authorized file extensions, rather than the default blocklist specified by "Y."
The web scanning tool attempt to find vulnerabilities of various types. In our experience the web-scanning tools excel at finding certain types of vulnerabilities and have less success with other types.
The tools are generally very good at finding these types of vulnerabilities and most reported issues are actual issues.
Finding these are much harder and generally the accuracy is lower than for Reflected XSS.
In the few cases we have seen the 'stored' claim was based on tainted input being carried between pages in a page flow, not necessarily in an 'executable page context' and certainly not stored in the database.
Tools tend to produce a high proportion of false positive for SQL Injections.
The most common reason for reported 'potential SQL Injections' is that the tool recognizes a database error code in the response and concludes that there might be a 'potential SQL Injection'.
The most common source of these 'database errors' is:
PL/SQL data type validation errors
JDBC connect errors
PL/SQL errors typically come from calling java or jsp URLs that call PLSQL APIs.
In this case, the server-side code is executing in the database and any error reported is likely to be "a database error." Typical errors are plsql data validation errors such as "buffer too small" and "that's not an integer" of the ORA-06502 family. Another source of error is "that string cannot be decoded", seen when messing with submitted cookie values.
These PL/SQL errors may be indicative of "Information Leakage" but they are not SQL Injections.
ORA-06502: PL/SQL: character string buffer too small
ORA-06502: PL/SQL: numeric or value error: number precision too large
ORA-06502: PL/SQL: numeric or value error: hex to raw conversion error
The JDBC connection errors are seen when the web scanning tool overwhelms the tested instance with a rapid fire of requests. In some cases the connection pool between the application tier and the database gets exhausted and no more database connections can be made. In this situation JDBC errors such as "read() returned -1" are thrown indicating that a database connection could not be made.
These errors may trigger the tool to report "potential SQL Injection" issues as the error stack includes reference to jdbc. Again a potential case of "Information Leakage" but not a SQL injection.
Oc4j, which is the servlet container used in Release 12.0 and 12.1, has the unusual feature that it just cannot say "no."
When it receives a request for a file that does not exist, it will always respond with a "200 OK" response with no content - the tool may have expected a "404 Not Found."
Web scanning tools that rely solely on the response status code will think that the file exists and not notice that there is no content served. This may cause the tool to report the presence of "Sample Code," "Known Bad files," or "Alternate Version of File" when no such files exist.
Note that "no content" may be indicated by a Content-Length: 0 header or if the Transfer-Encoding: chunked header is present the size of the first and only chunk will be 0.