 |
|
Finding APEX
Hacking vulnerabilities with Google
Oracle Tips by Burleson Consulting |
The advent of a cost-free Oracle (Oracle XE)
along with the powerful free APEX environment was a brilliant
move by Oracle. In 2006, thousands of people will create
web-enabled Oracle databases using Oracle XE and APEX, and many
of these may have security exposures. For an example of this
exposure,
run the search "filetype:ora+sqlnet" to see exposed
sqlnet.ora files on the web. If the Googlebot find your
initialization files (init.ora), people can
see your Oracle parameters.
If you have read the book "Google
Hacking for Penetration Testers" or seen Johnny Long's web
site on
Oracle hacking with Google, then you know that Google can be
used by good guys to find potential exposures. For the bad guys,
they can use Google to find
the location and internal details from Oracle APEX databases on the web.
For example, try running a Google search for
"ERR-1002 Unable to find item ID", and you will see Oracle
databases on the web where Google was able to archive an APEX
screen page.
This is a great approach for vendors who want lots of exposure on
Google, like Amazon, where a large amount of traffic comes from
allowing the Googlebot to archive their web pages and URL's.
For more information, check-out these topics:
What's inside an
APEX URL?
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.
As a review, see
APEX URL contents.
An APEX URL has this form, in
three general sections, separated by the URL's last-slash (/), a
"f?p=" tag and a dot (.):
domain_address / f?p= screen . values
After the f?p= clause we have these subparts:
page_to_invoke : data_values
So, the whole call now looks like:
domain_address / page_to_invoke . data_values
Within the page_to_invoke construct we have
these three values:
application_nbr : page_nbr : session_nbr
Hence, the whole URL is now in the form:
address /
application_nbr :
page_nbr :
session_nbr .
data_values
Finally, example data values are shown in the
Oracle APEX user guide shows this:
.::NO:6003:MY_ITEM1,MY_ITEM2,MY_ITEM3:1234,,5678
This colon-delimited format suggests six areas
in the data values section:
-
. (dot)
= start of passed values
-
:
= positional parm #1
-
:
= positional parm #2
-
:NO
= third positional indicating
nodebug (hide debug messages)
-
{1-n}varnames = Repeating char names
of variables
-
{1-n}values = repeating groups of values,
one for each varname
Depending on the confidentiality of your
APEX application you may not want this information exposed to the
public.
So, what's exposed to the
world?
When an installation of
APEX allows the Googlebot to access your APEX screens you are opening-up your
database to public exposure of confidential system details. If
you are a vendor you love this feature, but if you are
operating your business you may not want the following information
in the Google index for everyone to see your:
Armed with this information, bad guys will know:
-
Your company name
-
Where to find you (your IP address)
-
Your APEX application number
-
Your APEX screen numbers
-
Screen variable names
-
And, worst of all, people can see actual
data being passed between screens
Remember the potential threat from URL
tampering in APEX. Improperly configured,
APEX can allow URL
tampering, where you can change the values passed in an APEX
URL. For the good guys, we can use Google to learn about
APEX vulnerabilities and see how to fix them.
Finding
APEX pages on
Google
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 might look
like this.
Increasing Google rank for
APEX pages
If you are a vendor who wants Google to index
your pages with a high pagerank, the dynamic APEX queries with a
question mark are ranked lower than static web pages.
Here are
details about how to archive dynamic APEX pages into
static web
pages.
Protecting your
APEX
application from the Googlebot
The best way to prevent a search engine from
indexing your APEX application. On the server, you can
protect your directories with read-only permission like "chmod
744" and umask commands.
The
Google privacy
policy addresses the issue of URL's that pass internal system
details and notes that the Googlebot stores personal URL
information:
"When you submit information to a web page (such as a user login
ID or registration information), the operator of that web site
may "embed" that information - including personal information -
into its URL (typically, after a question mark ("?") in the
URL). When the URL is transmitted to Google, our servers
automatically store the URL, including any personal information
that has been embedded after the question mark."
Web crawlers are supposed to follow the robots
exclusion standard found at
"a standard for
robot exclusion. We can also direct Google to
exclude your entire web site.
To remove your site from search engines and
prevent all robots from crawling it in the future,
place the following robots.txt file in your server
root:
User-agent: *
Disallow: /
To remove your site from Google only and prevent
just Googlebot from crawling your site in the
future, place the following robots.txt file in your
server root:
User-agent: Googlebot
Disallow: /
|
APEX support:
 |
For APEX development support just call to gat an
Oracle Certified professional for all APEX development
projects. |
APEX book and code samples:
 |
|
Need Oracle training?
- Get Oracle training from a practicing Oracle
expert
- Get custom training designed to
fit your needs
- Conveniently offered at your
workplace, anywhere in the USA
BC Oracle training offers some of the
USA's most respected Oracle experts and authors. Why spend
thousands on cookie cutter Oracle classes when you can have the
personalized attention of a real Oracle
guru? Just call now: |

|
|