Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×
  • entries
    45
  • comments
    63
  • views
    108,598

The FileMaker Platform API’s Are Your Friends, Right?


The FileMaker Platform API’s Are Your Friends, Right?

The FileMaker Platform supports integration with a variety of Application Programming Interfaces (API’s), and it has done so for a very long time. These API’s allow FileMaker Platform developers to integrate their solutions with other technologies and applications. This is an incredibly useful capability; indeed, from both technological and business-process standpoints, it is essential.

Many FileMaker developers are not aware, however, that these API’s have the capability to access customer or client solutions in unexpected ways and to extract or insert data, to manipulate business processes developers embedded into these solutions, and to compromise the integrity of these solutions.  Correctly configured and appropriately granular Privilege Sets can control many of these behaviors. But developers must first understand what those behaviors are and then how to control them.

This FileMaker Security BLOG entry will identify a number of these API’s, will describe their use as attack vectors, and will point out some specific issues with several of the API’s. My hope and intent is to equip FileMaker Platform developers with the knowledge necessary to recognize these issues and to address them.

The FileMaker Platform utilizes a number of API’s:

  • Apple Events
  • Active X
  • WebDirect™
  • XML
  • PHP
  • Execute SQL
  • xdbc (ODBC and JDBC)
  • Plug-Ins
  • FMPURL
  • FileMaker Pro External File References and Data Sources

Many developers may be surprised by my including the FileMaker Pro application itself in the list of API’s. Yet, through use of its powerful capabilities to access data in other files and to trigger business-level processes such as scripts, the application is, in fact, an API to itself. This has significant impact from the security standpoint when the capability is misused and when one FileMaker Pro file functions as an attack vector on another FileMaker Pro file.

There are five significant actions an external API can undertake to perform on a FileMaker Pro file.  Not every API can perform all these tasks; however, each can perform at least one of them. What are those actions?

  • Read and extract data
  • Write data
  • Read and extract metadata
  • Manipulate the User Interface
  • Trigger FileMaker Scripts

What are some of the types of attacks these API’s can facilitate?  And, more importantly, how can developers ameliorate the adverse impact of such attacks and perhaps prevent them in the first instance?

One category of attack centers on manipulation of the User Interface to send the attacker to a layout in the file the developer never intended to have exposed.  This is one of the inherent dangers that so-called “Developer” layouts present.  Unless a layout enjoys access protection in the Privilege Set attached to the active Account, the Attacker can navigate to it and observe anything shown on it.

Another category of attack deals with reading and extracting data from a table.  Some API’s can perform this task and even write out the data to another application such as Excel or Microsoft Word. In other instances, an attack can cause an export of data from a file.

Still another category of attack involves the triggering of scripts in a manner developers did not anticipate or intend. Generally speaking, if a script is either modifiable or (more commonly) executable to the active Account’s Privilege Set, then the Attacker can invoke the script. Developers must carefully consider the conditions under which a script runs. Scripts that re-log into the solution with elevated privileges without a credentials challenge are especially attractive targets for attackers. The script does not have to appear in the Scripts menu or be attached to an object on a layout to be vulnerable to such an attack. Its mere existence in the file in an unprotected state is sufficient to render it vulnerable.

Some API’s can extract metadata from a file.  Some metadata, such as a list of items in a value list, might also reveal data at the table level. Additionally, the metadata item might be a list of the Layout names in a file.  An attacker could use this information to attempt navigation to a particular layout such as the “Developer” layout previously mentioned. Similarly, metadata might reveal a list of Script names; this could facilitate an attack on a selected script.

There are three API’s that cause particular concern because of their breadth and relative ease of use.  These three are Apple Events, the FMPURL process, and FileMaker Pro files themselves.

The Apple Events Suite has an extensive set of commands that can read and write data, read metadata, manipulate the UI, and trigger scripts. In addition, they can work outside the normal constraints found on layouts in a file. http://thefmkb.com/5671

The FMPURL process (that is described at https://www.filemaker.com/help/14/fmp/en/html/sharing_data.17.6.html can open a file and run a script in it.  If the file is already open, then the script will still run.

A FileMaker Pro file can also read and write data in another FileMaker Pro file.  That is a commonly used process.  But such files can also run scripts, manipulate the UI, extract data, and extract metadata from other files.  If the target files are not protected, they are vulnerable to these type actions. This is a more subtle process than might first be observed.  A number of Privilege Set bits apply only to the file in which they are defined; they may work differently when called externally from another FileMaker Pro file.

So, how can a FileMaker Platform developer address these issues and protect a FileMaker Platform solution?  There are several key steps developers should take:

Invoke File Access Protection.  This prevents unauthorized references by external rogue files an attacker might create. FileMaker, Inc. introduced this feature to the Platform in version 11. At that time I authored a White Paper fully describing this feature. The White Paper can be found at the following location: http://www.fmpug.com/resources/security_schema_changes_filemaker_11

Tightly define Privilege Sets so as to block access to elements that need protecting. Items marked as «No Access» do not respond to External API calls as a general rule.

Take steps to prevent automatic access to files without credentials. In most instances developers should prevent auto-opening of files, especially at higher levels of privilege.  Once opened, such files can become vulnerable to attacks using the API’s. They can also be used to attack other FileMaker Pro files. I discussed some aspects of this two years ago in a post on this BLOG 

Do not enable any API’s not needed in a file. This includes such items as XML, PHP, and xdbc.  Strictly speaking, WebDirect™ perhaps is not actually an API; however, developers should not enable it either if it is not needed.

In this BLOG post, I have enumerated a number of FileMaker Platform External API’s and described how a Threat Agent (Attacker) might use them as a vector to compromise FileMaker Platform solutions.  I have also enumerated some specific attacks.  And I have provided several recommendations for protecting the files and lessening the likelihood of a successful attack.

Steven H. Blackwell

 

  • Like 1

5 Comments


Recommended Comments

taylorsharpe

Posted

This is a good topic for discussion.  APIs are our friends.  But like any technology, if we don't understand them and plan for the security implementation, we can really mess up.  I hope this is a healthy discussions of ways to utilize APIs while taking into account appropriate security controls.  I also don't want people to be afraid to use APIs because they open a powerful word of additional functionality to FileMaker.  But they are just like FileMaker... you wouldn't create a FM database with no security.  It is the same with APIs.  

The big take away I hope people have from this is that the FM security does not handle security for API functionality outside of FM.  We are used to a strong robust FM integrated security for our solutions.  But using APIs gets into areas beyond which FM security and encryption is in control. And each API technology is different and has a different set of vulnerabilities and security controls.  

This gets back to do you have a security plan for your solutions?  And does the security plan address each of these technologies.  

sreese

Posted (edited)

In a security discussion on the regular FileMaker forums I made a big stink about wanting to disable some of those APIs, but there was a lot of pushback from users against it. We don't have any apple products in our environment, so wouldn't it make sense to be able to disable access from the Apple Events Suite?

Edited by sreese
webko

Posted

If you have no Apple products, then isn't this vector already unusable?

Wim Decorte

Posted

All it takes is that your attacker has Apple products... it's the FMP client that exposes that particular API, not the server.

And besides, the Windows ActiveX API carries its own vectors.

Steven H. Blackwell

Posted

Quote

If you have no Apple products, then isn't this vector already unusable?

Quote

We don't have any apple products in our environment, so wouldn't it make sense to be able to disable access from the Apple Events Suite?

As Wim points out, NO on both counts. The question is this:  What parts of the FIleMaker Platform and/or these API's can access your files, and under what conditions?

Quote

The big take away I hope people have from this is that the FM security does not handle security for API functionality outside of FM.  We are used to a strong robust FM integrated security for our solutions.  But using APIs gets into areas beyond which FM security and encryption is in control. And each API technology is different and has a different set of vulnerabilities and security controls.  

This gets back to do you have a security plan for your solutions?  And does the security plan address each of these technologies.  

This is not correct either.  The issue is not whether the FileMaker Platform manages functionality outside of FileMaker.  It's how the various parts of the FIleMaker Platform manage security inside the files.  The internal FileMaker Pro Privilege Sets can manage many of these API functionalities as can some other internal factors.  But this is an incomplete suite.  In the future, I am hopeful that the capabilities of that suite can be enhanced.

Likewise, a "security plan" does not tell us much.  What we need to know are what assets we are trying to protect and what the level of adverse impact on those assets would be when there is a breach. Then, and only then, can we assess vulnerabilities and how to control them and to mitigate the impact of the breach.

×
×
  • Create New...

Important Information

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