APEX Security vulnerabilities Oracle Tips by Burleson Consulting

Because APEX openly passes screen values between screens (see passing values between APEX screens), we need to ensure that a malicious end-user does not have the ability to "snoop" on other values by changing the literal values.  The URL page variable data can also be protected by using page computations in lieu of passing them in the URL. Remember, session state is "global" for an application and one page can set the session state for another pages page items.

All of these APEX security exposure vulnerabilities can be avoided by careful configuration, but there are many potential security exposures to consider.  There are several areas of potential APEX exposure:

• Search Engine vulnerability - If a search engine indexes an Oracle APEX web site, URL's with exposed data values become public.

• Referrer statistics exposure - If an APEX end-user clicks away from an APEX screen, the referrer URL might send data values to the destination web site.

• Hoover Bots - People can write scripts to replicate APEX transactions, vacuuming out all exposed Oracle data. 

• URL Tampering - With improper configuration, end-users can alter their APEX URL and see data outside the scope of the APEX application.

Search Engine Vulnerabilities

If Google indexes your APEX database you may expose confidential data to the public.  We can see all APEX pages with the Google "inurl:" search feature to only show Google results where the URL contains the string "f?p=". 

The Google query to find pages with data exposures might look like this Google query that shows unintended Oracle database values within the URL.  The exposure is not just limited to Google as many search engines (especially malicious bots) will not honor "nofollow" tags in the pages.  The DBA must be always vigilant to ensure that all APEX details are placed in password secured directories, unavailable to any search engine.  Permissions like 700 or 770 on the inodes (directories) will take care of this exposure.  For related details, see Finding APEX Hacking vulnerabilities with Google.

Referrer Statistics exposures

Referrer statistics are sent as part of an HTTP request, and there is the possibility that an end-user who navigates directly from their APEX screen will send unencrypted data values to the destination web site.  This is especially prevalent if the end-users have fast-access toolbars in their browser, such as the Google Toolbar.

Hoover Bots

Any al all data exposed via an APEX application can be hoovered off into another Oracle database.  For details, see superb this article on how someone hoovered megabytes from Amazon's Oracle database.

“Using a pair of 5-year-old computers, two home DSL connections, 42 hours of computer time, and 5 man hours, I now had documents describing the reading preferences of 260,000 U.S. citizens.  I downloaded all the files to an external 120 GB Firewire drive in UFS format."

APEX URL Tampering

From this excellent APEX best practices security whitepaper we see that URL tampering can work:

"Web based applications, including those developed in Oracle HTML DB often pass values from one page to another through a URL. A clever enough user may observe this and override a value by typing his own value in the location field of his browser. For example, on a page that displays a form for editing an employee record the value in session state of a certain item may determine which record is displayed In HTML DB, the session state of this item can be set in the URL containing the following:

f?p=&APP_ID.:1:::::P1_EMPID:1234

Where 100 is the application ID, 1 the page ID, P1_EMPID the session state variable and 1234 represents a primary key value in a table of employees. When a user clicks on such a link it will appear in the browser’s location field. At this point the user can experiment and modify the URL into:

f?p=&APP_ID.:1:::::P1_EMPID:5678

in the hope of retrieving the employee record with the primary key value 5678. The user in question may or may not be allowed to look at the details for employee 5678. If she is not allowed, appropriate authorization rules should be applied to the logic on the page and, even better, at the database level to prevent her from viewing this data. Obscuring the value passed in the URL through a form of encoding or encryption is not sufficient. Put another way, don’t attempt to secure your application by obscuring values passed in a URL. Rather, secure the destinations that URLs go to using database level security policies.

In addition, you can use HTML DB authorization schemes. Cross Site Scripting Cross site scripting, sometimes called XSS, is a security breach that takes advantage of dynamically generated Web pages. "

The URL page variable data can also be protected by using page computations in lieu of passing them in the URL, and all variables are available via the application global session state. Here is an excerpt from the book "Easy Oracle HTML-DB Application Express " discussing creating Page Processing Computations.

Computation Locations

The computation locations identifies where the page item is located that will be set by the computation.

• Item on This Page – Used to set the value of a single item on the current application page.

• Item on Another Page – This type of computation is useful when you want you are navigating to another page and you want to set page items on that page. Using this method you can hide the values by not having to send them in the URL. The limitation of using this method is the page would not provide a URL for the user to save in the browser as a Favorite (such as a sale item on your web site).
   

APEX support:

For APEX development support just call to gat an Oracle Certified professional for all APEX development projects.

APEX book and code samples:

Easy Oracle HTML-DB Application Express Create Dynamic HTML with Oracle Includes online APEX code depot Buy it now for 30% off - Only $27.95