"Do you know if Oracle or a third-party has verified how secure APEX is against threats or vulnerabilities? It would be nice to have something published saying how secure APEX is and how it’s never been compromised."Now I imagine smart people like David Litchfield or Pete Finnigan or Alexander Kornbrust would hope that I say something daft here. But that's not going to happen. As I replied to the partner:
Sorry, but this doesn't make sense, and for a couple reasons:
- There have been published security vulnerabilities in Application Express in the Oracle Critical Patch Update, and they have been fixed in subsequent releases of APEX. It is incorrect to say that there have never been bugs in APEX itself. Here's an example: http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html
- Secondly, even if APEX never had any security bugs in its existence, if someone built an APEX application which is susceptible to SQL Injection or cross site scripting, does that mean that APEX was compromised?
I can offer you the following:
- APEX 5.0.3 is the most secure version of APEX in our history.
- APEX 5.0.3 has more security features than any release of APEX in our history.
- We are never permitted to release any version of APEX with known security vulnerabilities, whether they are internally or externally filed.
- We routinely scan APEX itself for security vulnerabilities across a variety of threats, and do this for multiple times in a release cycle
- Oracle Database Cloud Schema Service runs APEX, and has endured yet another set of multiple rounds of Cloud Security testing.
- The Oracle Store runs APEX.
- APEX is used in countless military agencies and classified agencies around the globe.
- Even inside of Oracle, IT hosts an instance of APEX used by practically every line of business in the company, and it's cleared for the most strict information classification inside of Oracle.
- APEX is even used in the security products from Oracle, including Oracle Audit Vault & Database Firewall, Oracle Key Vault and Oracle Real Application Security.
My organisation recently deployed an APEX 5 application. Prior to release it was subject to penetration testing by a third party. Not only did the testing company find no vulnerabilities, but they were so impressed that they actually called me on the phone afterwards to ask about the methods we used. He seemed quite frustrated because "normally [they're] able to suggest something that could be improved" but with this, they couldn't find anything at all.
ReplyDeleteI had to explain that we were using this tool called 'Application Express' and that our authentication methodology came pretty-much out-of-the-box.
Thank you for posting this. Given our customers are financial folks and folks involved with US federal agencies, having this information public is a huge help.
ReplyDeleteI had the same experience with the security team at a large hospital network who is driven by security concerns, compliance (HIPPA) etc.
ReplyDeleteThey ran an vulnerability scan for over 12 hours and did not find a single issue.
In this case we were using Trustwave App Scanner (Cenzic Hailstorm) to perform the dynamic application security testing (DAST) assessment.
One caveat here, many of the security issues found in traditional applications are found by scanning source code. Since Apex is metadata driven, it has almost no source code files (save for javascript and plsql in the database).
In this case we were using Veracode Plugin to perform the static application security testing (SAST) assessment.
Because most enterprise tools don't do static testing on Apex metadata and the Apex IDE, we certainly appreciate the plug for ApexSec to so the SAST. Thank you Joel.
Hi Joel,
ReplyDeleteYour post is very helpful.
Regarding this point
"APEX is used in countless military agencies and classified agencies around the globe.".
I would imagine those agencies would run the APEX applications through some kind of security certification process before they let them in the door.
It would be nice to know how and what, and I can show my client that the application is "Military Grade" :)
We have been testing APEX applications for well over 5 years now, this is how some of the aforementioned agencies, military and commercial entities "certify" their code, with a robust security testing process by a reputable third-party company like ourselves or by an internal security team.
ReplyDeleteUsually no application can be deployed in these organisations without receiving a security test first, either using static analysis (SAST) and/or traditional "penetration testing". We normally do both for high risk applications.
Automated static analysis by a tool such as ApexSec is, compared to manual static analysis, much more efficient in cost/time to achieve a good baseline of code security. After that there is usually more to do, in terms of functional testing and manual oversight. Unfortunately there is no "magic bullet" or "military grade", more a case of continual improvement as the threat landscape changes.
There have been a few occasions where we have found security concerns in the APEX framework itself, these have been report by us and addressed quickly and without prejudice by the APEX team. This is another good reason to choose the framework; passionate support by the people that write the APEX framework, knowing this team has "got your back" in terms of security support for the framework. Obviously the applications developed by your organisation still need to be tested as with any other web technology.
APEX applications that are written by end-users usually come into two categories, the ones that stay within the framework, by using the provided components to build the application and the ones that try to stretch APEX by writing large amounts of Javascript and/or plugins and try to augment standard APEX functionality. The latter normally exhibits a greater number of security issues that the former. Robust authentication out-of-the-box is excellent for APEX application, there are rarely any issues there.
There is one absolute in all this, get the security into the application development life-cycle as early as possible. If you don't we guarantee it will stall the project at the end. For example, we have just finished consulting on the retro-fitting of security into a 300 page application, it added two months onto the length of the project.
If security is a concern for your organisation then you could do worse than contacting us to see if we can help you.
Kind regards,
www.recx.co.uk
For over 5 years we have been developing APEX application for financial customers, including banks, which are very serious about security in their apps. Before final release and priori to every update, all applications are verified and tested by external companies specializing in security. They have never reported any issue related to APEX.
ReplyDeleteYou can create insecure application in every technology, but APEX gives you features that make it a little bit harder.
Hi Joel,
ReplyDeleteNice post and a good point. The framework itself is one aspect of security and the application developed by the customer is also a different aspect. I agree that if the framework itself is secure that is fine but the application developer can do things non-standard or write vulnerable code or call vulnerable packages and make it insecure. You capture this point well BUT the point you did not capture is that the application written in APEX does not live in isolation. It sits inside a database and delivers web pages to end users. The database itself can be a source of security issues that can be used to then exploit APEX. The other aspect that you did not cover is the source of the attacker. Of course to test the security of an APEX application in isolation is futile if half of the internal staff or worse even external staff have direct access to the database itself or indirect access via other means then the data can be still exploited.
The focus for me is always data. What you are trying to secure is not Oracle, APEX or the application it is **data** - of course you must secure Oracle, APEX and the application to achieve this but the focus must be on protecting access to data. This could be exploited remotely via an unauthenticated user (test for issues in the framework and the application) or externally via a web authenticated user (again mainly the framework and application must be tested) but internally we can still be vulnerable to all of these external issues BUT internally plus all internal authenticated users of the database and then a bigger task is needed to ensure least privilege, control access to data.....
Some of the things I talk about here are not issues with APEX per-se of course but complement the full picture that our job is to serve data it users and therefore protect data. As APEX tightly sits inside the database we cannot ignore the database for security.
cheers
Pete Finnigan
We have been using eSert (now APEXSert) for over 4 years now. Tools like this and APEXSec and even the built-in Advisor in APEX will help identify security vulnerabilities in developed applications. By using tools like these to fix our vulnerabilities, it has helped all APEX developers adopt more secure development habits. We often think of SQL Injection and cross-site scripting when creating or modifying pages in APEX. I know we cannot be 100% secure on the web, but I think we have successfully secured many "open door" invitations in our APEX applications.
ReplyDeleteJust to let you all know that I noticed that APEX-SERT is now part of OraOpenSource - worth a look - currently supporting APEX 4.2 with APEX 5 version coming soon - seems to work pretty well roll on the APEX 5 version.
ReplyDeleteAPEX-SERT - formerly Enkitec eSERT - is now open source and can be downloaded and used at no cost. Some major additions to the open source version, too! You can download it from here: https://github.com/OraOpenSource/apex-sert
ReplyDeleteCan't emphasize enough that you should be running some sort of scan from day 1 of your development. All too often, I see a 300+ page application that's in production that has never had any security evaluation run against it at all. And when one is finally run, the customer is wowed at the sheer amount of things that need to be fixed and the time it will take to fix them.
- Scott -
This comment has been removed by the author.
ReplyDeleteHi Gola,
ReplyDeleteWhat kind of "security tips" are you looking for, and in what form? And I'm curious - why do you say "security may be issue with oracle"?
Joel
Hi Joel,
ReplyDeleteSorry for saying "security may be issue with oracle".
I just wanted to say that Apex is running inside database so if we are using it without weblogic then anyone can easily find the database IP and hit unwanted authentication for your sys user.
Please give me some tips about oracle Apex so I can impress my manager's for implementing Apex in my organization.
As a developer I found some interesting advantage of Apex
1. Low code and No cost
2. Browser based IDE so development can be from anywhere.
3. Version control on GIT
4. Easy deployment because of few moving components
5. Unlike other languages Application backup not required secretly only need to backup and secure your database.
6. SQL script s can be saved in database only.
7. Reusebility of components like LOVs.
8. Oracle forms can be easily maigrated in Apex.
Bhavani
Hi Bhavani,
ReplyDeleteIndustry best practice is to separate the mid-tier from the database tier. While you can run ORDS standalone, or in WLS or Tomcat, all on the same database server as APEX, that's not industry best practice. It's preferable to have ORDS separately deployed in WLS (or Tomcat) on its own server, and you connect to the database via SQL*Net. Additionally, for production deployments, it's preferable to have each of these behind their own firewall and in their own network zone.
These recommendations aren't unique to APEX. You would follow this model for almost any production deployment of a Web application.
I hope this helps.
Joel