NOT sharing a related DB with WC to avoid security issues

[Steven H. Blackwell]

Read the web security white paper on the FMI site.

Second, turn the WC off on the copy of the file on the server.

HTH

Old Advance Man

[cinolas]

Thanks for the reply.

I have read the Web Security white paper...

And removing WC sharing in the copy on the FMP server is the first thing I checked...

Unfortunately, the WC sharing is off in the FMP server local file... Still, everytime I open a copy on my WC box, it says the WC is on !

Any other idea ?

Any help is greatly appreciated !

Since I can only open the sharing panel with a script (and not change the settings) I'm down to unchecking manually everytime.

[Keith M. Davie]

I remove data using scripts.

http://simplifyfm.com:591/

You can too.

[cinolas]

Hi,

The security loophole topic has opened my eyes on some security flaws of my system. Turns out I was serving security sensitive data with web companion and, using the force command, was able to access it.

Thanks to this forum I have now secured the data.

One problem remains...

To solve the security issue I stopped sharing the DB containing the sensitive data altogether. I now use a different approach using a relational DB. Off course, because I need to access the data, the sensitive DB is still open on my FMP Server but not shared by WC.

BUT whenever I have to close the DB and re-open it, the WC sharing (in the sharing panel) is re-activated ! I have to manually uncheck the option. No matter how I go at it, the WC sharing always comes back !

Can someone tell me what I'm doing wrong ?

How can I convince FMP NOT to share this DB with WC once and for all ?

Any help is greatly appreciated !

Thanks

[cinolas]

??? What do you mean "remove data using script" ?

Do you know a way of setting WC companion sharing for one file using a script ? (on a PC so no AppleScript)

Thanks

[Keith M. Davie]

"??? What do you mean "remove data using script" ?"

At my site, as an example, when someone registers (and this is just a simple example using very limited data) they provide a first name, a last name and a user name. That data is used to create a record in a signon_.fp3. A password is then entered and a script is run which first confirms the uniqueness of the password. If it is approved then the data from that record is removed to at least two other files. At least one of those files is not connected with WC and does not show as part of the solution. In my web site exampel the First and Last names and the password are removed to a db file away from web access entirely (not connected to WC). The username is kept available to web access and is available for display in the solution. When the data has been removed to other db files, the record in signon_.fp3 is deleted by the script. The "delete" attribute of the Web Security does not need to be allowed because the script will handle the delete.

Similarly any "sensitive" data can be removed entirely from web access. Only data pertinent to the solution needs to be kept immediately available, such as the user name and a unique identifier (so that e.g. Paul Simon the song-writer can be distinguished from Paul Simon the Nobel-winning economist as well as from Paul Simon the Senator).

In the second instance of a script at my site, the user must login with the username and password. This data is ultimately confirmed by a script using data from the files which are not web accessible. In the process a subscript is run which increments a number.

Both scripts are protected against multiple requests and will display the proper message and allow the client to try again should ScriptMaker be in use at the time of original request. In this way the client is properly informed and no data is lost because a script did not run.

And that is what I mean when I say I can "remove data using script". It works. It is very cool.

Please visit my site: http://www.simplifyfm.com:591/

[scratchmalogicalwax]

As OAM said........if you close the database on server open it on a client disable WC close it on the client then open it again on the server WC should remain un-enabled when you open it thru hosts

[ March 15, 2002, 03:31 AM: Message edited by: scratchmalogicalwax ]

[Keith M. Davie]

I see things in a different perspective quite often so I say things in a "shorthand" kind of way. Let me expand a bit on my point of view in re: what you originally posted.

"Can someone tell me what I'm doing wrong ?"

I can only tell you what I have done differently. I remove selected data using scripts. I remove that data to db's which are not set for Sharing and are stored elsewhere on the HD. I move other selected data to db's which are for Web Sharing. It does not include sensitive data per se, but it does allow the necessary data to be displayed vis a vis the browser. Part of the difference may be that I am serving FMPro 4.0v3 using one machine, which I doubt makes a difference. I do not use inlineactions for this solution because they are not available in 4.0v3.

How can I convince FMP NOT to share this DB with WC once and for all ?

When you set your Preferences, the WC is set under Application Preferences. Thus the FileMaker Application is set for WC.

In my soluiton I do not have AppleScript enabled and so I can set my remove/remote db files such that I do not activate them for Sharing which keeps them from browser accessibility. They do not appear in the list of db's named in an app. like Chazboi's - even though they are open. They have never presented the problem of which you wrote.

Because you are using inlineactions it may be that FMPro somehow reads that to mean that Sharing must be set. I don't know, so don't quote me on that.

"...because I need to access the data..."

This may be part of the problem also. Instead of direct access through a db hosted solution have you considered accessing the data you need to access via a browser solution? It would seem to me easier to write a few format files for administration than to integrate a browser solution into a db hosted solution (or vice versa).

[cinolas]

Keith This is very interesting and I have read it in another thread but it doesn't answer my question...

scratchmalogicalwax : That's what I first did... I tried opening the file locally (not through FMP Server) and the web companion option was already disabled. So I tried opening the file in a client (through FMP server) and, again, the web companion option was already disabled... Still, when I open it on the WC box WC is Enabled... driving me nuts...

Thanks for your help,

Any suggestions are VERY welcome...

[scratchmalogicalwax]

that is really strange ....... I always have the opposite problem I always forget to enable WC on new DB's and wonder why Lasso Remote can't see it

What Keith is describing is a method for adding security to your solution which sounds interesting ..... however you should be able to run a DB on your WC box without the FMPro client automatically enabling WC on that specific DB while running WC on other DB's (I do this myself).......

I'll do some testing with mine ...... but I have never come across this problem myself

[ March 22, 2002, 01:28 AM: Message edited by: scratchmalogicalwax ]

[cinolas]

Keith: Like I said this sounds really interesting and all but my problem right now is to convince my WC box NOT TO SET WC SHARING FOR THIS SPECIFIC DB. The rest of the security issue is dealt with. My security sensitive DB is open on WC box but since it is not shared with WC, when probing it with the -Findall tag, one gets the 973 error message and nothing else. And I didn't have to setup some kind of script related data transfer solution. Not saying that it's not interesting, it's just not necessary.

scratchmalogicalwax Let me know if you get results ! It seems to me it should be pretty easy but I took it from just about every angle and my WC box is just really set on the idea of sharing the DB... I had a spark of hope when I realized that it might be because the client app I was using to make the change had WC disabled. When I activated WC (in app/pref) the WC sharing for the file enabled it-self ! So I check it off hoping for the best.... but same deal.

[Keith M. Davie]

cinolas, thanks for that very informative response.

I understand the problem you are describing. My post was merely to point out what I have occurring since I do not have that problem. I figured that you could compare what I wrote with the intricacies of your soluton and maybe see something which I was unable to see. Sorry my info could not be of help. Maybe next time.

[scratchmalogicalwax]

Hi cinolas,

My set up:

Data server = stripped down Server OS 9.1 and FMPro Server 5.5

Clients = stripped down OS 9.2 and FMPro Unlimited 5.0 ( WC 5.0v6)

sadly I cannot recreate your problem.....

here is how my system reacts to WC being enabled and disabled on a database open on FM Server and then opening it on FMPro Unlimited thru hosts. (the WC is obviously installed and enabled in my FMPro Unlimited clients)

WC enabled on database (before opening it on server) - DB opened on, and being shared from, FMServer:

Open the database thru hosts and the WC is enabled by default as expected. (File Sharing...)

The WC can then be disabled thru the Sharing Dialog box without effecting WC on other instances of the database open on other FMPro Unlimited clients.

If the database is closed and reopened thru hosts WC is automatically re-enabled as expected

WC disabled on database (before opening it on server) - DB opened on, and being shared from, FMServer:

Open the database thru hosts WC is disabled as expected. (File : Sharing...)

WC can be enabled thru the Sharing Dialog box without effecting WC on other instances of the database open on other FMPro Unlimited clients.

If the database is closed and reopened thru hosts WC is automatically disabled as expected.

If your setup isn't working like this then im not exactly sure what could be wrong beyond your FMServer or Unlimited going mad also make sure you have the latest versions of WC although I have never heard of older versions of WC doing this

hope this helps

[ March 26, 2002, 09:33 AM: Message edited by: scratchmalogicalwax ]