I’m just about finished with the ApexNinja blogging platform (v2) that I plan on releasing together with all the sources somewhere next week. Fortunately I met up with security experts Tim and Nathan from Recx (http://www.recx.co.uk/) during the UKOUG APEX SIG Meeting in London, where I did a presentation on APEX Printing Techniques (http://www.ukoug.org/events/5642-apex-sig-meeting/). And these guys, being really friendly and awesome, offered to use their APEX security analysis tool to check out my blog platform, before I release it on the wild and cause all its potential users some serious harm.
Long story short, after they sent me the security report, I realized there are some security best practices for developing APEX applications that I haven’t really followed and generated some vulnerabilities in my applications. And also understood why a tool like ApexSec is a must-have for every APEX development team, no matter how experienced it (thinks it) is.
First of all, you can find all the details about the ApexSec Security Console here: https://secure.recx.co.uk/apexsec/index.jsp. Although this is not a free application, Recx does offer free analysis by uploading the sources of your APEX app to Recx’s online interface here: https://secure.recx.co.uk/apexsec/upload.jsp. You will get back an HTML report together with an XML project, that you can upload and drill down more easily in the security report, by downloading the free version of the Apex Security Console, here: https://secure.recx.co.uk/apexsec/download.jsp?code=free. For paid subscriptions, you don’t need to submit your precious apps to Recx, instead the tool can connect directly to your database and generate the security reports from there.
Just to give you an idea on how the application looks like, here’s a screenshot:
What security issues I found and had to fix:
In my opinion there are two "must read" articles concerning Oracle APEX. The first, a very interesting overview of the APEX architecture, by Dr. Paul Dorsey at Dulcian Inc.: http://www.dulcian.com/papers/ODTUG/2009/2009_Dorsey_APEX.htm.
The main points to follow in this article:
– APEX is the spark between the PLSQL HTP package and the mod_plsql Apache module. APEX is stored entirely in the database and the web pages are generated using the HTP package and the mod_plsql Apache module. Simple as that!
– APEX does not currently have what we traditionaly call a model layer. A model layer is used to temporary store data between multiple web pages, as required by a stateless web application. The mode-view-controller stored the state of each web page and does a commit just "at the end", resulting in a insert/update/delete. APEX does not have this. The workaround is the items and collections. Not so frequently used, APEX collections (
apex_collection) will soon be a must for all complex applications with forms spreading across multiple pages.
The second article is a whitepaper about Hardening and Hacking Oracle XE. The minuses of APEX applications that use Oracle XE db are mainly found in the database. Oracle does not offer support for free products and patches are sparse and sometimes hard to get, if you don't have a metalink account. Proud of your XE database? Think again: it's missing most of the security patches applied to the SE versions…
This article describes some considerations about how APEX authorization works and describes ways of building authorization schemes and applying the defined authorization schemes to pages or objects within a page.
After creating an APEX application, if the application is accessed by multiple users that have multiple roles or rights and you want to find a way to limit their access to the pages and objects that they are allowed to view then authorization schemes are the answer. You can limit the users' access to pages, tabs, lists or pretty much any object within the regions of the page.
This article describes some considerations about how APEX authentication works and describes a possible way of building your own authentication politics.
When you create a new APEX application, along with the pages that you add in the application creation process, APEX automatically creates a login page with the number 101. Also in the application creation process the user can chose one of the three options: Application Express, No authentication and Database account. It is not really that important the choice, as it can be modified afterwards at any point, and for example the Application Express scheme can be basically modified to act just like any of the other two.