Is this a secure solution?

[cmartin]

Hello all-

I have attached a PDF diagram of the two routes to access my databases. I would love it if a few people could chime in about the security issues. My database holds information that is sensitive and security is important. In the attached diagram, I am assuming that I could set FileMaker unlimited to only allow access to the Web Server IP address. Would that work? Is a system set up like this vulnerable to the xml security issues I have been reading about (ie -dbnames,etc)? All of the record level access is not handled through the Web Security database but rather built into the system.

Thanks-

Courtney

CRUAccessDiagram.pdf

[Garry Claridge]

Courtney,

The WSC route can be made very secure. As you say the access can be set to the WSC only.

The FMPro client access through a VPN will also be as safe as the VPN.

The general concept looks OK to me The WebSecurity database can be used also to limit field access.

All the best.

Garry

p.s. Anatoli had a product, like a WSC, which filtered out certain tags like "-raw, -dbnames" etc.

[Anatoli]

RE: p.s. Anatoli had a product, like a WSC, which filtered out certain tags like "-raw, -dbnames" etc.

It is 90% finished works OK for months without crash on Windows.

As soon as you put FM databases through WebCompanion and Unlimited on web, consider them as "public domain".

To block and protect your data:

you need programmable firewall to block bad syntax

or

finished plugin like we where developing

or

use "Exact search" in all web queries

I believe 100% security can be only achieved for FileMaker through Lasso *and* good programming in Lasso.

Search forums for "security loophole" and similar topics.

[Garry Claridge]

I believe excellent security can be gained through the "Web Security" database for certain designs and conditions. As I proved in the "Security Loopholes" threads.

All the best.

Garry

[Leb i Sol]

Anatoli.....tell me more about your plugin....I spend last few weeks thinkg about altering CGI (especially URL) processing of FM.....had very little luck or $$$.

is this supposed to be retail plugin? or will we see it at the Sample Forum

thanx_();

[omiossec]

I so 2 points in your schema that can unsecure your solution.

First you VPN I suppose that some client access to the databases from laptop or in house computer without any control. This users can have their own connection that could open a bridges between your Secure zone and Internet.

The second point concerne you application on the web. First you should add some urls tools like url scan to eliminate wrong/malformed url.

Remember to that using the web companion let users show the db name and layout name and can manipulate the url.

You should also be sure that the FMPU not use a public adresse

Remember to that hacker can aslo manipulate tcp packet to pretend that a request come from your web server and not from internet.

So you better use tools like Lasso or JDBC to secure your critical db. and not show critical informations

[Anatoli]

Our plugin will just filter out the "nasty hacking syntax".

I do not believe in WC security much. I guess it is something like 0 (zero) in most solutions and up to 70% if you implement all known tricks.

In Lasso security is enhanced up to possibly full 100%. But it has to be used professionally again with good programming techniques.

[cmartin]

It seems to me that for the web-based route, the only way someone could get in given the implementation in the diagram would be if, as omiossec said, someone manipulated a packet to make it look as though it came from my web server. Otherwise, they will be going through the very secure route of SSL. If they did make it appear as though it were coming from my web server, then they could use the -dbnames and -raw, etc commands to access what? I have read through all the secuirty threads but I don't think there is ever a consensus as to what then may result.

By the way, I am also using forced frames, disable right click and cannot eneter site without javascript enabled.

Thanks all for the input so far!

-Courtney

[Anatoli]

Leb i Sol -- We where just building the filter and it really works as I wrote above. But because it is filtering all XML and CDML "nasty hacking syntax", there is problem, that WSC loses connection to Unlimited, because it is using one of the forbidden XML commands.

I guess unblocking that command is everything what need to be done, but the project is on hold and until someone will finance the estimated US $300 to finish that filter we cannot use it.

It works like IIS -- WSC -- Filter -- WC+Unlimited. It is not crashing and it is superfast.

[Anatoli]

RE: By the way, I am also using forced frames, disable right click and cannot eneter site without javascript enabled.

When I developed that combination I never thought about gaining full security. It is just small navigational help and sort of "security through obscurity".

[Unable]

re: "... they could use the -dbnames and -raw, etc commands to access what?"

Well if you take a quick look at Flanzy's recent thread on this forum, you will see that at his site "everything" was available, including cc #'s and their expire dates. Squeaky ouch!

And he had a couple of ScriptMaker scripts which could have been run thru url manipulations as well. Might have just played havoc with things, but then someone would have had to deal with that too, huh! Oh my.

I might infer that's "what" may similarly be available at your site in the situation described.

[Garry Claridge]

"-raw", with "-findall", will display all data from the database, unless restricted with the "Web Security" database. The same applies to the "xml" commands.

With these commands, you do not need a Format file to display data. Hence, Format files cannot be used to "hide" data.

Hope this makes sense.

Depending on how your application is designed, the "Web Security" database may provide all the security needed.

All the best.

Garry

[cmartin]

I just reread my intital post and realized it sounded as if I was not using the web secuirty database, which I am. So that being said, if someone does manage to manipulate a packet to make a request appear as if it coming from the web server, then they still have the web security issue to contend with.

garry-

could you elaborate on this :

"Depending on how your application is designed, the "Web Security" database may provide all the security needed. "

Thanks-

Courtney

[Garry Claridge]

Courtney,

The one main problem I've found, is that I cannot have "All Users" browse the database yet hide certain fields from them and have other users see the hidden fields.

As an example, "All Users" search a Products database and see the selling price. Only the sales staff are allowed to see the cost price, supplier and markup etc.

If I am only using Format files to restrict field display, "-raw" and "-fmp_xml" will allow "All Users" to see all fields.

This is the design which causes me some work-around problems.

All the best.

Garry

[Anatoli]

RE: Depending on how your application is designed, the "Web Security" database may provide all the security needed.

So Garry, how would you protect the databases, when in fact all must be set as "All Users"?

On most web solutions one can never enter all visitors into Web Security db.

[Unable]

I believe that some greater degree of security exists in 5.5 and above - provided one is willing to put aside aesthetics and use the yucky pop-up.

In that instance one can inform the general-public-client of the password to enter into the pop-up when it appears.

Those with "in-house" needs will be informed (of all places) "in house" of the password or (possibly more accurately) group and password to use with the ugly pop-up so they can enter whatever level is appropriate to them.

Another solution is set the website such that the db file serving it is restricted by a group/password other than All Users and utilize the automatic entry of the password.

It should be possible (probably advisable) to run two sites, one for the public (restricted, seamless, no pop-ups) and one for in house (many groups and passwords).

[Flanzy]

Unable - I thought you weren't going to broadcast my error in having that info available. I hope I was able to remove it before everyone went there. Have solved one speed problem, but don't know how. I am now trying to figure out if lasso would be the answer or an SSL to the security issue. BTW - this Flanzy is female.

[Anatoli]

RE: or an SSL

With SSL you will get transport encryption, but not security from FM.

RE: It should be possible (probably advisable) to run two sites, one for the public (restricted, seamless, no pop-ups) and one for in house (many groups and passwords).

That will call for Lasso for synchronizing between both systems, thus making 2 systems redundant, because of Lasso.

[Flanzy]

Anatoli,

I am confused. There are 3 computers on an in-house network that communicate via apple-talk. But only one computer runs the on-line shopping cart solution. Anyone who wants to work with it goes to that computer. We live in a rural state and our bookstore is in our barn behind our house. The barn is dry and economically rennovated (floors, shelves and ceilings.) I make back ups of the solution - so do I still need to have two systems?

Also - when you go to book-selling sites like abebooks.com - or a lot of other shopping sites, they offer a secure way to send credit card info. So doesn't that - or will that achieve the security one wants? Or am I not thinking correctly?

---

Flanzy

[Garry Claridge]

Re: how would you protect the databases, when in fact all must be set as "All Users"

Protect what?

If you have "All Users" browsing that means that you are allowing them to see the data.

I've missed your point!!! What protection do you mean?:

Garry

[Anatoli]

All Users will allow ALL data to be displayed via -raw queries.

In the same moment All Web Users should be able to place order in e-shop.

How do you protect some fields not to be displayed?

[Anatoli]

Flanzy

RE: But only one computer runs the on-line shopping cart solution.

Is that connected to FM server? If yes, then if you allow All Users, which I will say is desirable, then all databases opened in Unlimited and all records are available to -raw "hacking" syntax.

Did you try that? There are plenty of articles here. Search for "Security loophole".

SSL is just secure channel between browser and Web Server. So in theory nobody connected between end points is able to get anything out of it.

If web server is disclosing all info from hosted databases, where is the security?

What do you see in http://yourserverIP/FMPro?-dbnames :

[Garry Claridge]

Re: How do you protect some fields not to be displayed?

Yes, that is the problem! As I stated, I've had to develop "work-arounds" for this design in the past.

The way I've done that is by establishing another database which has one field, the "Item ID". All other fields are Calculations from the related record in the master database. The trade-off here is performance.

This is where I believe the "Web Security" database needs to have field restrictions based on Users. Not just a "blanket" restriction.

All the best.

Garry

[Anatoli]

Calculations are displayed on request. IMHO -- no protection again.

RE: This is where I believe the "Web Security" database needs to have field restrictions based on Users. Not just a "blanket" restriction.

That will work. But how to do that for thousands of unexpected visitors in e-shop?

[Garry Claridge]

Re: Calculations are displayed on request. IMHO -- no protection again

It works exacly how I want it to work with the protection I need!

Garry

p.s. Give me the e-shop requirements and I will design a system. I will also charge accordingly!

[Anatoli]

Garry Claridge said:

Re: Calculations are displayed on request. IMHO -- no protection again

It works exacly how I want it to work with the protection I need!

Garry

p.s. Give me the e-shop requirements and I will design a system. I will also charge accordingly!

The field is always displayed. Text field or text calculation, if database is hit by web request, proper user page or -raw it is displayed. The same as in FM. If you are happy with that, that's OK with me.

I am not happy with that. So the shop is on Lasso which has also huge performance benefits and with LassoScript I can do more, than FM can do.

[Garry Claridge]

Re: The field is always displayed

That is correct. That is why I have only the fields intended for display as Calculations in the "web-exposed" database.

So if anybody uses a "-raw" or "-fmp_xml" they see only the data I intend them to see.

The reason these fields are calculations is so that they remain "dynamic". That is, a change in the master database is seen in the web-exposed database.

Hope this helps you understand the design.

Garry

[Anatoli]

Yes, that is clear from beginning and good way of some "read-only" protection.

Also, you cannot edit such fields from web, because if you allow access from web to database, it is web-exposed.

That is working as protection of company "internal" data. Not protection of absolutely all data used on web database e.g. email address. That has to be in web served database available for users for all edits. I can verify the user, allow him/her to edit record and only his/her record.

Then someone will get the whole database listing with -raw query. That *is* bad.

Obviously the accounting data will not be visible, because they are not in Web served database. Then someone will ask for those data to be visible only for verified users. That is again impossible. The only reasonably way is "exact search" in WSD, but then everything must be with exact search on that database and that is far away from real web usage.

Take this example:

I've checked how Masters are doing protection years ago. I've listed in browser all email addresses from database of famous FM author. I've notified him and basically he replied something like "who cares".

I was furious, because my address was "in public domain".

My opinion about security and FM served database is just security by obscurity. Only Keith's way with scripts is much more secure, because he is shifting the data out and in database exposed to web. But since scripts have those unpleasant side effects like freezing the FMU it is again solution for few websites with small number of visitors. Not the traffic we have.

So I am studying Lasso and there is possibility of real security. It is in Lasso features and it has to be achieved through good programming. Actually, talking here about security is like children games. Dramatic security breach in Lasso Lists is considered just the exposure of database names to web traffic. And we even didn't touch those depths in any security discussion here!

[Keith M. Davie]

Well thank you Anatoli.

Based on my experience "side effects like freezing the FMU" do not have much significance when the ScriptMaker event processes in less that 100 milliseconds, which is more than enough time to remove data completely from web exposed db file with a protected ScriptMaker script.

[Anatoli]

Maybe in your case, but not in our heavy traffic. But in case of protecting otherwise unprotected data I will probably rather risk crash, than data to be stolen.

With Lasso we don't have such issues

[Garry Claridge]

Anatoli,

Do you like Lasso?

Garry

[Anatoli]

I was working only on one solution in Lasso 6.

When I examined the requirements and the FM solution, there was absolutely no way to do it in CDML. I can say I know 90% from CDML, 20 % from related JS, but even with FM scripts and better security than WC has, the task was too much for CDML.

With Lasso -- piece of cake. I was hold back from time to time with Lasso vs. CDML difference, but with excellent support from Lasso List it was relatively easy task.

In short

[Leb i Sol]

IF WEB oriented THEN

MySQL+PHP

MySQL+ASP

MySQL+JSP

is even better than any FM +"cowboy" tool ...heheheh

[Anatoli]

Did you try both? Lasso is more productive than php and you get MySQL in Lasso "tuned". Everybody who is at home with CDML knows already some of the Lasso workflow.

ASP is even less productive.

Lasso is expensive, but php with Zend is even more. Lasso and php are portable between Windows, Linux and MacX, ASP not.

BTW, FM is quite fast on my Windows, so normal search is faster than the same search in MySQL. Obviously MySQL is faster and faster as the complexity in Queries increases.

[Mariano Peterson]

Oh boy, here we go again!

Yes, Lasso has some very useful tags built in. However, PHP is much more robust and extensible. Further, PHP supports object oriented programming which can *greatly* simplify the code behind a complex web site, and greatly reduce development time as well. Further, PHP is free. While you can optionally purchase the Zend optimizer (which costs slightly more than Lasso), it is outright unnecessary for most sites.

Further, PHP is much easier to learn than Lasso (imho) because there are hundreds of excellent books out there on PHP. Lasso on the other hand only has a few books, none of which are worth their weight in salt. From what I hear Lasso has a good list-serve and supportive online community. So does PHP - in fact more so because PHP is soooo many more users/programmers than does Lasso.

PHP is also optimized for MySQL, since they the development of those technologies was tightly knit together. MySQL is also free, unless you build it into a product the user cannot choose which database to use. However, MySQL is free for database driven web sites, even if you're making money from the web site via subscriptions. I've personally verified this with the MySQL AB team through email correspondence. PHP is also well optimized for Apache, which is a *free* world class web server.

Another *extremely* good reason (imho) to use PHP over Lasso is that there is much more demand for PHP programmers than Lasso programmers. If you can acheive the same (or even reasonably similar) results from PHP or Lasso, why not choose the technology that will open up a world of new job opportunities for you? Just go on craigslist.com, hotjobs.com, dice.com or monster.com or any other and search for Lasso jobs, then search for PHP. The difference is tremendous.

Also, most web hosting services provide PHP and MySQL... how many provide Lasso?

ASP is also a good technology, and offers far more pre-canned functionality than Lasso (thereby making it a more production tool). I don't think ASP is quite as fast as Lasso or PHP, but the difference is not much. The only thing is, ASP doesn't yet have a free code package that abstracts the http/xml layer it uses to communicate with FileMaker.

I don't think any of us are supporting E-Bay type traffic with FileMaker on the back end, anyway - so the speed differences are not too noticeable.

----

Re: security.

Any middleware is a HUGE improvement over FileMaker's native web scripting. First, these all offer increased security by removing FileMaker's web vulnerabilities - any client communication to FilerMaker must be filtered through the middleware, which can be built to provide as tight a security model as you like. Any of the aforementioned scripting languages will also vastly boost your productivity by allowing you to approach standard programming problems in standard ways - instead of looking for brittle and obscure work arounds in CDML.