Running Web-Scanning Tools


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.

Preparing Your Oracle E-Business Suite System for the Web Scan

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 suggested values for the profile options.

Suggested Profile Option Values for Preparing Your Oracle E-Business Suite System for the Web Scan
Profile Option Profile Option Name Suggested
Utilities:Diagnostics DIAGNOSTICS No
Framework Validation Level FRAMEWORK_VALIDATION_LEVEL Error
Restrict Text Input FND_RESTRICT_INPUT Y
Attachment File Upload Restriction Default FND_SECURITY_FILETYPE_RESTRICT _DFLT N (allowlist)

My Oracle Support Knowledge Document 946372.1, Secure Configuration of E-Business Suite Profiles, describes the Diagnostics and Validation profiles in more detail.


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.


Setting these to "Error" increases security by signing and validating many of the parameters that are not supposed to be modified on the client.


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.


Setting this to "N" enables an allowlist of authorized file extensions, rather than the default blocklist specified by "Y".

Reviewing the Results

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.

Reflected XSS and Header Splitting

The tools are generally very good at finding these types of vulnerabilities and most reported issues are actual issues.

Stored XSS

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 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.

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.

Sample Code Installed

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.