Jump to content

Advanced Question/Hack Worries


This topic is 8246 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 smile.gif" border="0

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

Link to comment
Share on other sites

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 ]

Link to comment
Share on other sites

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 ]

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...

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?

smile.gif" border="0

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

Link to comment
Share on other sites

This topic is 8246 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.