erasmussen

Here are the basics: You can use Apache as a "front-end" for FileMaker Unlimited by configuring Apache to act as a proxy server for requests to FileMaker. In fact, this is a very good idea for both performance and security. For more info, see this previous post: http://www.fmforums.com/threads/showthreaded.php?Cat=&Board=UBB21&Number=19052 Please note that the referenced post gives example commands for setting up the proxy which apply to the 1.3.X versions of Apache and may or may not be accurate for the recently released 2.0.X versions. The FileMaker Unlimited client can run on Mac (OS9, OSX) or Windows, but not Unix/Linux. The FileMaker Unlimited client does not have to run on the same machine as Apache, and it cannot run on the same machine as FileMaker Server. FileMaker Server exists for Mac, Windows, and Linux. Apache, as you probably know, exists for just about everything under the sun.

quote: Originally posted by Anatoli: Scripts will be always only partially successful. Example: to put current date in global field it will work all the time. To find records by script and display them through HTML -- no way. It may look it is working. But if first request (1) from user A will run the script, and another request from user B (2) will make different found set of records, then the machine will not display correct set of records to user A (3). You cannot assume, that FM somehow will process the requests in 1-3-2 sequence. Are you saying that web companion will answer the request for B before FileMaker finishes running the script for A (i.e. scripts run without regard to synchronization with filemaker/web companion)? If so, what happens to the answer for A? Does web companion answer A before the script finishes, thus generating an incorrect response? Does web companion/filemaker actually process the requests in a non-FIFO (first-in, first-out) manner? In your example above, isn't 3 really part of 1, and 2 shouldn't be processed until the script completes? Does this also mean that a user at a regular filemaker client console could interfere with the proper operation of a script by using a keyboard/mouse to perform a command while the script was running in the background, or is this simply a problem with web companion? -Eric

quote: Originally posted by chazboi: Yes you are right (as far as I know). The field restrictions should stop individual fields from being viewed. The major problem with the field restrictions is that they are not specific to a layout or CDML format file (it would be so nice if -raw, etc. didn't exist). Therefore, information that you need to show on a restricted basis, such as after you log in, cannot be hidden using the don't show attribute. For that, you need to use relationships that are only valid once certain information has been filled in.

quote: Originally posted by John May - Point In Space: -op = -eq is not the same as appending "==" to your search term. The first will find fields with ANY word in them equalling the search term. The second will find fields ONLY containing the exact search term. - John Doh! Thanks, you are correct. I guess I misread the text in the CDML reference for -Op.

quote: Originally posted by garrycl: I'm using OS X with Apache and FMP. I'm using a high port number, however when I installed OS X I was prompted to allow the use of ports above a certain number (much greater than 591). Also, 591 maybe reserved for FMP client/host communications not http. Try a different port number. All the best. Garry Try a port number above 1024. Unix (OS X) reserves port numbers below that for system (root) processes. Above that is open for user programs. (The limit might be 1000 or 1023 rather than 1024, I'm a little fuzzy on the exact detail, but this is the general concept.)

quote: Originally posted by Keith M. Davie: Eric, I notice that you are (or were) trying to do an exact search with the cdml tag -op and the cdml tag eq. Please understand that those tags do not work in html. In order to get those tags to work you will need JavaScript. If you are interested in doing an exact search using cdml/html then you should go to FileMaker and read: http://www.filemaker.com/support/index.html Search and read: Article Number: 104829, and Article Number: 105687 Understanding the application of the exact search, you will find that the other options (found under symbols in the status bar of your FMPro db's when doing a find) can also be applied similarly, with a minor degree of intelligent application. The articles you reference were written for FileMaker 3.0 and 4.0. The -Op operator with the -Eq argument is the same as putting "==" at the start of your data. It was added after those articles were written and replaces "-Eq" as a standalone operator. In either event, using "==" as a prefix for the data has the same result as adding &-op=-eq to the URL. Javascript has nothing to do with it. -Eric

quote: Originally posted by Anatoli: Eric, for this I am using calculated field with Name & Password and I am comparing that with calculated field in database with access rights. There is also field with Name & Password. If those Calc fields fully match, the flag is set to log user in. That's a good idea. I'm going to end up using that method, plus some others, to help validate the data passing back and forth from the web to our internal databases. -Eric

quote: Originally posted by proton: What I would like to know is, if one is using Filemaker access privileges, then one is more vulnerable than if one uses Web Companion security? I know as a rule this is true, but I mean with respect to this new information with raw and layoutnames? Aren't the two security measures on equal footing when it comes to these vulnerabilities? Also, if a database is using Filemaker access privileges, and a hacker logs in with a specific password, can they have access to data in fields that are blocked for that password? That sounds very powerful if you ask me. Cause if I say access is denied to field x with regards to a filemaker access password z, then you are saying they still can the data in it? Please supply more details. Thanks in advance. Oh, is this problem specific to later versions of web companion? Or to all? Example, will this also be the case with Filemaker 4.x web companion or just 5.x? P.S. I almost forgot, didn't Filemaker say that if you don't want your database listed you put an underscore in front of the name or something? Does this alleviate the databasenames problem? Or is that still there? [ July 30, 2001: Message edited by: proton ] FileMaker Access Privliges are not as good as the combination of FileMaker Access Privliges + Web Security Databases. However, both are vulnerable to the -raw and other series of undocumented features. The Web Security Databases will allow you to block access to fields on a field-by-field basis, which helps against the extra data that can be revealed by -raw. You can't use different FileMaker passwords on the web to have dynamic security through FileMaker Access Privileges because the database gets opened once by FileMaker with whatever password FileMaker opens it with, and that determines the Access Privileges that it is stuck with on that web server. You can add user accounts in the web security database for browser-based security, but there are limits to what that can do. Specifically, once the user logs in on the web, they can then run the undocumented commands. I have only tested the undocumented commands on FileMaker 5.x. However, I suspect that they exist as far back as FileMaker 3.0, because Claris Homepage apparently uses them. I'm not sure if the blahblah_.fp5 naming trick works against the -dbnames function. I haven't tried it yet. -Eric

quote: Originally posted by chazboi: Something interesting I noticed is that FileMaker Online have a couple of Web Companion driven resources. However the servers seem to be Apache not FileMaker. The FMPro? tags can only be used on certain directories. As far as I can see, they use some sort of forwarding maybe to a different port or even a different server. Is this possible? Is there some server package that can refuse HTTP requests if it holds certain values? If there was, that would be ideal. Actually, it is quite easy with Apache. I've been doing that for over a year. I setup Apache as a proxy server for all requests to certain directories. The requests are internally redirected to a different port on the same machine where FileMaker/Web Companion answer the requests. Depending on how you setup the proxy statements, you can even use this technique to hide the CDML template files in your /web directory under FileMaker, so that browsers can only see the results of FMPRO? queries. I won't get into the all the details of proxy serving under Apache, but it's not too difficult. Below are an example of the "magic" lines that you need: ProxyPass /fmweb http://thehost.com:1234/fmweb ProxyPassReverse /fmweb http://thehost.com:1234/fmweb ProxyPass /FMRes http://thehost.com:1234/FMRes ProxyPassReverse /FMRes http://thehost.com:1234/FMRes The first line tells Apache to relay requests for /fmweb on the main web site to /web/fmweb under FileMaker, and to contact Web Companion on port 1234 (because Apache is already on port 80). You could just as easily relay the requests to another server entirely. The second line translates the returning URL so that it looks like it came from /fmweb on the main server. The third and fourth lines do the same thing for the /FMRes directory, which is a "virtual" directory under FileMaker's /web directory, and it is needed by Web Companion for a number of functions including the Javascript error messages, and templates+images for instant web publishing. If you want to hide your CDML templates, you can "enhance" the first two lines to be: ProxyPass /fmweb/FMPro http://thehost.com:1234/fmweb/FMPro ProxyPassReverse /fmweb/FMPro http://thehost.com:1234/fmweb/FMPro This will only relay the requests to FileMaker and not serve any static files in these directories (such as your CDML format files). The thing to remember if you do this is that you then need to move any static files that you do want to serve from that directory to a real /fmweb directory on your web server (e.q. .../htdocs/fmweb), so that Apache can serve them. You then keep only the CDML format files in /web/fmweb under FileMaker. Something to keep in mind with either of these methods, though, is that FileMaker will see all requests as coming from the IP address of the proxy server. Apache will still log the requests, so you don't lose security information, but it prevents FileMaker from using IP address information for anything. Apache also has the capability to perform URL "rewriting", such that you could theoretically filter out certain strings such as "-format=-raw" in a GET request. However, URL rewriting is rather complex and I haven't attempted that yet. Even if you did, I'm not sure that you could easily filter out the equivalent request submitted via the POST method as part of a FORM. Version 2 (still in Beta) documentation for Apache indicates that it will support filters for inbound and outbound data, so that you theoretically will be able to filter out the equivalent tags in an incoming POST form. However, it looks like the first 2.x release will only support limited outbound filters, which doesn't solve this problem. I think that what we need to do in the short term is lobby FileMaker to document these dangerous features and hopefully remove them in the future. In the meantime, I am setting up our new registration system to use a 1 record "proxy" database (chock full of globals and scripts that double-check their data before running) to sit between the web and my real databases. I am also using a calculated relationship to the real data that only connects to real data when the proper username/password combination is entered. In this way, I can "harden" the proxy database against unauthorized attempts to extract or damage real data, and I have to live with the fact that the scripts and fields in the proxy database are visible. -Eric

quote: Originally posted by John May - Point In Space: Another way to force an exact match is to concatenate an "=" character to the beginning of your search term. This should force Filemaker to find only fully-matching requests (I know it works w/Lasso at least, not sure about CDML, but I don't see why not). - John That does work when performing a find request. The thing is, I take the philosophy that you can't trust users not to send in requests that you don't expect. For example, a hacker could easily look at the syntax you use, modify it, and submit it. Since you cannot force the user to search on the fields you expect them to search on, they could easily find records that they shouldn't see. The Web Security Databases address this with a feature called "ExactMatch", which requires exact values for one or more fields to be submitted as part of the find request. For example, you can use ExactMatch on the password field to insure that the user actually submits a valid password with each find request. If they don't, then the Web Security Database settings cause Web Companion to block the find and not return any results. Assuming that they can't guess the passwords, this is a good way to keep hackers out of your data. The problem is that the ExactMatch function doesn't seem to work properly for some data values. I am perfectly capable of submitting the same data in a find request and having FileMaker answer with the correct records if I don't try to use the ExactMatch feature. The troubling thing is that ExactMatch behaves differently from Find in determining what is an exact match. Consider the following request: http://thehost.com/FMPro?-db=[database]&-lay=[layout]&-format=[format]&-op=eq&password=mypassword&-op=eq&LogonID=longemailaddress@longdomain.com&-find Assume that there is a record with the field password equal to "mypassword" and the field LogonID equal to "longemailaddress@longdomain.com". The above find request will work if I don't use the ExactMatch function of the Web Security Databases for the LogonID field. The same request with the same database will fail, even though it should work, if I turn on the ExactMatch option for the LogonID field. Read my first note in this thread for differences in this behavior between Web Companion 5.0v6 and Web Companion 5.5. Eric

quote: The good news is that, at least as far as my tests can determine, if you use the Web Security Databases, it does appear to restrict the use of -layoutnames, and -scriptnames based on web user access restrictions. That is, unless your browser is already logged in with valid user info (i.e. something other than "all users"), you cannot execute -layoutnames or -scriptnames. It looks as if my earlier test missed something. If the Browse permission is enabled for the web user, such as all users, then the -layoutnames and -scriptnames functions work as does "-format=-raw&-view", which effectively lists all field names. Turning off the browse permission seems to disable all these functions from working. quote: Everyone from us makes available all db names, layout names, field names etc when designing web solution. So my question still is: What can anyone do harmful armed with all this knowledge? Good question. Many of us rely on a bad practice known as "security through obscurity". Shedding light on things such as script names gives hackers a much greater chance of doing damage because it violates the assumption of many developers that the script names were secret, and therefore used more lax security methods, if any, in the scripts. While it is true that a good hacker could figure out all the scripts used on the web by analyzing the forms used on the web site, there may be many additional scripts used internally (i.e. for local users running the FileMaker client) that are now "visible". Because there are no script-level access rights, this means that if any scripts are used on the web, all script are available as long as you know the name. There is a good chance that many FileMaker users have scripts that will do "bad things" when run with unexpected data sets, unexpected user permissions, etc. This risk was always present, but it is now much greater. What is really harmful, though, is that data that developers thought was secure, by means of restricting viewable data to that specified in the CDML tags, and choice of layouts, turns out not to be the case. This means, for example, that customer data that should be private may now be exposed. You could argue that this can be mitigated by restricting the web client's access to certain layouts that show only the desired fields via FileMaker Access Privledges (i.e. by opening a database with a FileMaker password that only allows access to specific layouts), but that turns out not to work at all. I just did more testing and determined that, even if the client cannot see the restricted layouts, web companion can. Thus, ANY FIELD/DATA ON ANY LAYOUT IS VISIBLE thanks to the undocumented -raw layout, and you can use the undocumented -layoutnames to find all the layouts, even those not intended for use on the web. Therefore, data that was previously thought to be secure is not. In short, all you need to view ALL DATA in a database is: 1) Browse permission for the database AND 2) Each field to appear on ANY layout in the database (yes, portals and related fields from other databases show too) AND 3) A lack of record-level access permissions (such as by ExactMatch or DontShow) or the data necessary to satisfy the ExactMatch criteria That's it. I suspect that these conditions are true for many FileMaker databases currently being published on the web. quote: This is why you should highly consider switching to [inline] actions, which can hand off a username/password to Web Companion without the user having to be logged in with the same. Inline actions are handled the same as requests coming from the web. Therefore, all a hacker needs to do is submit a properly formed request, and use the generic -raw response format, and they can see whatever it is that you were trying to hide with the Inline response. Also, you don't want to embed the username/password as static text in the HTML/CDML template because it is trivial to view the raw source of the template on most systems (I actually figured out how to hide this), which would then reveal the username/password and necessary syntax. Maybe I don't understand your suggestion, though. quote: Originally posted by chazboi: Anatoli, I know that all the actual data is safe and fair enough, the database names are common knowlage, but I don't want people looking at my layouts, private fields and especially scripts. 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. On some of my databases, if someone got hold of all my script names it could be fatal. They do all sorts of functions that I DONT want excecuable via the net. Do you think we should mention this to filemaker? They could easily make the remote admin password govern acces to this data. If they did that, I would be more than satisfied. Charlie I fully agree. The less information about one's systems that the hackers can get ahold of, the more secure it is. This does not excuse poor coding, but as we are discovering, basic assumptions about what is safe with Web Companion are turning out to be false. It is hard to make secure systems when the documentation you are reading is incomplete. Currently, I am in the midst of a big project involving an online registration system using FileMaker/Web Companion. We would like to make sure that the confidentiality of data from our customers is maintained. This is a real eye-opener, given that I have been using Web Companion for about a year now and consider myself fairly proficient with CDML. I now have to seriously rethink portions of our system design given that I can no longer rely on my CDML templates and existing scripts to restrict access to data. Eric null

quote: Why do you need the "ExactMatch"? I want to make sure that users can only access their contact information records by forcing all find requests to contain both a LogonID and password. The records being found all contain the LogonID and password values, which is how I find the correct contact records. If I do not use ExactMatch, then a saavy web user could easily construct a custom find request based on some other field (or even use -findall or -findany) and reveal information that they should not see. quote: Originally posted by John May - Point In Space: What happened when you changed the storage of the field to ASCII? Did you also turn off ExactMatch when you did this? This has always solved the problem for me. - John Turning the storage to ASCII had no effect. Turning off ExactMatch will allow the find request to work correctly (i.e. web companion can successfully find records with LogonIDs longer than 20 characters and containing the @ symbol). However, this removes a layer of security that I would like to maintain. The point of ExactMatch is to allow record level security via the web, which is what I need in order to prevent customer contact information from being extracted by personal information thieves. Right now, I can do the ExactMatch based on password, but not password & LogonID, which *SHOULD* work. (Yeah, I know, "should" is a big word when it comes to computers.) Anyway, ExactMatch is simply failing to work on some data, even though the same data works perfectly when actually using it to find records. As far as I can tell, ExactMatch is either broken, or this is an undocumented limitation of ExactMatch.

Wow, talk about a loophole... I did some poking around and discovered the following "undocumented features" in Web Companion (v5.5). I suspect the existance of more undocumented feature, but I don't have time to keep poking around. Substitutions (I have not yet tested these) ------------- fmp-companformlayout fmp-compantablelayout fmp-compansearchlayout fmp-compansortfields Actions ------- -dbnames -layoutnames -scriptnames Formats ------- -dso_xml -fmp_xml -dso_xml_dtd -fmp_xml_dtd -raw Everything in http://host/FMRes (a "virtual directory") ------------------------------- too many to list, but includes the following types of files: *.js *.gif *.css *.htm This is all very disturbing. I hope that someone can convince FileMaker to be more open about what users are exposing themselves to by documenting the rest of the codes. The good news is that, at least as far as my tests can determine, if you use the Web Security Databases, it does appear to restrict the use of -layoutnames, and -scriptnames based on web user access restrictions. That is, unless your browser is already logged in with valid user info (i.e. something other than "all users"), you cannot execute -layoutnames or -scriptnames. Even with Web Security Databases being used, -dbnames returns a list of all databases being shared by web companion, but not the names of open databases not being shared by web companion. This is not good, but not a total disaster. The bad news is that custom web publishing with filemaker access privledges is USELESS if you wish to keep ANY data, such as passwords, in the shared database private. Even the most carefully designed CDML templates are useless in the face of -raw and the other undocumented format tags when you want to restrict access to data. I suspect that most users will be IRATE when they find this out. Who knows what wonderful undocumented features are hiding in /FMRes?

I am trying to use the web security databases to perform record-level access restriction for web users. I have a LogonID field and a Password field that I would like to use with the ExactMatch feature. ExactMatch works just as expected with the Password field, but is unreliable with the LogonID field. Some LogonID values work as expected and allow access to the relevant records, while other LogonID values cause Web Companion to return an error message. If I disable the ExactMatch feature for the LogonID field, then all values of LogonID work when performing a -find to pull up the relevant records. As far as I can tell, web companion 5.0v6 (windows) can't perform an exact match if the data in the field is longer than 20 characters. This is a problem, because I am trying to use our customer's email addresses as their LogonID, and some addresses are longer than 20 characters. A developer I work with suggested switching the indexing for the LogonID field to ASCII, because it contains the @ symbol. However, that did not solve the problem. I take this to mean that web companion is using some sort of internal index value list or relationship to perform the ExactMatch, because relationships and index value lists only use the first 20 characters. I thought of making a calculation that was the first 20 characters of the LogonID field, and using ExactMatch with the calculation, but then realized that the Exact Find part of the web request would fail (remember that the -find action works correctly with the full data). I never actually tried this approach, though, because I'm pretty sure it won't work. I then upgraded to FileMaker 5.5 on the same machine, hoping to solve the problem. I even went so far as to use the new set of web security databases that came with 5.5 and recreated the database/users/field permissions. Unfortunately, it got worse. As far as I can tell, in 5.5, ExactMatch fails on any text with an @ in the data, even when the total text is less than 20 characters in length and I am still using ASCII indexing for the LogonID field. Given the inconsistent behavior between ExactMatch and -Find, and the fact that it changed from 5.0 to 5.5, I'm tempted to report this as a bug to FileMaker. However, I thought that maybe I was missing something and would ask the experts here for help first. Has anyone else experienced this problem? Does anyone have any workarounds?