Security - Expert Oracle Application Express - page 360

Custom Developed Applications vs. Commercial
Off the Shelf Products
There are many commercial off the shelf (COTS) content management and website building tools
available. HBGary used a custom developed content management system for their site. This drives two
questions:

• Are COTS products more secure than custom developed applications?

• Are proprietary systems more secure than open source systems?

Naturally, the questions could be formed in the reverse:

• Are custom developed applications more secure than COTS products?

• Are proprietary systems more secure than open source systems?

There is little agreement as to what is more secure, with valid arguments on both sides. Most
organizations will require custom, COTS, and open source solutions within the enterprise. Hence,
determining which is more secure is less important than understanding the vulnerabilities of each.
COTS products are presumably developed by professional software developers, rigorously tested,
with patches provided on a regular basis. On the other hand, once a vulnerability is discovered and
published, every installation of that software is a target until a patch is released and applied. Later in our
story of WikiLeaks, HBGary, and Anonymous, we will discover that Anonymous also exploited a known
bug on an unpatched operating system. Applying security patches on products is critical to enterprise
security. This may seem obvious, but http://www.ie6countdown.com/ shows that, as of early 2011, 12
percent of the world continues to use Internet Explorer 6. Internet Explorer 6 has a variety of known
bugs and yet a surprisingly high percentage of users continue to use it and corporations continue to
specify it as a corporate standard.
On the side of custom applications, hackers are more likely to target and publish flaws with widely-
used applications than a system only installed in a single location. Custom applications may not have
the same rigor in testing or development standards, and some development tools are more likely to
introduce flaws such as SQL Injection than others. Understanding the security implications of the
chosen technology is critically important.
Open source solutions, or any solution in which the source code is available, poses additional
challenges. While having the source available provides the opportunity for more developers to fix
vulnerabilities, it also provides the opportunity to scan the source for flaws. In the PL/SQL example in
the previous section, our findUsers procedure could have been written without a SQL Injection flaw. For
example:
create or replace procedure findUsers(pEMail in varchar2) as

cursor c1 is select username from my users where email = pEMail;

begin
for c1Rec in c1 loop
htp.p(c1rec.username);
end loop;

end;