Access Security? HA!

  • Thread starter Thread starter Tom
  • Start date Start date
T

Tom

I wrote a couple of weeks ago and asked a security
question about keeping form being hacked. Thanks to those
who responded - but I have found a different problem
which I don't think should require SQL Server to prevent -
or should it?
Here's what I did. I created a new db using the built in
System.mdw. Then I opened that db using my "secure" mdw
file as a standard user in that mdw. Then I went to
import some tables. I was able to access one of
my "secure" db's (OK so far since the user does have
Open/Read permissions on that db) and I was able to
import those tables including all date into my non-secure
db which had been opened using the secure mdw file.
Essentially that means that any user who has open/run
permissions on the back-end can create their own front
end and import or even link the tables. I realize linking
will not help them if they only have read permissions.
But importing does because they now become the owner in
their new front end.
I read through the SECFAQ but did not find anything
specifically addressing this issue. What I found was
that "Access is secure to a point..."
Did I miss something? Do I have something screwed up in
my permissions? Is it really this easy for any user with
simple open/run permissions to get at any data they want
even if in our secure front ends they would not be able
to?
I hope I am just missing something and I don't have to
spend - who knows how much - to move to SQL Server.
Thanks in advance for your help.
Tom
 
Think about what you are asking. The user has permissions to read data, but
you expect somehow that they will be prevented from reading the data into
another db. This would be possible with ANY database engine (SQL Server,
Orable, whatever). If you don't want the user to be able to read or import
the data, you have have to take away the permissions for them to do so.
 
Tom said:
I wrote a couple of weeks ago and asked a security
question about keeping form being hacked. Thanks to those
who responded - but I have found a different problem
which I don't think should require SQL Server to prevent -
or should it?
Here's what I did. I created a new db using the built in
System.mdw. Then I opened that db using my "secure" mdw
file as a standard user in that mdw. Then I went to
import some tables. I was able to access one of
my "secure" db's (OK so far since the user does have
Open/Read permissions on that db) and I was able to
import those tables including all date into my non-secure
db which had been opened using the secure mdw file.
Essentially that means that any user who has open/run
permissions on the back-end can create their own front
Click to expand...

What permissions did this user have to the Tables? You can deny
permissions to the tables and use RWOP queries to provide all data access.
If they have no permissions to the tables themselves, then they won't be
able to import them or link to them.
 
Tom said:
Rick,
Sure enough the user has permissions on the back end
table to add/delete/etc. I guess I did not think that
would allow them to import them into a db which was not
under the same authority/security as the original mdw
file.
Anyway, if I use your suggestion, then I need to deny
them all permissions on the back end tables - do I deny
them on the front end as well? Also, that means for every
form I will now need to create a corresponding querry
instead of using the table direct - correct?
Will all that hassle really solve my problem?
Thanks in advance.
Click to expand...

Regarding the RWOP query issue I am only going off of what I've read in
these newsgroups, but my impression is that it would prevent users from
importing the tables into another file.
 
Rick Brandt said:
Regarding the RWOP query issue I am only going off of what I've read in
these newsgroups, but my impression is that it would prevent users from
importing the tables into another file.
Click to expand...

Correct. And to the OP: yes, you *do* have to do all access to the
tables via RWOP queries - otherwise the user must be given direct
access to the table(s) - which is what you are trying to avoid in the
first place.

HTH,
TC
 
(snip)
I created a new db using the built in System.mdw
Click to expand...

Well, that was wrong to start with. The default system.mdw is created
without a so-called "workgroup ID". This means that anyone with access
to your PC, can recreate it. (They can maybe even do that *without*
having access to your PC.)

So the first step in securing a database, is to create a *new*
workgroup file and give it a nonblank workgroup ID. Then no-one else
can recreate your workgroup file (and thereby gain full administrative
rights over your database), unless they know that ID.

HTH,
TC
 
Back
Top