I only KNOW that it affects FMP 4.1 and above. I haven't tested it on any system previous to 4.1. I do know that the feature was included for use on the Claris Home Page assistants. So I assume that it will be on all versions that came out after Claris Home Page 1.0 was released. I don't think it matters though!

Ok, Let's face it. This is perhaps the most significant thread which was started in 2001. Thanks chazboi.

I understand how to force data from any db accessed through WC, so the data is not protected.

However chazboi you wrote, "If they do have access to scripts on the Security Database, they can perform any script as long as they know the name of it, which with this knowlage you can find out easily."

How can they perform any script as long as they know the name of it? I've tried several things and am unable to get those results.

-----------

And for the question of FMPro 4 being accessible in this way, it most certainly is. So I know when I announce my address next week, probably Mon, several of you will be trying to find out what you can there.

One thing I know is that certain db's which are pertinent to my solution are not visible as they are not WC connected.

Regarding FMPro 4.0 on the web, chazboi's d-base will show the three FMPro security databases in the list of db's. Interestingly the fields and layouts will not appear.

Similarly, using the force code on these three db's to try to reveal the data I have been unable to show anything but error codes.

Clearly then, FMI has a way of keeping this data private. Makes one wonder why we cannot do the same. But if we know how to do it, we could probably figure out how to undo it, including FMI's solution.

Hey John.......

I have been trying to look at my lasso databases and layouts and I can't get as far as you did.

The D-Base program does nothing but return 103's in fact the only thing that works is the

http://thehost/action.lasso?-dbnames

through a browser.

Im probably doing something incorrectly but it does seem that lasso is not as vulnerable as WC alone.

The "Web Security" database may well be using an "Exact Match" restriction on itself. Hence, combined with "Don't Show" for each of the fields, you will not see the data.

Have, many secure accesses.

Garry

We are in final development stage of our Security Filter for Windows and FM5 Unlim. It works very fast taking just 1% of power from total FM load.

Last build (131) sustained heavy load from two browsers in JavaScript loop and 3:1 ratio of get/put pages.

The test is on 2 PC connected via 100Mb Ethernet, so it is at maximum WC output per second.

It is filtering all "hacking" syntax we know and displays just simple HTML error page.

Garry, thanks. I forgot that I could look there. Duh!

Hey all..

Keith: I started the thread because I was concerned that WC was insecure. Since then I have learned that as long as the correct security measures have been implimented, it doesn't matter that the database information is available over the WC. Hopefully Anatoli's Filtering solution will solve the problem once and for all.

Still the thing that concerns me is that FileMaker don't tell people about this. If I had my way, the WC would have at least some ReadMe file that explained the importance of the WebSecurity DBs.

Their excuse for this is the XML support in FMP 5.5 that is accessable over the WC. If they were sensible about this, they would have the option to allow people to access this info.

scratchmalogicalwax: D-Base only works on WebCompanion so you won't be able to get anything out of a lasso server.

Thanks for your comments. Good luck with your filter Anatoli.

Keep it secure.

Charlie

Chazboi

I cannot thank you enough for starting this -- so far -- best thread!

Although we are not storing Credit Cards details, I just hate when everyone equipped just with browser can hack something so easily.

And as I wrote before -- FileMaker Inc. is still suspiciously quiet

Anatoli, "...FileMaker Inc. is still suspiciously quiet". Probably based on advice of their legal weasels. Their license probably denies any responsibility on their behalf. All software seems to be sold this way. A disclaimer is cheaper than good workmanship.

True!

I am not gonna try to hurt them with lost sales but it will be interesting reading on many sites dedicated to the security issues.

I think, Microsoft is trying harder. At least they do issue security patches quite soon after something is discovered.

Looks like quite a lively subject you have going here!

I

First, use 5.0v3, not 5.0v2.

Second, do not run FMU on the same machine as FM Server. Give both their own machines.

Third, do not put the database to be shared into the web folder. It doesn't need to be there. If it's open and if it's set to share via the WC, then it will be broadcast just fine.

All that said there are substantial security issues. At best don't put anything into the database that you do not want to be seen.

Also, if you avoid setting the database to multiuser you can reduce the chances of its being accessed in other ways.

Old Advance Man

RE: Second, do not run FMU on the same machine as FM Server. Give both their own machines.

That is big issue on Mac OS.

If you have powerful machine with good preemptive multitasking, it is not so problematic. Especially with 2 or more processor hardware.

From what I understand, if you use chazboi's D-Base you can get a list of FMPro db files which are being served through WC (doesn't seem to matter where they are placed) at a given site. Once you have that list you can force all the records from any/all of those db files.

Thus it would seem that one would want to keep perhaps only one file connected through WC such that it has no "privileged" data stored in it. That db should be used to access other db's which are in no way connected by WC. Ways to move data to other files seem to be inlineaction and scripts. Scripts require a workaround to avoid data loss and misinformed clients should a near-simultaneous request occur on any script(s). Inlineaction is not possible in FMPro 4.0.

quote:

---

Originally posted by Anatoli:

RE: Second, do not run FMU on the same machine as FM Server. Give both their own machines.

That is big issue on Mac OS.

If you have powerful machine with good preemptive multitasking, it is not so problematic. Especially with 2 or more processor hardware.

---

Sounds like a dual processor G4 running OSX to me!

128bit processing and now with a decent OS watch out x386

quote:

---

Originally posted by scratchmalogicalwax:

Sounds like a dual processor G4 running OSX to me!

128bit processing and now with a decent OS watch out x386

[/QB]

---

If the G4 and MacX are as good as Apple claim, then you need only single G4 500MHz to have the same (fast) sufficient performance like Pentium 1GHz and NT or W2K.

hmmmm true............in theory ............but I'm waiting to see exactly how WebSTAR V and Lasso V perform especially with regards to security.

Hopefully BlueWorld have had a look at the security loop holes when using Lasso with filemaker WC.

It would be interesting to hear from anyone who has this setup.......

The ability to remove/disable actions or tags such as -Databasenames etc. would be nice.

To be honest i don't think I have ever incorporated any of the "loop hole" tags / actions mentioned here in any of my Lasso / FMPro solutions......

Thanks for all your responses!

A couple of follow up questions:

1) I can update to FMUnlimited 5.0v3 easily enough, but is are there significant security advantages to warrant paying the upgrade to FMU 5.5?

2) The points raised about running FMU on the same machine as FM Server seem to be performance rather than security related, yes?

3) Otherwise it seems that a relatively secure solution would be to have one file with unsensitive data with Web Companion enabled. And then isolating sensitive data on a related, but disabled Web Companion file. And the fields from that file that you want made visible on the accessible file would be, correct?

Keith, I

[fmp-inlineaction] is a cdml tag in Pro 5.+ which is not in 4.0. You will find it in your copy of cdml reference.fp5, available online if you don't have it. I don't have the address, but it is elsewhere on this forum, or someone else can give it to you. There are several threads about this tag, mostly on the cdml forum.

As to upgrading to 5.5, I can't tell you the differences. I did note a .pdf at FileMaker which mentions that a few cdml tags which were available in 5.0 have been removed from 5.5 because of some problems (possibily security issues, I don't really recall). Again, that .pdf

has been referenced recently by me on one of these forums. I don't recall the exact address at FileMaker or the name of the .pdf. Perhaps someone else can shed further light on your questions.

RE: Inlines

code:

---

What it does

[FMP-InlineAction] allows the processing of multiple CDML requests

during the processing of a single format file.

The [FMP-InlineAction] tag takes as its parameters the URL-like format of the name value pairs for a CDML request.

All further processing of the format file then continues as if the inline request started the processing.

When the [/FMP-InlineAction] is processed the request that was in effect previously is restored.

Any -Format tags are ignored in the request. [FMP-CurrentError] contains the error result number of the last [FMP-InlineAction].

Any FMP-ContentMIMEType or FMP-Header tags inside any [FMP-InlineAction] tags are processed as if they were not inside any [FMP-InlineAction] tags.

[ February 13, 2002, 01:37 PM: Message edited by: Anatoli ]

For those (especially newbies) who are joining this conversation late, there is another thread on the using filemaker online forum entitled "web security db and -find" which is quite related to what is being discussed here. This thread is also worth the read.

I GOT TO SHOW YOU NO STEENKING PATCHES!

I have been advised by FMI's Tech. Dept.:

FMPro 4.0 is vulnerable to D-Base (and similar apps using HomePage source) and to the force command ("...&-format=-raw&-findall").

Just to be clear about this, D-Base is not necessary per se. One can usually find ample data from browser "View" to allow one to perform such nefarious acts.

There will be no patch for FMPro 4.0

FMPro 5.0:

If one assigns a password to the db file (File / Access Privileges / Passwords) D-Base will not penetrate unless the password is applied. The force command will not apply unless the password is applied.

An aside about ugliness: Let's say you have set your site as in a recent example on these forums. That is, in order to show data by a current date to the client on the first page which the client views, you have started with a blank default.htm which reloads (including the database) with a meta refresh. But wait. We are now going to apply FMI's password protection solution. With the password solution which FMI offers the client will get the FileMaker generated window asking for a username and password before seeing any pages. How will the client know that a username is not necessary to enter? How will the client know what the proper password is? Hmmmmmm...? Remember, this password is FMI's solution.

Since the solution of the above "aside" will not work, let us now say that you have a default page on which you inform your potential client that they will need to enter a password into a window ("Click here and enter the password 'ThisSux'"). Your client now does as instructed an can enter and roam your site. (Sure you may have a solution which requires their registration, including another password.) But that initial password was put in place as FMI's security solution.

The only problem is that once they have entered the password and gained access, D-Base will read all the file names, etc. of FMPro 5.0. And the force command will cause the display of all the data from all the fields of all the records

There will be no patches for FMPro 5.0 since FMI considers 5.5 to provide all patches for 5.0.

According to FMI, FMPro 5.5 is not vulnerable to D-Base and to the force command - provided that you set a password to your db files.

Of course, anyone desiring to enter your site will need to enter that password, same as described above. (As FMI has it now constructed, "...it is a nessasary step of HTTP authentication to provide encrypted security standards.")

I am told that D-Base will not reveal information from 5.5 db files which are so formatted. I am further informed that the force command will not cause record data to be displayed in FMPro 5.5.

I do not have 5.5 at this time, so I cannot test this myself. I am hopeful that a concerned user of 5.5 will confirm this for this forum.

Probably not.

WSC on A will send those hacking requests to B, so you are not blocking that.

BTW, we are now running our FM Security Filter 4th day and it looks like final solution. It is on PC NT and our programmer is saying, that MacX version is feasible, but not Mac OS.

If someone is interested in testing, contact me.

Security Problem Solved - (for MACs)

The following set-up thwarts both the impressive D-base program and the use of -raw, or for that matter any other URL packet data that execute hacks.

IPNetSentry on box A running a server and the web server connector (the folks at sustainable softworks will tell you how to configure it - ask for Brad) http://www.sustworks.com

IPNetSentry on a box B running FMPro. Set IPNetSentry to block all requests other than those coming from box A

[ February 21, 2002, 12:31 PM: Message edited by: Dr.J. ]

Topic: web security db and -find

Keith M. Davie

Member

Member # 100

posted February 16, 2002 08:02 AM

Anatoli,

In the test you speak of "Test page is using -max 50 and will display not only found

records, but also chapter with 1-3k text...". That is what is being displayed., and in fact

your test is running at this heavy load to display search results.. The test you are running

is not creating new records which are putting in large amounts of text and then displaying

the results.

You also said, "I doubt, that shifting data in and out with scripts will work for hours in this

test, consistently and in average speed 6-9 request per second."

About the concept of shifting data for hours, in the test you are performing don't you

think a better test of capability would be to create a new record which includes 3K

paragraph of text which record is then displayed in the results screen which as you are

already doing? How many hours would that run at 6 - 9 requests per second, either before

there was an overload or until FMP ran out of room? Search is one thing. New record

creation and search is more demanding at heavy load.

Theoretically, at an average speed of 10 requests per second (faster still than your test)

the request rate could be described to be one request every 100 milliseconds.

Now you suggest that 50 milliseconds is a long time for a script. But speaking in this

theoretical way, that would suggest that 20 scripts of 50 milliseconds each could be

handled in that second.. Far faster than the test you are running.

When done properly the data handling is being controlled by the script such that there is

no data loss within the databases and even to the display page. And should a "collision"

occur at ScriptMaker, the workaround ensures that the client(s) whose script does not run

is appropriately informed and given a chance to resubmit.

I might point out once again that I have been to more than one website where I have

encountered the need to resubmit a request because it was stated the load was heavy.

And these sites are running main-frames.

I might point out that when one receives a message such as I have encountered that

message has been hard-coded into the solution. The message may or may not be true.

That is because the client does not need to know the actual source of the problem.

At my site, if you enter a name to register (hey try it with some made up names), the

next page asks for you to enter your favorite password (so make up a few). But before

you enter a password click the button. This will give you a page where you can (re-)submit

the password. This is the same page you would get if there were a conflict at ScriptMaker.

My comments on that page reflect this.

Within my solution, should one cause a conflict at ScriptMaker, there are a couple of

different responses. It depends on where one is when the conflict occurs. In one scenario

of a conflict the password is hard coded into the page and displayed with a button which

allows the resubmit. All the client needs to do is click. Of course, one would be unlikely to

handle a clients password in such a manner, but the example can be extended to

handling data in other fields.

Anatoli (and others), please feel free to visit the site and try to cause a ScriptMaker

conflict by making multiple submissions.

I might also point out that I earlier posted four threads on the cdml forum about

Entertaining a script. I provided all the information necessary to create a simple db or two,

and all the code for the format files. This is so that the Developer who does not

understand the problem can create the files necessary to see the problem first hand. That

demonstration also shows the design problem of running a ScriptMaker script which loops

on the www.

Sure, setting up the db's etc. will take some time, but learning takes time. And if you are

at all interested in the power of scripts you will need to know all this and more.

The workaround at my site looks quite simple when you click the button and get the

results. It is extremely complex in its construction. The workaround affects the way things

are done in very unusual ways.

[ February 16, 2002, 08:07 AM: Message edited by: Keith M. Davie ]

--------------------

SIMPLIFY ...

Keith

Posts: 585 | From: Jerome AZ | Registered: May 2000 | IP: Logged

Anatoli

Member

Member # 374

Member Rated:

posted February 16, 2002 02:20 PM

Read again:

Second page is triggering third page, which is submitting page full of data to generate

mew record in FileMaker database in size 30k.

RE: But speaking in this theoretical way, that would suggest that 20 scripts of 50

milliseconds each could be handled in that second.. Far faster than the test you are

running.

You didn't count the latency of FM. There are slight delays in between operations.

Furthermore, still not a single word from you about logic and there is the main problem:

When you finish the transfer, and you release the thread, there is another 1-5 CDML

requests waiting in cue and one will be picked as the next. Thus all results shown in FM

are lost.

In FileMaker code is not single mechanism which will halt ALL request from WC plugin until

another job is finished. Did you tried to work in FM Unlimited while connected to web with

some load? That is simply impossible.

Yes, if there is some kind of flag, which I can set, and everything will stay in cue until I

released this flag, then yes, we can do lot. In multi-user scenario it can be done with

scripts because everything can be processed with scripts.

But not in WebCompanion unless EVERYTHING is running through scripts and not from

CDML. In that case I will need 10 RAIC system to replace single Unlimited.

--------------------

Anatoli Kohout

FileMaker support for East Europe

$30/hour FM programming

$60/hour FM consulting

Posts: 1580 | From: Prague | Registered: May 2000 | IP: Logged

Keith M. Davie

Member

Member # 100

posted February 16, 2002 08:01 PM

Gee Anatoli, I'm not using Unlimited. I'm using FMPro 4.0v3. You mean there is a

problem with 5.0 that does not exist in 4.0 Some improvement, huh? Good ol' FMI.

Yes my scripts are causing the proper displays.

Please feel free to visit and test the site as described therein. You have not done that so

far.

--------------------

SIMPLIFY ...

Keith

Posts: 585 | From: Jerome AZ | Registered: May 2000 | IP: Logged

Anatoli

Member

Member # 374

Member Rated:

posted February 17, 2002 04:35 AM

It is the same as in v. 4.

Ask someone to work through web and you try to work behind that same (web serving) FM

directly.

If you run script to do something, then come web request producing another result and

then your another script will continue with e.g. foreign found set, you'll end up nowhere.

No one can force web users to work in linear fashion. Someone will display his found set

and immediately will progress. Another will display his result and will wait 10 minutes

before progressing. You will need some kind of history tracing.

And still everything must run through single script from top to get data consistency. And if

someone will make request and the script will cancel that request or the web request will

cancel the script, everything will be in mess.

Good thing with WC is that in web work it is keeping the history and always will start and

end single request without interference with another request.

Scripts no. They start and end, wait and always assume, that only single user is working

with the solution. Found set will stay days until another user request.

I see 3 or more find requests with different found set per second. You cannot rely on that

in scripts.

Again, to run script in split second, the only script in solution the same for all users works.

I am using that because of bad date format in WC. But it is setting only the flag for

today's date.

But to run any logic through scripts without history, no way.

--------------------

Anatoli Kohout

FileMaker support for East Europe

$30/hour FM programming

$60/hour FM consulting

Posts: 1580 | From: Prague | Registered: May 2000 | IP: Logged

Dr.J.

Junior Member

Member # 5840

Rate Member

posted February 17, 2002 11:39 AM

RETRACTION

My apologies. After further testing with D-Base and the url hacks posted on this list, it

appears that IPNetSentry is protecting the FMserver machine as I had said, but the hacks

can access the data on that server via the server/web-server-connector machine, just as

long as they are not password protected via web security database. Password protected

dbs return a signle code number "971" and no data. However, the presence of the

password protected dbs are revealed by D-base. I will try to use the security features of

webstar to block the url hacks.

Posts: 19 | From: Alabama | Registered: Dec 2001 | IP: Logged

Keith M. Davie

Member

Member # 100

posted February 17, 2002 03:16 PM

Anatoli, you are still talking theory.

Well, the fact is that you or anyone else can test your theory at my website. You or

anyone else can make (or attempt to make) near-simultaneous calls on one or both

scripts. One can also call other actions at the same time. All one needs to do is run two or

more browsers on ones' 'puter at once, or coordinate with a few other people to make

(near) simultaneous calls on a script. I've already tested the site quite well and am

satisfied with the way the scripts run successfully.

The only issue is that of security, as has been discussed in this thread and elsewhere.

And that security issue applies to all of us who are using FMPro through WC.

Still, you have not been through the site even once to use it, much less 6 to 9 requests in

one second (your test). At some point your theory must meet the road. You say, in theory

it can't be done. I say at my website it is being done.

If you can set up 9 or 10 browsers so that you can click on a Run Script button, then in

theory, you can cause my scripts and workaround to fail. The scripts from those buttons

are running at ~185 millisecond and ~245 millisecond when served at 500MHz. In your

theory, the latter can be crashed with as few as 4 requests per second. I previously tested

this over the web when served at 266 MHZ and the scripts were running in excess of 1000

milliseconds. In that testing requests were being made from 10 browsers.

Don't you think it is time you tested your theory now that you have the opportunity?

http://simplifyfm.com:591/

--------------------

SIMPLIFY ...

Keith

Posts: 585 | From: Jerome AZ | Registered: May 2000 | IP: Logged

Anatoli

Member

Member # 374

Member Rated:

posted February 17, 2002 04:17 PM

I am not talking theory, no. I am programming solution every week or two. Without

scripts. With scripts, which I've tested 3 years ago I cannot do that, it didn

That will work, if it will not block any useful requests. I was wrongly focusing on IPNetSentry on a box B running FMPro. Set IPNetSentry to block all requests other than those coming from box A in your post.

How is it now with FM6?

Are the doors still open?

Just got it so havent tested in yet ..... I will let you know when i get it running..... filemaker forgot to put the install codes in the pack ........ hmmmmmmmmmm

Thanks.

I've downloaded just the trial and I didn't have much time, but the first

-dbnames is still there.

Oh boy

I just read this entire thread and I don't believe this question has been firmly answered...

It is possible for someone to get access to field names and layout names, but CAN THEY GET DATA?

re: It is possible for someone to get access to field names and layout names, but CAN THEY GET DATA?

By using the Web Security Database you can prevent anybody from accessing data. You can even control which fields have access rights.

However, it does lack some functionality which would make working with the Web Security database a lot better!

All the best.

Garry

RE: It is possible for someone to get access to field names and layout names, but CAN THEY GET DATA?

Usually yes. IMHO that was the reason FMI stopped using FileMaker for most of the tasks.

What Garry is saying is true, but in most cases not very practical. If you want to have very private data, you have to use strict validation like "exact match".

Try that to see if it's work for you.

Also site like http://www.databasepros.com was running unprotected. I have asked the owner about this and the reply was: "However, there is no way to prevent a hacker from seeing my databases. Good thing is all the information on my web site is free anyhow. I do have passwords so nobody can delete records. Other than that, there isn't much I can do."

I think that anybody should protect my record especially my email.

If you want to have very private data, you have to use strict validation like "exact match".

And by this you mean that whenever I want a user to be able to search for "their" record, I should require exact match in the field so they are unable to find other records? In other words, without exact match, a user could search for ">0" and find everything.

But... that only allows them to see data in fields which I am making available on the web any ways (not really a HUGE concern, though nice to know about). There is no way for them to see inside fields that I have not even put in the web companion layouts is there? That would be a BIG concern!

Re: There is no way for them to see inside fields that I have not even put in the web companion layouts is there?

Not if you restrict the fields using the "Web Security" Database.

All the best.

Garry