1. always validate data (vias form or url) before pushing into the database (regardless of web app or db used)
2. if you are thinking about SQL injection -type attacks, see #1
3. always use the highest security on your dbs and websites.
In addition to Beverly's more general advice, these are things to look for:
- The overall length of the submission should be limited to something you're expecting. One common tactic is to paste gigabytes' worth of text into a form box and see if the hacker can overload the database or otherwise cause a crash.
- Sanitize the data for the data type expected. PHP, like FileMaker, uses type juggling to attempt to guess at the correct data type, but if you need to avoid illegal junk in your number fields (for example), then you should filter it out on input.
- There are some characters that can come across and wreak havoc with your formatting. This can happen from something as innocuous as a user pasting text in from Word, for example. You should always filter out any characters you wouldn't want to see in your incoming data using a regular expression or something like it.
- Although it's nowhere near foolproof, a CAPTCHA implementation of some sort is useful. This prevents bot attacks that simply hit the web form over and over until the server gives up. (A form of DOS attack.)
There's lots of good material on the web about security practices in PHP. Don't rely on FileMaker to do all your work for you; be diligent and avoid issues.
See # 1
Thanks so much for your responses. Been using a number of them, but the way you both articulated your checklists is all kinds of food for thought and much appreciated. The specific question was whether there was any kind of character string that might trip up an FMP database. In the same way trying to include an unescaped double-quote in a csv: eg: "record1","person1","Dialogue:"Hello"" would make illegible and effectively corrupt that dataset, is there a delimiter that FMP uses that could be entered into a field would corrupt the integrity of the file?
What do you mean by "corrupt"? What do you mean by "integrity"? If you're asking if a character inserted in a text field can introduce structural corruption requiring a recovery, then the answer is no. They're just characters, and FileMaker doesn't care.
However, if you're relying on those data to perform some function, or even echoing them back out to a web page, then you may encounter unexpected results. That would "corrupt" the "integrity" of your application, which is why you NEVER accept any unvalidated data from a web page.
If a Filemaker database were a simple data structure, like a CSV, and the UI were not well-conceived, then I'd expect a user dropping the following text into a single field -- "ThisEntry","ThatEntry" -- would effectively corrupt the database; Even though they're just characters this hypothetically flawed FMP DBMS would not be able to distinguish the user's desire to include quotes in the field from delimiters. I'm assuming FMP uses delimiters of some type, more sophisticated to be sure, and I presume the developers were careful to design the system so that it protects against someone who might attempt to drop that delimiter into a field. But it was a question that came up recently, and I wanted to put it out there.
It's not a PHP question, then. All you're asking is, "Can a user paste some text into a field that screws up FileMaker's database structure?"
I've never seen it and I seriously doubt it. Users can paste characters into fields that cause the formatting to go all wonky, but the data in a field have never jumped to a different field (which is what you're essentially postulating) or otherwise "corrupted", in my experience, just because some characters were pasted in.
But you would have to ask one of the FMI engineers if you want a definitive answer.
Correct. The question is hardly limited to PHP. It was just the context in which it came up on our end. Though it seems FMP PHP is a feature that is lesser used (or rather I haven't found too many discussions abut it) and conceivably less vetted. It was precisely my previously taken-for-granted assumption that nothing entered into an FMP field would corrupt a database that actually gave me pause. What's taken for granted safe is often what creates in the biggest security holes. Unfortunately, I don't know any FMI engineers.
A quoted phrase can be placed into a FileMaker field by copy/paste, set field script step, calculated field, manual entry, import (xml for example), by web publishing (Web Direct or CWP w/ any web app)
There is no reason to assume that the phrase was really meant to be a CSV. There is no corruption. It's the phrase 'as is' (quotes and all) being brought in.
PHP, can be use to read the phrase however you deem. I can read a .csv file with PHP and bring the data into any database connected to it for "rows/columns". I can also read the entire file and insert it 'as is' into a TEXT field/column (if the size is not a deterrent). But that's me as web developer controlling the data that I allow.
Read my post again:
1. always VALIDATE the data before inserting into a database.
You as web developer (or one you hire) must be able to perform the above. If you don't take that precaution, then you are asking for undesired data, perhaps, but not corruption.
If you are using just the database in a multiuser situation, you can also validate and control what actually gets placed into any given field.
what of your question has not been answered?
Let’s say, for example, the FileMaker structure were actually XML. And it looked something like this:
” into the field contents and, thereby, monkey things up.
Obviously, the structure isn’t that simple, and there are obviously traps to prevent such a simple phrase from destroying data. But I think this is where he’s asking the question.
Mike, I think your XML example didn't make it fully intact to the discussion, correct? Your hypothetically posed XML-based FM database would be tripped up by XML markup (which I don't see in your post. Only a quote. The quote would trip up my hypothetical CSV-based FM. I wonder if your attempt to post XML somehow tripped up the discussion posting system.)
I agree with databoom. there is no XML structure (sometime post by email munges code).
But if you have an
It can be brought into a field as-is.
However, d, I have a question. Why are you assuming everything with quoted text is .csv? If you import as .csv, yes there are precise rules (as there should be). The same would be true for any database with import-by-CSV. If the data is not valid, it will not import correctly, but 'corruption'? No. Perhaps you mean 'data integrity'?
And there are ways to validate data before actually bringing into your fields. (by web or otherwise)
At some level I'm asking the question: what is Filemaker's internal delimiter (or more broadly, what is FMP's internal structuring system)? I've got no idea what FMP uses as a delimiter. It's likely not CSV nor TAB nor XML. I'd never really taken a look at the behind-the-scenes engineering innards an FMP DB until about 30 seconds ago, and I didn't learn a whole lot in that quick look-see. I saw a bunch of "ﬂﬁ^?" strings. Maybe that's it -- who knows. Suffice to say, I suspect FMP utilizes some kind of proprietary delimiter to structure the data it holds. Whatever that delimiting method is, be it a single character or a string of characters, if that FMP delimiter were permitted to be dropped into an FMP field -- raw, without escaping or otherwise transforming it -- the FMP engine would read it not as text but as a delimiter, at which point your database would stop functioning as expected. So the question that hasn't been answered yet (and probably requires the FMI team to do so) is how secure is FMP from attacks that might seek to corrupt a database via malicious use of the FMP delimiter.
great Devon! that is specific and does need FMI to step in with an 'answer'. I could guess, but you have seen that what gets stored if not human read-able.