Jump to content
wedgeman

Hacking concerns of startup scripts?

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

@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 by wedgeman

Share this post


Link to post
Share on other sites

"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

  • Like 1

Share this post


Link to post
Share on other sites

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?

  • Like 1

Share this post


Link to post
Share on other sites


 

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?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

 

 

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By Joel Shapiro
      Hiya
      Can FMPerception show the elements that have script triggers that call a specific script?
      Thanks,
      -Joel
       
    • By tdub808
      Aloha All,
      DISCLAMER
      I'm not a programmer nor a technical writer and also is ESL. So my writing is tailored to me or someone like me aka noobie as F* (toward me not you). Detail and step by step and as clear as possible. Please let me know if i’d missed something or grammar correction.
      System: As of 04-20-2016 (not potting around) macOS 10.11.4 (yeah I’m using macOS name form now on instead of OS X), iOS 9.3.1, Filemaker Pro Advance 14.0.5 and GO 14.0.4 
      OBJECTIVE
      Make merge variable to show the slide control panel's object name (the name of the front most slide panel). So when the file is open the merge variable will show the name of the from most slide control panel letting you know which slide you're on.
      ISSUE
      Merge Variable does not show value on open first window. Please read entirety below.
      WORKAROUND
      Although it's a lame hack that I prefer not to use but it does the job. I'd included these two ugly steps in the script Go To Object [ Object Name: "Panel2" ] then Go To Object [ Object Name: "Panel1" ] to have the merge variable show Panel1 name on opening of the file.
      # the number symbol or the hashtag is to comment as a note to yourself and others about the script line(s) (ignored when the scrip is performed functional line). Set Variable [ $$panelName; Value:GetValue ( Get ( TriggerTargetPanel ) ; 2 ) ]  #The "2" is the result value which is the name of the objectName that you gave it in the inspector panel. Number "1" will return the number of the panel. As in 1 (which is the first) of 3 panels or 2 (which is the second) of 3 panels or 3 (which is the third) of the 3 panels. Go to Object [ Object Name: "Panel2" ] Go to Object [ Object Name: "Panel1" ] #Refresh Window will work the same but I think it'll refresh the whole layout. FYI: "MVpanelName" is the object name of the merge variable "<<$$panelName>>." Refresh Object [ Object Name: "MVpanelName" ]  
      ENTIRE HOW TO
      Create a new file.  Choose File menu > New Solution… https://www.filemaker.com/help/14/fmp/en/html/create_db.8.5.html Enter Layout Mode. Choose View menu > Layout Mode or press COMMAND + L keys. https://www.filemaker.com/help/14/fmp/en/html/fmp_basics.3.7.html Insert Slide Control. Choose Insert menu > Slide Control https://www.filemaker.com/help/14/fmp/en/html/create_layout.9.42.html Name the each slide panel. Choose View menu > Inspector or press the COMMAND + I keys. Choose Position tab > Enter Name field. Press the Enter/Return key to commit the name to the object. http://help.filemaker.com/app/answers/detail/a_id/6147/~/naming-objects-in-filemaker-8.5-and-later Choose the next slide and repeat.     Create a script with the above script. Choose Scripts menu > Script Workspace… Type or copy and paste the script in the code box above in the the WORKAROUND section of this post. https://www.filemaker.com/help/14/fmp/en/html/create_script.14.3.html Choose Insert menu > Merge Variable. Name it the EXACT same as the name use in Set Variable objectName ($$panelName). https://www.filemaker.com/help/14/fmp/en/html/create_layout.9.35.html#1064499     Set File Script Triggers. (not a 100% sure this is needed) Choose File menu > File Options... Choose Script Triggers tab > click checkbox OnFirstWindowOpen > click Select button > choose your script > click OK button > click OK button. Set Layout Script Triggers. (not a 100% sure this is needed) Choose Layouts menu > Layout Setup... Choose Script Triggers tab > click checkbox OnLayoutEnter > click Select button > choose your script > click OK button > click OK button. Set Object (slide control) Script Triggers. (this is a must) Right click on the Slide Control Panel object > select Set Script Triggers... Click checkbox OnPanelSwitch > click Select button > choose your script > click OK button > click OK button. Enter Browse mode. Choose View menu > Browse or press the COMMAND + B keys. SEEKING HELP
      Please reply if you have a better solution to this terrible workaround.
       
      Mahalo All!
       
    • By mmarino
      Any time the user updates a field, or enters a new layout, I run a script. This works fine on FileMaker Pro and WebDirect, but the script triggers stopped triggering on Go. Not sure what is causing this, because they did work for a time. Buttons still work, but the requirements don't allow for the user to have to press a button every time they change the search parameters. Does anyone know what could be causing this behavior?
    • By Peter Barfield
      Hi guys,
      Wondering if someone can point me in the right direction. I am working on a POS system (only small) and at the moment all is progressing nicely. I have a touchscreen keypad that I have implemented not the in built one and am wondering how I would tell filemaker or more succinctly the cash drawer to open say if they pressed a button called open drawer (for arguments sake). I'm assuming that each cash drawer might be different in how this works buts let say it requires the F9 Key to be pressed to open it. How would one simulate this through the open drawer button?
      Thanks in advance.
    • By malkus
      I'd like to keep the user on the currently selected tab even when the user leaves for another record.
      I have a script that identifies the currently active tab and another that restores that tab state.
      I can trigger the latter via layout script trigger "OnRecordLoad" but how do I trigger the "memorizer" - even when no changes have been made to the record?
       
      I am on FM11 so I don't have access to the new Tab-script behaviours.
×

Important Information

By using this site, you agree to our Terms of Use.