[FX.php List] [OFF] Filemaker Web Security?

[Tim 'Webko' Booth]

Dear Joel,

I am not a security expert but...

> This is how the client replied when I asked for more info:
> "I keep hearing about "sql injection attacks" being used to  
> compromise web pages. So I was wondering if Filemaker had a  
> notification service about updates and / or security issues. It may  
> be that Filemaker is "flying under the radar" when it comes to  
> malware writers and there is little reason for concern. Given the  
> security of the Internet nowadays I would rather be safe than sorry."
>
> It seems that FMI does *not* provide (decipherable) security update  
> notifications, so I can pass that along to the client.
>
> Investigating "SQL injection attacks" (e.g. <http://www.sitepoint.com/print/sql-injection-attacks-safe/ 
> > ), I'm reminded of Jonathan Stark's DevCon presentation in which  
> he urged (numerous times) that we Filter All Data, incl. the use of  
> htmlentities() & strip_tags()...

The vast difference between SQL and FM is that FM effectively has no  
command line - I do not believe an injection type attack could  
compromise a FM database. You could put whatever code you like into a  
FileMaker field through a new or edit, but that is not interpreted as  
run-code by the FM engine.

Of course, you can get bad data, and if the attacker can guess some of  
the other field names, or knows them somehow, they could over-write  
records, add data in places you don't want, or hijack a delete routine  
to remove records that you want to keep...

It *may* be able to compromise the web server, or at least knock it  
over through buffer overflows etc - that is more a php vulnerability  
than a FM one, and php does issue decent security advisories.
>
>
> Do people here do that on *all* submittable fields?   For all  
> FMFind, FMEdit & FMNew?  Is there some guideline as to when that's  
> more or less important?  Are there other functions you like to use  
> for this?

I do not allow FMDelete - people can mark records as not to show, or  
for deletion later, but I never use an actual delete in any web page.

FMNew I'm reasonably OK with - I do have at least one system where  
someone or something randomly adds extraneous records, but as it is an  
open system on the web for registrations, I expect some level of bad  
data. I do make sure key fields are there and conform with system  
requirements.

FMFind I'm not worried about to any great degree - any system that  
allows a find does so for a reason - I want people to  see stuff.  
Exception is systems where i have targeted user groups, and then I  
start storing some important info about the users into session  
variables to use in each find.

FMEdit I am fairly careful with.
>
>
> Also:
>
> 1) Is a site vulnerable to this type attack when using FileMaker  
> security for logins (internal or Ext Auth w/ AD OD)?  (My guess is  
> "no" since these aren't fields in a web-accessible database...)

It should be somewhat less vulnerable than an open site, as you have  
restricted who can see it. And the authentication side of it should be  
happening inside your network,making man in the middle more difficult.
>
>
> 2) When using records w/ username & password fields for logins,  
> would using the format:
>   $login->AddDBParam('UserID','=="'.$_POST['user_name'].'"');
> be safe enough to avoid these types of attacks, since FM can't  
> process additional code like SQL seemingly can
> (e.g. the submission of: ' or 1=1 -- ) ?

You could be paranoid and do some parsing/stripping/filtering, but  
that's pretty much what I've been doing - it will either match or not  
- php itself may be vulnerable at this point.
>
>
> 3) Are there any such risks within FMEdit calls?  Does it matter  
> whether fields are submitted via radio buttons?

FMEdit is probably the command to worry about the most, especially if  
the recid is ever visible, or your primary key. Like other web  
systems, if people can craft a GET call with either of those, they may  
be able to change data you are not expecting to be changed.
>
>
> 4) The above URL cautions against SQL procedures such as xp_cmdshell  
> and xp_grantlogin.  Do FileMaker or FX.php (or the API) have any  
> such dangerous code?

Not that I aware of.
>
>
> 5) Realistically, if a site is hosted locally, has an SSL cert, and  
> has no links from any external pages, is there much risk of it being  
> found and thusly hacked?

Realistically. Not a lot.
Like I said earlier, I had a FM system with a gaping known security  
hole, and the patch toi plug that hole was never triggered in 5 years  
(apart from my own testing...) - and that one was heavily used and  
publically accessible...

Hope these musings help to some degree