Databases Reference
In-Depth Information
Each request to an APEX page is passed from the web server to the database via either ModPLSQL or the
APEX Listener. The APEX engine resides in the Oracle database instance, hence a database connection
remains open for the duration of the time that the APEX engine generates the page. Each page that is
concurrently being built requires an open database connection. Hence, the count of database
connections during DoS, intentional or not, will go up significantly. This can greatly impact other
applications that may use the same database.
End users and the infrastructure will have varying experiences depending on the architecture
supporting the APEX installation. When using Oracle Web Cache in front of the web server, Apache will
limit the number of connections from Web Cache to Apache to the value of the Apache directive
MaxKeepAliveRequests (default 100). This in turn limits the number of connections from Apache to the
database to the same value. Under this circumstance the database will typically run without significant
problems, assuming 100 active connections is not sufficient to overwhelm it. In this case, requests will
stack in the Web Cache as it waits for a connection to Apache. Eventually these requests will wait beyond
the Web Cache max wait time and users will experience a Web Cache error: No Response from
Application Web Server (see Figure 8-13).
Figure 8-13.
Oracle Web Cache error when it cannot communicate with Apache
Without Oracle Web Cache or some other limiting mechanism, though, Apache will continue to
establish connections to the database until either Apache or the database is overwhelmed and no longer
accepts connections. In this case some users will experience a browser that just waits, while others may
get a message that the browser is unable to connect to the web server at all.
In the case of malicious DoS attacks, each request to the server is probably anonymous, that is, it
does not have an established APEX session. The APEX activity log will have a list of page requests with
associated IP addresses. An APEX administrator can query this log or the Apache access log to determine
the IP address of the offender. The same is true for the non-malicious spiral-bound notebook or
impatient user. There are additional symptoms in this case, though. Because the request is likely to be
for the same page, and for a logged-in user with an established session, the page request will almost
certainly be setting some data into session state. Assume the page takes 7 seconds to build. The user puts
down a spiral notebook, inadvertently pressing the enter key, and walks away. The first request hits
Apache, gets routed to mod_plsql and gets a database session from the pool. Then the next request (.05
second later) comes in to Apache, then to mod_plsql, then gets a different session from the pool
(because the first page is not done building), but this page is blocked by the update of the
wwv_flow_data session state from the first page request. Now repeat this every twentieth of a second,
and in 7 seconds there are 140 open sessions to the database, all being blocked by that first one. Before
long this will cause a great number of sessions to be blocked by a single statement, the statement
updating
wwv flow data
session state:
UPDATE WWV FLOW DATA SET ITEM VALUE = :B6 || ':' || :B5 || ':' || :B4 || ':' || :B3 WHERE
FLOW INSTANCE = :B2 AND ITEM ID = :B1
And each of the blocked sessions will have the same session
client identifier
, which will include
the username and APEX session ID of the user flooding the system with requests. The following query
will give you a list of active sessions by user and session:
