Prevent execution of script

[sphere]

OK i am 1/2 way through recreating a file that i accidentally removed full access from then lost the original file....

Now i have a second question relating to security:

When opening a file i have specified to run the "OnOpen" script i created. The first entry in the script is Allow User Abort OFF followed by trap error messages.

As I have configured the file to run the script at open, is this a sure thing? Or is there some way that a user can circumvent my "OnOpen" script so that they launch the file (with some magic key combination or otherwise) which would cause the script to not execute on launch?

Cheers

[Stuart Taylor]

Here is a bypass example:

MainFile

Admin Account

Username: Admin

Password: Admin

User Account

Username: User

Password: User

Opener

Admin Account

Username: User

Password: User

If you open the Opener File (which has no Admin Privileges to MainFile go to Scripts and execute the script there... MainFile will open without running the opening script and execute any script you choose using only your user privileges...

Scary huh!!!

best

Stuart

PS: I know there is a way around this with access privileges but thought i would show you the gapping hole.

Bypass_Opening_Script.zip

[Stuart Taylor]

You could embed a script step in your startup script to set an ID in an otherwise empty global field that is tested for by every other script before execution and then closes the file if its not met... but im sure you could probably bypass that somehow... Old Advance Man would know how.

[Stuart Taylor]

OHHHH MYYYYY GOOOOODNESSSS!

You can create relationships and set data using this method ... im feeling queeeezy.

Don't know about you but im feeling very INSECURE right now

OLD ADVANCE MAN ... HHHHEEEELLLLPPP!!!

Any way around this one?

[sphere]

Well, i just purchased Old Advanced Mans book....

So its on its way now but i really need an answer to this one asap.

How do you prevent this?

[Steven H. Blackwell]

r is there some way that a user can circumvent my "OnOpen" script so that they launch the file (with some magic key combination or otherwise) which would cause the script to not execute on launch?

There are many ways to bypass on open scripts, the most direct of which is to run any other script in the file externally. Also, you can use the script debugger in some instances.

Steven

[Stuart Taylor]

So there really is no way of stopping a user who has privileges to a script running that script at any time from an external file. hmmmm

That really posses some major issues in terms of security for me, The architecture of your scripts has to be really sorted out...

Getting your head around this one is tough.

Is a closing script a little harder to bypass...

Or a custom close window custom menu?

If so your closing script could send you to a "Logged Out" Layout.

Your Startup script could be the only one that does not test if its on the "Logged Out" Layout before executing... all others could quit if it is.

Sure you could get around this too...

Crash the file for example so the closing script does not perform ... not sure what the startup state would be in, in a networked environment.

Man this is a toughee.

So what kind of scripts must i avoid?

1. Any with "run with full access privileges" i suppose:

• Export Records
• Import Records
• Delete Records
• Delete All Records
• Replace
• Create Records
• Set unautorised data

Changing Menu Sets Without testing the layout is valid

Auto logging in as a new user

Auto Creating a new user with full privileges even one that gets the data from a field as this can be read or set from the other file.

Sure there are many more...

Funny after you stick all the restrictions in for security your file starts to write itself...

Layouts really do become cosmetic and are in no way useable for hiding data ... simply presenting it.

Security Really is the foundations of your house... you really can't build it in last.

I really wish i knew every hole now.

best

Stuart

PS The simple answer is probably that you can't prevent it!

Edited November 15, 2006 by Guest

[Steven H. Blackwell]

So there really is no way of stopping a user who has privileges to a script running that script at any time from an external file. hmmmm

Now, I did not say that at all. Script behavior can be made conditional based on parameters. Script behavior can be controlled by setting granular level privileges on the scripts themselves in the Define Privilege Set.

I do not have time today to go into all this; nor is the FM Forums likely the best venue to deal with these type questions. But there appears to be sufficient interest, not to mention obvious need, so I will pull together something that addresses these type issues and release it.

Steven

[Stuart Taylor]

Hi Steven,

That would be amazing

many thanks,

Stuart

[Singlequanta]

Hi Steve;

I'm a little confused. Can you please explain what you mean by "granular level privileges on the scripts themselves in the Define Privilege Set?"

That doesn't make any sense to me.

Steve

[Singlequanta]

Stuart;

There is a relatively simple way to "Wrap" your script so that it becomes difficult if not impossible for someone to execute the script without your permission.

Email me for details: steve AT grant dot cc

[Steven H. Blackwell]

In the Define Accounts and Privileges, in the Privilege Set definitions, under the Scripts section, developers can assign different levels of access privileges to scripts one by one.

Steven

[Stuart Taylor]

Does this constitute an Eratz/insecure model?

Remembering that the objective here is to stop the user from executing a script from an outside file ... a script that with there user privileges they have permission to execute.

Here is a simple non bypass example:

MainFile

Admin Account

Username: Admin

Password: Admin

User Account

Username: User

Password: User

Opener

Admin Account

Username: User

Password: User

Bypass_Opening_Script.zip

[Singlequanta]

Ahhhh Gotcha - the "custom privileges" for scripts under Data Access and Design....

[Stuart Taylor]

No not exactly...

The Account can be assigned a privilege set ...

The Privilege Set can be assigned set restrictions/Access levels...

Extended Privilege Sets allow you to customise Privilege Sets via calculations.

Non of these can prvent you from performing a script at any time if you have the privileges to perform the script.

My last example simply adds a simple parameter to the script button or method of execution which i believe can only be tested for if you click on the button or custom menu item therefore if you perform it externally no parameter could be attached.

I still do not know if this is eratz or not (ie could it be over riden or easily read by a posible attacker/bypasser.

?

Stuart

PS: I am surprisedat the lack of file downloads on this topic people are either very knowlegeable about security / do not care or think its to difficult to deal with...

if the first is not true then the fm community ... like me ... needs a kick up the arse.

Edited November 19, 2006 by Guest

[Steven H. Blackwell]

What download are you talking about?

Steven

[Stuart Taylor]

Hi Steven,

Was simply refering to the number of times the files in this topic have been downloaded...

If something stimulates the community you can usually tell by the number of times the files in the topic have been "viewed".

Just find it interesting that the count is not that high as these are surely critical issues being discussed.

[Steven H. Blackwell]

Didn't know there were any files for download, hence my question.

Thanks.

Steven

[Singlequanta]

I think it is generally a lack of concern or knowledge.

I would doubt your average FM developer has much knowledge about security. Heck, I have downloaded sample solutions from reputable designers who have employed ridiculously simplistic and completely insecure security methods.

I seem to recall a conversation with Steven about four years ago about an Ersatz based solution where i "dared him" to crack it -- which he of course did in less than five minutes : Ever since then; security has been first and foremost over schema and functionality.

I think Steven has a lot of very good advice and perspective on the matter; And his approach is not complicated to understand.

Anyway, thats enough of blowing wind up Steve's skirt. Go out and buy his book. It's well written and a must for anyone serious about securing their solutions.

Oh - buy the way Steve -- I dare you to try and crack my solutions now! :P

[Stuart Taylor]

Let the games begin.

:joust:

[Singlequanta]

Ha ha ha!

No; lets not and say we did.

[Steven H. Blackwell]

I seem to recall a conversation with Steven about four years ago about an Ersatz based solution where i "dared him" to crack it -- which he of course did in less than five minutes Ever since then; security has been first and foremost over schema and functionality.

Well, I have had so many of these discussions in the past 5 years that it's difficult to rememebr the details and the when, who, and where. Contact me off line if you like to refresh my memory here.

I don't like the role of "solution cracker" at all; I prefer the role of security architect. But as such, I have to be far more concerned about where something will break, than about where it works. I spend a huge amount of time wrestling with these issues.

FIleMaker Security: The Book and subsequent efforts were attempts to codify some of this information and to make it available to the FileMaker Pro development community.

It seems a never-ending task. It is, indeed, as one extraordinarily knowledgable observer of this activity once remarked to me, "...a never-ending arms race...."

Steven