No database is secure without precautions. For example, a user creates an
Access database through a FrontPage results form. The database exists in the
default fpdb directory. Because this directory is part of the web it is
publically available and downloadable by anyone who can figure out where to
look (which isn't too hard a lot of the time). Placing it out of the web and
using an ODBC connection to talk to the db helps this issue. Now, you may
have a number of text boxes in the form. Unless you have a mechanism to
check the text of every textbox when the form is submitted, a hacker could
gain access to all your data easily through what is known as a SQL Injection
attack. This type of attack involves carefully crafting SQL queries to place
into your text box that can return results from your database without you
ever knowing. This is much more likely to happen when using ad-hock SQL
queries such as FP and most other editors use (ad-hoc by the fact that the
SQL query is cobbled together as a big long string such as "SELECT * FROM
tblUsers where EmailAddress = '" & Request.Form("EmailAddress") + "'".
As for the items specifically in the article, they help a bit but only part
of the possible problem. The server administrator is the only one who can
set the appropriate permissions for your database if you want them changed
as one possible method discussed in the article. As for the others,
basically they just involve how the db is built in Access (or another rdbms)
and how to use a unique user account to talk to the db (which is something
specific to each type of database and can be setup within the appropriate
database application).
Hope this helps,
Mark Fitzpatrick
Microsoft MVP - FrontPage
