Databases Reference
In-Depth Information
Authorized Access
As the WikiLeaks story demonstrates, hacking often comes from the inside. An army private was
provided authorized access to a system containing vast amounts of sensitive US Government data. The
army private may have had access to all of the compromised information. Perhaps the data should have
been more compartmentalized, access more audited, or users more vetted. The example demonstrates,
though, that any access at all to a system, even with limited privileges, provides a starting point for
unauthorized activity.
An APEX Example
One afternoon in the summer of 2009 I received an instant message from a friend and the author of a
very popular public APEX application. In his development environment, the application had been
upgraded from APEX 2.x to APEX 3.2 and had multiple enhancements. He was about to release this
update to production and wondered if I could give it a quick look for security vulnerabilities. Anyone on
the Internet could access the application and self register to use the application. This access model
presents one of the greatest challenges. Anyone on the Internet can get authorized access with only a few
clicks. They can create multiple accounts and see how those accounts can interact.
Assessing an application, the infrastructure it runs on, and the policies and procedures that support
it requires much more than a quick look. Nevertheless, this was a friend, so I agreed to spend a few
minutes looking at it. After all, friends don't let friends release code with security holes. He messaged the
URL and I set my stopwatch. Nine minutes later I messaged back, asking if my friend could log in and
look something up for me. It didn't take him long to realize that he was not able to log in—his password
had changed.
In those nine minutes I had created my own account, recognized how to find other users'
underlying user_ids, located the change password screen, and inserted my friend's user_id instead of my
own when updating the password. My friend could not log in to his account, but I could. To make
matters worse, this account gave me access to administrative screens that typical self-registered users
should never know exist, let alone be able to access.
The Details
The primary problem in this case was the self-service screen for updating user information. User
maintenance screens are a common place to begin hacking attempts. This application used a table to
store the username and password. Although I never saw the APEX application code or data structures,
the basics are easy to imagine. The system used a table with the following structure:
USER ID
: A primary key generated by a sequence or random number
•
USERNAME
: A string chosen by the user, e.g., bjones
•
PASSWORD
: A string chosen by the user, hopefully obfuscated in some way
•
•
Additional columns as required, e.g.,
FIRST NAME
,
LAST NAME
,
EMAIL
This table could be created using the Create Table wizard in APEX (Figure 8-5).
