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

[Joel Shapiro]

Thanks Webko & Kevin

Webko, your line "The vast difference between SQL and FM is that FM  
effectively has no command line" is key, thanks!

Kevin & Webko both mentioned PHP vulnerabilities:
K: "PHP code for form processing can still be vulnerable"
W: "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."

Any pointers on where I can get more info about these issues?

As to my question "Do people here do that on *all* submittable  
fields?...", the "that" I'd meant was filtering the fields in PHP  
before submission to FM, e.g. using  htmlentities(), strip_tags(),  
etc.  Do people do *that* on all submittable fields?

Thanks,
-Joel


On Sep 4, 2008, at 5:26 PM, Tim 'Webko' Booth wrote:

> 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
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list