An idiots guide to securing your solution

[Singlequanta]

OK; so i chose the topic heading as the Idiots guide to securing your solution rather inhumanely. I am not a big fan of those "Idiots" series because I certainly don't view myself as an idiot.

However; I've done some pretty stupid things... but i digress.

Before I go on; I want to provide you with a quote that I overheard by my receptionist who was talking about our systems administrator. She didn't like the guy very much and this is what she had to say:

"There are two qualities a systems administrator should never express: Arrogance and Apathy."

So the sixty-four dollar question is, how do you secure your filemaker solution?

I have said this in other posts, and will say it again - purchase Steve Blackwells book. It covers the principles of securing your solutions and provides examples. But most importantly, it provides a different way of thinking about securing your solutions.

In this post, I am attaching a zip file with a fair representation of the process that people go through when securing their solutions. I will refer to this as a practical example, and invite this to become an open forum on collectively improving security.

So without further hesitation, please download the files and review the solutions. There are Four folders. Original, Bypass, Attempt 1, Attempt 2

The original folder contains my original databases that I thought i had secured. The first file is ally NOT secure, the second one is my attempt to secure it.

The BYPASS folder contains the clever bypass hack.

The Attempt_1 folder contains my first attempt to get around the bypass hack.

The Attempt_2 folder contains my second attempot to get around the bypass hack.

In a separate post following this one, i will explain in a little more detail; what has happened....

Securing_Solutions.zip

[Singlequanta]

OK;

For starters; the reason i was able to "bypass hack" the scripts and execute a script on the remote file was due to a simple authentication token process. Call it a feature or call it a flaw, it is what it is.

Essentially; if I am able to create a local file (hackit) that I can authenticate on; that has a matching authentication token as my destination file; then I will by default be granted access to that file -- even in the situation where I used the developer tool to remove the [Full Access] privilege set.

Scary eh?

not really. It works just various other authentication models.

So how do you begin to secure your files?

Well for starters:

1) don't trust that filemakers internally created privilege sets are all that they are cracked up to be.

2) Enable your GUEST account; and then create a privilege set for GUEST that has no access privilege at all. Assign that privilege set to GUEST and then DISABLE the guest account.

3) Do NOT use user names such as "User" and "Admin" and definately do not use "user / user" and "Admin / admin" as the username and password sets.

Remember this: the authentication token is the successful verification of both the username and the password.

4) Create a user account with something such as:

username: insecure.user

password: e0:44:99:$$:giggle

5) set your database to automatically open using this (or some other secure UID)

** this step may not be practical for most solutions where more advanced user authentication is required; but is a good step for solutions that don't use the inbuilt filemaker acct handling

6) RENAME your admin account to something a little more secure; such as: mysolution.admin

7) Give your admin account a proper password -- that is not easy to guess.

All of those steps above will contribute to preventing a user from connecting to your file and executing a script without proper access rights. BUT - that is NOT a guarantee they won't.

To make your solution **more** secure; do the following:

within your solution; modify the extended privileges of limited user sets and specify that these users are allowed to execute scripts only. This of course assumes that you want your authenticated users to run the scripts.

In your administrative access levels; grant the ability to modify scripts.

To make your solution even **more ** secure; you may consider "wrapping" your scripts within an internal security wrap. This is only effective if you have removed the ability for your users to modify scripts; because if they can modify the script; then can certainly remove your wrapper.

A method that I enjoy is as follows:

IF [ Get ( SystemNICAddress ) = "00:11:22:33:44:55:66" ]

# This workstation is permitted to run this

# script

Show Custom Dialog ["Message","Access Granted"]

ELSE

# DENIED

Show Custom Dialog ["Message","Access Denied"]

ENDIF

There are plenty of other ways to secure your solutions above and beyond these few points. Just keep in mind, that no system is TOTALLY secure; and arrogance will get you every time.

S

[Ender]

It seems the main security hole in your example file was that the auto-login account's privilege set had execute access to all of the scripts and view access to all of the layouts.

Correct me if I'm missing something, but wouldn't it be effective to:

1. Not use the auto-login feature, or

2. If you do, don't allow access (via custom privileges) to the fields, scripts, and layouts that could be sensitive.

[Singlequanta]

It seems the main security hole in your example file was that the auto-login account's privilege set had execute access to all of the scripts and view access to all of the layouts.

Correct me if I'm missing something, but wouldn't it be effective to:

1. Not use the auto-login feature, or

2. If you do, don't allow access (via custom privileges) to the fields, scripts, and layouts that could be sensitive.

You aren't missing anything at all. That is totally correct.

And; The point is that by default any filemaker solution created "out of the box" will be vulnerable to these issues.

That was precisely why the original poster here was able to so easily circumvent the "opopen" script and execute an arbitrary script on the destination file.

I was hoping to mirror the thought process that a developer goes through when attempting to secure their solution without first understanding the concept of shared authentication tokens.

FileMaker's default file access is to log onto the solution using Admin / no password (which is the full access account)

So; it is important to change your usernames/passwords so that the authentication token can't match any auth token generated by a potential hacker -- in addition to addressing the granular access levels.