Advanced Question/Hack Worries

[BuddySystems]

I'm developing a new web function for a new product we are releasing. I am very nervous about the web function being hacked. Our solution will be used by hundreds of customers and will have stored credit card information. I have heard about hackers somehow using their own web security databases and other hacks. I am aware of the normally published security precautions to take. My questions are these:

- Considering that our software will be a developed and sold solution, what "above and beyond" precautions would you recommend we tell our customers to take.

- I have seen solutions that limit access via the web security database to the database to browse and scripts only, then do searches in their forms and use scripts to actually edit records. This would seem to be a more secure process, but I have no idea how to move searched data to an existing record. Does anyone know how this is accomplished?

[Anatoli]

Real hacker will just get the data from FM database through "open doors" left there by FileMaker Inc.

Only completely scrambled data are reasonably protected.

Without some filter protection which will not let hacker to get data I will suggest not store Credit Cards data available on Web in FM database.

Is someone more experienced and has some kind of protection?

[Keith M. Davie]

Gee. If only you could run a script which took the data away from the web server and removed it behind a firewall on another machine...

[proton]

quote:

---

Originally posted by Keith M. Davie:

Gee. If only you could run a script which took the data away from the web server and removed it behind a firewall on another machine...

---

Just a thought here. Lets say you have a user database where you store user information (name, address, credit card number, etc.). Now having this web enabled would give a hacker (through open doors left by FMI) access to the sensitive information. So let's say you created a number of user databases (User Online and User Offline) and gave them a relationship based on user code for example. In the relationship you could tell it to automatically create a record in user offline when a record is created in user online, but do not let it automatically delete the record if the record in user online is deleted. Hope you are following.

The User Online Database is web enabled, but the User Offline database is not web enabled. When the user wants to 'sign up'. They create the record in the User Online database (which via the relationship automatically creates a record in the User Offline Database). After successfully creating the record, the record in the User Online is automatically deleted (Using page redirection/Meta Refresh). This way the User Online database only has a record for a short period of time. The rest of the time it is empty. The database containing the actual sensitive data is not web enabled and so can not be accessed from the web. Your data therefore is relatively 'safe'.

Now this introduces another problem. What if the user wants to edit their record? You can not use the User Online database, because from the time you create a new record it automatically creates a new record in User Offline. So your best bet is to create another database: User Edit (which is web enabled) for example. This also has a relationship set via user code. But it contains only one native field (user code). The rest of the fields are related fields pulled from the User Offline Database.

If the user wants to edit their record. They go to the form which automatically creates a record in the User Edit Database. There they can put in their user code (or it can automatically be put in depending on how you work it). When this code is put in the user code field in the User Edit Database, it automatically displays the data from the User Offline Database (example: name, credit card number, etc.). Using this they can edit the record in an Edit form (what they will really be editing is the fields in the User Offline Database). When they have finished editing, they submit the information and they are taken to another metarefresh page which automatically deletes the record in the User Edit Database.

I have thought about the problem of having sensitive data accessible on the web, and this is the solution I have come up with. I am going to implement this in my solution. I haven't as yet though, but as I saw the question here I thought I would throw it out there.

The trick is that the Database with all the sensitive information is not enabled so it can not be accessed from the web. It can only be accessed via other (web enabled) databases, and they do not keep data permanently, only during the create/edit process. So they are mostly empty.

This could probably also solve another problem. The problem of the open door of Filemaker where a user can put in a URL string and get field names and raw data. The User Offline database is not web enabled so you do not have to have export privileges set with the passwords so the data can not be exported, and also it is not on the web.

Tell me if you all think that this is a valid idea. The only problem I can see is that you need three databases instead of just one. Let me know what you all think.

[Keith M. Davie]

Proton, instead of using the relationships to which you refer, the script workaround to the single-thread engine of ScriptMaker which I announced last April does exactly what you suggest and it does it without the loss of data or misinformed clients.

[Garry Claridge]

One of my clients has a web-based price lookup. For this purpose I created a seperate file which just holds item_ids, all other fields are calculated relations to the real prices file, which is not web-enabled and on another computer.

Item_ids are added to/removed from the web prices file via a button/script on the main prices file.

This is only one-way traffic, however it works well.

Garry

[Keith M. Davie]

Garry, with what you are doing, what occurs if two clients make a near-simultaneous call on the script, each requesting a different item_id? Will each get the item_id they request? Or can it occur that both are shown the same item_id?

[Garry Claridge]

Keith,

The script is only run from FMP client on the Intranet. The main prices database has a button/script which either adds or removes the item_id from the web version of the prices database.

However, I have a script running from the web on another project. It runs for less than a second and with about 8,000 clients using that site per week the probability of a collision is very low. If the script duration was longer I would consider using Simplify for a cleaner solution. If the script ran much longer and the collision probability was much higher I would consider another way. (Anatoli, I know your opinion!)

So a script to satisfy the situation for this topic would need to be very quick with little probability of collision.

[Anatoli]

Garry,

I do believe, that collision only occurs, when there is longer script. We never ever been able to trigger collisions with 1-2 line scripts. The only effect was just small waiting time measured in fraction of second.

But even small 1 line script cannot be used, when in next step visitor will try to use result from script step like Find Records. That has to be done from URL or Form request.

I believe you know this before

[ December 08, 2001: Message edited by: Anatoli ]

[Keith M. Davie]

Garry,

Yes, while I understand that the "probability of a collision is very low", have you ascertained if a collision can occur. If a client is misinformed by such a collision would the client know and be able to so advise you or correct the misinformation?

8000 hits a week is over 400,000 hits (opportunities for near-simultaneous collisions) a year.

Denial ain't just de name of a river.

[ December 08, 2001: Message edited by: Keith M. Davie ]

[ December 08, 2001: Message edited by: Keith M. Davie ]

[Garry Claridge]

Keith,

The script I refer to creates a new record under certain conditions. Assumptions:

Script has a duration of 0.5sec.

7,000 of the 8000 clients use this function in a week

Peak hit time, identified as 28hrs during the week.

This is 201,600 half seconds. Hence, the probability of a collision is 0.0347 i.e. 03.5% (I.E. One every 29 weeks)

If a collision does occur the client will have to click the button again.

However, that function is in the process of being changed and the need for a script has vanished. Interestingly this part of the site is a weekly survey, the new interface to this database is via Flash; looks good. One script remains; is is for email purposes.

All the best.

Garry

[ December 09, 2001: Message edited by: Garry Claridge ]

[proton]

quote:

---

Originally posted by Keith M. Davie:

Proton, instead of using the relationships to which you refer, the script workaround to the single-thread engine of ScriptMaker which I announced last April does exactly what you suggest and it does it without the loss of data or misinformed clients.

---

Could you post me a link to that thread Keith? Thanks in advance.

[Keith M. Davie]

Proton, you'd need to look to the cdml forum for April. Things have changed since then. Some of what was then is now different. The entire work is now much larger. I will be talking with an ISP later today (at least that is the plan) about putting something online. I am hopeful that within the next 10 days to 2 weeks I will be able to give you a link to a site demonstrating the use of two scripts.

[Krishan]

quote:

---

Originally posted by Proton:

This could probably also solve another problem. The problem of the open door of Filemaker where a user can put in a URL string and get field names and raw data.

---

The extra database sounds like a great idea. But doesn't Lasso solve the FileMaker "Raw Data" problem?

[ December 27, 2001: Message edited by: Krishan ]