Security Loophole

[Anatoli]

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 ]

[Keith M. Davie]

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.

[Keith M. Davie]

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.

[Anatoli]

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.

[Hammerton]

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. ]

[Hammerton]

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

[Anatoli]

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.

[Anatoli]

How is it now with FM6?

Are the doors still open?

[scratchmalogicalwax]

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

[Anatoli]

Thanks.

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

-dbnames is still there.

Oh boy

[jasonwood]

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?

[Garry Claridge]

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

[Anatoli]

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.

[jasonwood]

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!

[Garry Claridge]

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