Hacking concerns of startup scripts?

[wedgeman]

I've been searching for some clear answers on db vulnerability, specifically related to scripting.

We have a particular solution running in FMP13, with EAR. This is a peer-shared file design, which has hundreds of installations in peer-shared environments.

User access accounts have been severely limited in released versions (no admin, no [full access]), limited menus, etc..

Users are heavily striated by account privilege set.

 

I've read bits here & there mentioning that initial opening scripts (onwindowopen, etc) at startup are particularly vulnerable, but haven't found anything definitive.

1. is an opening script trigger a legitimate security flaw?? We use it to determine layout paths, check/confirm licensing, etc, so if it is 'hackable', what alternate option is there?

2. I noticed that even attempting to bypass script triggers, the system requires a full access name/password.. BUT it also displays the name of the particular script (seems like a point of weakness to me)... Is there a way to prevent this?

[Fitch]

There's nothing wrong with an opening script trigger. It only becomes an issue when people try to use scripts instead of the security settings.

It sounds like you are taking appropriate measures. You may want to suggest number 2 as a product idea.

[wedgeman]

Many thanks. just wanted to make sure there's not a loophole in there to be used.

I can't understand why people would NOT use the built-in accounts/privilege sets, etc. I wouldn't conceive of developing a database without them...

[Steven H. Blackwell]

In my view, we need to restate the question here as well as to examine the underlying premise:
    •    The OnOpen script presumably exists for some purpose related to the design of the database system, to the business processes it manages, or to both.
    •    The larger question is what would happen to either if the file were opened and the OnOpen script did not run.
An Attacker can bypass an OnOpen script in any of several ways. Other design considerations in the file will influence the selection of some of these.  Peer to peer hosting, even with EAR, is not optimal, but it will work. EAR has little impact in this situation; however, it is good to have it.
So the base question is whether you have protected the file against unauthorized manipulation in such a way that it could be opened without triggering the OnOpen script.  Developers typically invoke such protection by use of fine-grained privileges in specific Privilege Sets particularly as they relate to scripts, by extremely judicious use of layout-based script triggers, and by employment of File Access Protection.  As we have moved to later and later versions of the products, FileMaker, Inc. has provided additional controls to prevent External API's such as Active X and AppleEvents from serving as conduits for manipulation of files that could result in their opening without triggering an OnOpen script.  You can read more about that here: https://fmforums.com/blogs/entry/1738-behavior-change-api-privileges-in-version-16/ as well as following the references in that BLOG post to earlier ones here on FM Forums.

Respectfully,
Steven H. Blackwell
Partner Member Emeritus, FileMaker Business Alliance

 

[wedgeman]

@Steven H. Blackwell many thanks for the thoughts.

 

However, this leaves me questioning the validity of using  OnOpenTrigger scripts at all.

Are you saying that OnOpenTriggers can be bypassed by someone whose privilege set is authorized to only execute scripts, who has no authorization to edit layouts, edit value lists, or edit (or view) scripts?

I know there are a million caveats, numerous weak points, and a thousand ways a db can be left vulnerable..

IF properly implemented, can a db be set up such that OnOpenTrigger script is not vulnerable to being bypassed/hacked?  If so, how? Obviously this is an open-ended question, but assuring security is always open-ended, it seems..

Edited December 31, 2017 by wedgeman

[Steven H. Blackwell]

"Are you saying that OnOpenTriggers can be bypassed by someone whose privilege set is authorized to only execute scripts, who has no authorization to edit layouts, edit value lists, or edit (or view) scripts?"

Yes, that is correct. It may vary, as you suggested, from situation to situation.  This is one of the reasons we advise people not to employ such scripts for "security" purposes.

As previously noted, as we have gone from version to successive version over the past 13 3/4 years, FIleMaker, Inc. has worked to close a number of the potential attack vectors, including external file manipulation and use of external API's.  Remember also, please, that the script itself has nothing to do really with gaining access to the file.  If someone obtains credentials for an Account, that person can access the file.  In most instances accessing the file with trigger the OnOpen script.  But we cannot 100% guarantee that in every instance that this will occur.  In fact, we can state the opposite; in some instances it can be possible to by-pass the firing of the script. And circumstances will vary version by version.

I realize this is not the answer you wanted to hear.  However, it is the best information I can provide you about this topic.

Steven H. Blackwell

[Josh Ormond]

To add to what @Steven H. Blackwell has said.

Can you do a lot to prevent someone from by-passing the OnFirstWindowOpen script trigger? Yes, absolutely. Can you 100% guarantee that it will run? No. There are ways to prevent it from running, even if only temporarily. The answers you received are trying to account for varied security changes from version to version. One other important thing to remember, you may have built it for 16's security features...but did you make sure they can't open the file in 13, 14, 15?

OnFirstWindowOpen is meant to get your user to where you want them be when they begin using your custom app. It simply can not, and should not, be part of your security ( what the user is allowed to do ). The question posed is a good one. IF the OnFirstWindowOpen script does not run, can the user do something you didn't expect or want them to do? By setting up the privilege set to limit what they are allowed to access, you then afford yourself the strongest protection.

The main premise is this. If the privilege set allows them to see the data, they can see the data. If the privilege set allows them to go to certain layouts or run certain scripts, they will be able to run them or get to them. Scripts are merely one mechanism to automate the movement of the user and/or data. It allows you to provide a better user experience.

Allow User Abort [ Off ] is useful. And should be used in many places. However, it is not a guarantee that the script will complete. One many thing to think about. You have FileMaker Pro Advanced. What happens when you open the file with the debugger open, and are not logged in as a [ Full Access ] account?

[wedgeman]

 

Quote

IF the OnFirstWindowOpen script does not run, can the user do something you didn't expect or want them to do? By setting up the privilege set to limit what they are allowed to access, you then afford yourself the strongest protection.

 

This brings up an interesting dilemma..

This particular solution has a licensing model which runs on a script (check certain things, if/then, etc).. it functions based upon privilege set (ie., if Get(privilegesetname>xyz) go layout XYZ, else go to Layout FGH).. Additionally (and more importantly), there is a non layout-accessible table which covers licensing, applies certificates, etc - which determines whether or not this particular serial# is validated for an active license.

Lower level users aren't allowed to see those particular layouts (restricted by privilegeset name), but the greater question in my mind is HOW to implement this licensing structure?

If OnFirstWindowOpen can be bypassed or circumvented, how does the collective typically handle such things?  We have to manage licensing somehow, and had assumed that a script in the openning process would suffice for this.  Is there another point in time where a forced script would be less vulnerable?

[Josh Ormond]

In a case like that, make the default access be to nothing. No access to anything.  Only allow access to the data, and layouts once the script finishes.  That makes it so that when the OnFirstWindowOpen script has not run, they have no access to the data, the scripts, layouts, etc.

There is then no benefit to not having that script run.

[wedgeman]

33 minutes ago, Josh Ormond said:

In a case like that, make the default access be to nothing. No access to anything.  Only allow access to the data, and layouts once the script finishes.  That makes it so that when the OnFirstWindowOpen script has not run, they have no access to the data, the scripts, layouts, etc.

There is then no benefit to not having that script run.

Perfect..

Is there a mechanism whereby people (hackers) would be able to arbitrarily read scripts being implemented, and bypass them during the process, thereby circumventing particular auto-loading scripts?

If so, how are you able to prevent this or mitigate it?

In my particular situation, the need is to make sure that a series of scripts are performed to ensure the licensing model completes.

Based on your recommendation, the file is set to open to a particular layout which has no data, no buttons, scripts, or portals (ie., a dead/static page).  THAT page has an OnLoad trigger which in turn handles licensing, serial checks, etc (everything the script was doing on the OnFirstWindowOpen), but if the script is bypassed, it now goes to the blank/dead page with no opportunities to go anywhere.

 

 

[Josh Ormond]

With the privilege sets the way you have them now, add an additional check. A global field that only a [ Full Access ] account has access to. Set that field in your licensing process. If that field is not set, the script did not run. If the script doesn't run, the privilege set will prevent access to the data or any scripts.

As far as reading the scripts, no, hackers can't do that. Unless they brute force override the full access account password. But that's a different problem, which you cover by using EAR.

You can include a test at the beginning of all scripts, to ensure that field is set. If it's not, bail from the script.