Not allowing external scripts to open database

[michele]

We all know startup scripts won't work if a database is opened by an external script.

This is a major security problem, how can you work around this?

Thankyou for reading and eventually answering my question.

[The Bridge]

This is off the top of my head:

Have your proper startup script set a global number field to 1, then have all other scripts check to see if that field is 1 or 0 before proceeding. Have your proper close script set the global number field to 0 before closing.

[michele]

Very nice!

Thankyou.

[Steven H. Blackwell]

Fascinating. Suppose a hacker were simply to set the flag field to 1. Then where would you be? The concept of having scripts--at least some scripts--perform tests before running is a valid one, but this is far too simple a test. It is easily defeated. There are amy external ways to run scripts, just as there are many ways to bypass the start-up scripts.

Old Advance Man

[The Bridge]

quote:

---

Originally posted by Old Advance Man:

There are amy external ways to run scripts, just as there are many ways to bypass the start-up scripts.

---

Perhaps someone can shed some light on an actual solution to this, if any.

[Steven H. Blackwell]

The tests that are run in startup scripts need to be modularized. Then they can be called at random in other actions. Settinga flag fields is very easy to overcome if there is any kind of editing privilege associated with the file.

Old Advance Man

[BobWeaver]

The major hole in Filemaker security is the fact that you can create a script in another file that can perform as a subscript any script in the target file no matter what password security that you may have put on it. This may not provide the hacker with any useful information, but can allow a malicious individual a means to do a lot of damage.

Make sure that all your files have password protection. If you have configured your files to open with a default password, make sure that it is not assigned to any group. Make sure that EVERY script has the following steps at the very beginning:

code:

---

Allow user abort [off]

Set error capture [on]

If [status(CurrentGroups)=""]

Close[ ]

End If

---

Then, if the file is opened by calling a script from another file, these steps will immediately close the file and prevent any damage.

I make all my files open with default of (no password), which has no group assigned, and no access privileges at all. Then, I make a separate opener file with only a single script which is the startup script. The opener file has no default password, but has the same passwords as the other files in the solution. So, if you run the opener file with the legitimate user password, it's startup script will open all the remaining files with that password, and you are into the system. If you try to open any of the other files, they will open with the default (no password) and immediately close. Of course if a user knows the password for the file, they can get in with the option key, but that file's startup script will take the user to the main opener file which will then launch the rest of the files properly.

I don't guarantee this to be secure, because I have never had anyone deliberately try to hack into anything that I've done. I'd definitely like to hear how others approach the problem.

[Vaughan]

Scripts cannot perform anything that is denied through access privileges (passwords). That is, if the script says "delete all records" but the password does not allow delete, then the script does not peform the step. It may perform all the other allowed steps however.