Security Loophole

[Charlie Boisseau]

I think I found a loophole in the Web Companion. When I was playing around with the Claris HomePage Assistants, I saw that the program was able to dowload the entire list of open databases on any server, a list of all the layouts in any database specified, the field names of all the fields in a specified layout and also any related list values.

Being the inquisitive programmer that I am, I fired up interarchy to see how it was doing this. I saw that it was sending out some inline CDML that I had never seen before.

To access all the databases it was going to: http://thehost/FMPro?-dbnames

For the Layouts it was accessing: http://thehost/FMPro?-db=[DATABASE-NAME]&-layoutnames

For the Field and List Values it went to: http://thehost/FMPro?-db=[DATABASE-NAME]&-lay=[LAYOUT-NAME]&-format=-raw&-view

With this alone, anyone can access a lot of info that is essential to any hacker trying to access data. After looking into it I thought, they might be able to see your info, but without custom format files, they can't do anything.. But then I saw this "-raw" format file.. It is a master format file that contains all the information on anything parsed to it via inline CDML. With this knowlage, a hacker could (providing the server didn't have a Security system) have complete superuser access to EVERYTHING. Even with a Security system they could still see a lot more than they should be able to.

Does anyone know anything mode about this? If so, is there a way to stop the server from giving out this public data?

HELP!!! I have tried everything but my servers keep churning it out no matter how much I fiddle around with it.

Cheers..

Charlie - The Newbie

[Anatoli]

OK, what Charlie described is true.

Now, what can anyone do harmful armed with all this knowledge?

[Charlie Boisseau]

Can't they access all fields on a layout? What about accessing the passwords on the security databases? They could just perform a find in a web browser using the -RAW format file.

[John May - Point In Space]

The only actions that can be performed with this method are whatever is opened up via Web Companion's security. You need to lock-down the solution with passwords to avoid this.

Using Lasso, this is very easy, as Web Companion only allows Lasso to access it in this configuration (when properly configured), and you then use Lasso Security to set user privledges, etc.

- John

[Anatoli]

quote:

---

Originally posted by chazboi:

Can't they access all fields on a layout? What about accessing the passwords on the security databases? They could just perform a find in a web browser using the -RAW format file.

---

Did you try that?

Every one know the Security database names, every one knows all used layout and field names. That is on Web "open to public".

[Anatoli]

RE: 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

and other points.

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?

[ July 25, 2001: Message edited by: Anatoli ]

[John May - Point In Space]

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.

See Michael Collins' http://www.lassodev.com/ site for a great article on this.

- John

[erasmussen]

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?

[Charlie Boisseau]

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

[erasmussen]

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

[John May - Point In Space]

quote:

---

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.

---

If you lock down the databases to no access for all users, then the -raw response format won't allow you to do anything.

You can certainly embed your username/password in the inline safely, just make sure you use a Lasso/WebCompanion-processed extension on the file then to keep the user from being able to view the raw code (eg: .lasso on a file will make Lasso process it no matter what).

- John

[Anatoli]

RE: 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.

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

That is not really big concern. You should not use any scripts on web. Or, as I have only 1 script in 10 web solutions -- the script is just setting one global field with current date.

My conclusions are that scripts and web is not happy marriage. Scripts are next to useless on web.

[Charlie Boisseau]

quote:

---

That is not really big concern. You should not use any scripts on web

---

Yes.. You shouldn't use scripts, in a perfect world, but in some cases there is no way round it. Hundreds of people out there use scripts to do funtions on web solutions that are essential to make it funtion.

I know that you could lock down on security to make the database's actual data pretty safe, however the only way to do this is to comprimise heavily on funtionality. A lot of people use the Web Companion to publish databases but what they don't realise is that without being completely clued up on this problem (as Eric said), they are actually giving the world access to more than they originally wanted. And that could be fatal. FileMaker has not said anything about this and I have seriously cosidered switching to Lasso and completely removing everything I ever had to do with Web Companion.

To demonstrate how many people are at risk, I will create a program that can interigate a database via the web, and display resultes parsed from the XML foramts. I'll post some screenshots once I'm done.

Thanks for you feedback.

Charlie

[John May - Point In Space]

This is exactly why we don't offer Filemaker's or Lasso's Instant Publishing features with our accounts. They just open WAY too many security holes in the solutions.

- John

[Anatoli]

RE: To demonstrate how many people are at risk, I will create a program that can interigate a database via the web, and display resultes parsed from the XML foramts. I'll post some screenshots once I'm done.

OK. Could you analyze www.prnet.cz? How far is that in risk?

RE: scripts.

I do not need ANY SINGLE SCRIPT to make normal FileMaker driven web solutions. People are not getting the concept of FM on the web or are lazy or both.

These days everything can be made by CDML and of course even better with Lasso. Although I never get such difficult job that I must go for Lasso. The CDML was sufficient.

[Krishan]

Hi everyone.

What is the point of a password for members during login if anyone from this FM Forums board can view the member's data? There is no confidentiality.

...so does this mean that I should use Lasso instead of Web Companion? Is there a "raw" format file for Lasso too?

.....

[ July 29, 2001: Message edited by: Krishan ]

[scratchmalogicalwax]

Purchasing Lasso is a good idea because as far as I know there is no WebCompanion specific file extension so if you don't want your inlines available for everyone to see (when the page is not derived from a POST action) use lasso and the .lasso extension as John said it will process the form and throw up any error includes you may have put in.

Inlines require a very different approach to designing your solutions (I have yet to port some of my stuff over due to the time it can take) they can throw up a few problems of their own......that said I've never looked back since buying Lasso

[Charlie Boisseau]

quote:

---

OK. Could you analyze

www.prnet.cz?

How far is that in risk?

---

OK.

quote:

---

...so does this mean that I should use Lasso instead of Web Companion?

---

I'm asking myself the same question.. I think I will. From what Anatoli said, I have come to the conclusion that web companion is only good for solutions where security is not of upmost importance.

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.

Thanks.

Charlie

[scratchmalogicalwax]

With webSTAR you can create realm based security where the webserver will ask for a password if the client asks for a certain match string eg. log or .txt or a foldername.

With lasso you also get enhanced security features that aren't in WC alone

as far as FMPro online the server may be Apache but they would still be running a CGI plugin such as WC or Lasso the same as I use WebSTAR and Lasso plugin.

The main difference with this setup is that all communication is done over port 80 and then 591 internally (or which ever port you tell Lasso and WC to use).

This allows you to close 591 on your router and tell WC on the FMPro clients to use 591 when talking to Lasso internally (TCP/IP accross your RAIC, or Apple Events on the same machine) you can also tell WC to only accept requests from the IP address of your webserver (this feature is also available with WC only). This also adds another level of security aswell as getting rid of the annoying :591 off URLs.

All that said.........the best security feature of my setup is that I use apple Macs!

[ July 30, 2001: Message edited by: scratchmalogicalwax ]

[proton]

quote:

---

Originally posted by Eric Rasmussen:

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?

---

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 ]

[erasmussen]

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

[erasmussen]

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

[John May - Point In Space]

As far as I can tell, Lasso (even with the CDML compatibility module) doesn't allow usage of the -raw action.

- John

[proton]

quote:

---

Originally posted by Eric Rasmussen:

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

---

But you can block access to fields on a field by field basis using Filemaker Access Privileges. It is true that the web security databases offers a host of functions that can not be got by using just Filemaker Access Privileges, but if one is using just Access Privileges, and is blocking the fields. How can someone still access the data? Particularly if the field is set as access denied in the access privileges.

Also, when using Access Privileges, the users still have to input a password when accessing the database online. It is just that no username is associated with the password. Awaiting a reply to these rants.

[Anatoli]

I still do not know, what is all this about?

Give me please 1 example, how the names of databases running, or anything else mentioned above can help someone to gain access more, than I intended to publish on web.

I am not storing my credit cards numbers in web database.

[Charlie Boisseau]

I have finished the first version of my program. So far I have just made it so that it can download all the db names, layouts, scripts and fields. I have analized your site with it Anatoli. See the screen dump.

What do ya'll think?

I'll let you know once I've finished the interigation part.

Cheers

Charlie

[scratchmalogicalwax]

chazboi.......thats impressive but does this allow you to download the databases or gain remote control of them and access information stored within without anatoli's permission (not that you would cos that would constitute an illegal act )

Also can you leech the same info from Lasso?

PS nice to see a Mac window

[ August 02, 2001: Message edited by: scratchmalogicalwax ]

[iBib]

OMG!!!

That nifty little program looks awesome!

How good is the program to penetrate any defences?

[Charlie Boisseau]

That's what I am working on. The built in XML format files should let me set the program to interrogate any database, any layout with a set of field values and return results into a list box. Also you should be able to edit and delete records if you specify a record ID, which can be done automatically with the program. However, your actions are restricted by the web security database. Most people don't use this thoroughly enough though.

[proton]

quote:

---

Originally posted by chazboi:

That's what I am working on. The built in XML format files should let me set the program to interrogate any database, any layout with a set of field values and return results into a list box. Also you should be able to edit and delete records if you specify a record ID, which can be done automatically with the program. However, your actions are restricted by the web security database. Most people don't use this thoroughly enough though.

---

This is exactly what I am saying. Yes, you can see a list of layouts and databases that I have hosted on my site, and you can see a list of fieldnames as well. But how are you going to get my data if I have your privileges set to not be able to access a certain field? Or if I have your privilges set to not allow you to delete? How then are you going to access my data?

That's my primary concern. I don't plan on using scripts in my database so I'm not worried about that. And if someone can see my layouts and fieldnames, so what? It's the data I'm worried about. Awaiting your reply.

[Charlie Boisseau]

Exactly.. The problem is that FileMaker don't publish this. If they did people would naturally be worried about it and they would tighten up the security so that that information shouldn't matter.

On a lighter note: I have had the program running for a day and I have found it a really useful tool. It's really good for quickly getting field names from a remote server. I should put it up on shareware.

[Anatoli]

Yeah, that is all public, like everything on web.

Cloud you do something with all this information?

[Charlie Boisseau]

Only if the security was set up poorly... That is what I am trying to say. Most sites aren't immune to an attack from someone armed with this. I hope anyone reading this will make sure that their sites are safe.

[Arin]

Right, as long as fields that NEED to be protected are covered by Web Security Databse Field Restrictions, such as "DontShow" then they are protected am I correct?

Basically all this means is that everyone needs to make sure that their solutions are secured by the WS Database, and not "secure" through layout/format restrictions or ommisions.

On the bright side it seems that in light of the -Raw tag it's a lot less important to try keep your FMPro? URL's hidden.

[Charlie Boisseau]

Yes you are right (as far as I know). The field restrictions should stop individual fields from being viewed.