web security db and -find

clevow · January 25, 2002

I'm having a problem with the web security database. I didn't know it existed until an hour ago, so I'm new to it.

Web Security DB is set up as:

All Databases

All Users (no password): Browse Create Edit

Field name "sodsc": Exact Search

There is no security set up on the database called "PROJECTS.FP5" which is the one I'm working on now.

The URL that I'm using is:

http://xxxxxxxxxx:591/projects/FMPro?-db=PROJECTS.FP5&-format=search_results.html&-lay=Project&-Error=search_results.html&sodsc=EP9D43o5iQ5L&-find=

I get a javascript pop up returned that says:

Access Restriction:

You do not have access privileges to perform the action: find

There is at least one record in the PROJECTS.FP5 database that has the field sodsc equal to EP9D43o5iQ5L.

For the record, I'm using FMP 5.5 on a Win2k box running IIS. I'm using custom web publishing, security is set to use the web security database.

Why am I getting this error?

Thanks for your help,

Carrie

Garry Claridge · January 25, 2002

I would remove the "Exact Search" restriction, I believe this is causing the security violation.

All the best.

Garry

Keith M. Davie · January 25, 2002

First, All Databases should be deleted.

Next, create a new record project.fp5 and set your permissions.

Also, you may want to visit the FileMaker site and find (and read) the .pdf document on Web Security. It is sort of interesting to a FM developer.

Also you need to be aware of the problems associated with a single-threaded ScriptMaker engine encountering near-simultaneous requests over the mutli-threaded www. If you do not take precautions in this regard you may find that data gets lostg while a client gets mis-informed. This issue has been widely discussed on the Internet forums over the past year. Do not dismiss this as unlikely to occur.

I am now scheduled to get a broadband hook-up this Monday. However, this hook-up was promised three weeks ago, so we'll see. (I'm posting this from a public library.) In any event, once I get set up and get a couple of days to trouble-shoot and tie up some loose ends, I will be posting that site on the cdml forum. It will provide a demonstration of the workaround to the script problem. You will be able to test it for yourself at that time. Prior to that, you may want to make yourself aware of the problem as it exists. A lot of info has been posted on the cdml forum.

SIMPLIFY ...

Keith

[ January 25, 2002: Message edited by: Keith M. Davie ]

Anatoli · January 25, 2002

RE: Ultimately, what I'm trying to do is have as secure a database as possible without having users enter ids and passwords.

No way with FileMaker frown.gif" border="0

Anyone can list all your records in any database in any layout and call any script by name. Search forum for this...

Garry Claridge · January 25, 2002

How does the user enter their "Username", and how is the "sodsc" generated for each session (i.e. how is the URL formed containing the "sodsc")?

You may be able to use a combination of Cookies, [FMP-IF] and [FMP-Include] tags in the first format page called by the URL.

There are ways!

Garry

clevow · January 25, 2002

Shouldn't All Databases work? I'm going to need this for all my databases; I just happen to be working on the one right now.

Where do scripts come into play at all with this? I'm not running any scripts in my databases, and as far as I can tell the security databases don't have any that matter. I have read the forum pretty extensively about scripting and have been convinced that avoiding them is a good idea. So far, that's been perfectly fine.

Anatoli, I'm not looking for any major security here, just some. If I can restrict access to all records that aren't associated with that 12 digit string, no one should be able to look at those other records. I know that string will be visible, but it's pretty darn hard to crack a 12 digit randomly generated string.

The users of this database will be 20 staff members of mine, all of whom are undergraduate computer geeks. That's why I need security at all, just to keep them from easily screwing stuff up.

No one will have delete access to anything, if I can help it, and no one will be able to submit anything under someone else's ID (campus security scheme will prevent that). So as long as I can make it very difficult to get view access to certain records, I'll be okay.

-Carrie

clevow · January 25, 2002

Garry,

The users enter the site via a CGI that uses our campus authentication scheme (WRAP). They have to enter their campus username and password in order to gain access to the CGI at all. There is no way around this. They will get dumped back to that login screen from any web page they try to access.

Contained within that CGI is a bunch of "if" statements that say if username=X then sodsc=12 digit string. I have a finite number of users, currently ~20 so that's not a big deal. These are my staff members, and there will never be that many. I've got 50 12-character strings, just in case.

The URL is formed with the CGI saying to substitute the correct sodsc in the place of $sodsc:

$url="http://xxxxxxx:591/projects/FMPro?-db=PROJECTS.FP5&sodsc=$sodsc&-format=search_results.html&-lay=Project&-Error=search_results.html&-token=$user&-find=";

print "Location: $urlnn";

[ January 25, 2002: Message edited by: Carrie ]

Garry Claridge · January 25, 2002

You could also assign the 'sodsc' to a second token, as such:

&sodsc=$sodsc&-format=search_results.html&-lay=Project&-Error=search_results.html&-token.1=$user&-token.2=$sodsc&-find="

Then at the beginning of the 'search_results.html' page have:

[FMP-If: CurrentToken:2 .eq.]

[FMP-Include: noway.html]

[FMP-Else]

either have the original html of 'search_results.html' or include another file.

[/FMP-If]

This may add some security.

Garry

clevow · January 25, 2002

Hmmm....

I could do if current token = the sodsc on that record, view the record else noway.html.... that might work. I'll give that try. Thanks a lot.

-Carrie

Anatoli · January 26, 2002

RE: If I can restrict access to all records that aren't associated with that 12 digit string, no one should be able to look at those other records.

How? You can't. Read this forum on Web Security issues.

Just try http://yourURL:591/FMPro?-db=youranydb.fp5&-format=-raw&-findall if you are serving on port 591. Or without the :591

shocked.gif" border="0

clevow · January 26, 2002

but if the web security database has the "exactsearch" option selected for the sodsc field, then the findall command is disabled essentially. or so i thought....

clevow · January 26, 2002

I need to keep the exact search for security purposes.

Ultimately, what I'm trying to do is have as secure a database as possible without having users enter ids and passwords. As it stands now, I have a script that reads in a username from our campus authentication scheme. It then assigns a preselected 12 character random string as the field "sodsc." A find is performed via the URL I listed before. I'm trying to prevent someone from just taking the sodsc=xxxx out of the URL and being able to find all the records in the database. If it is required that string match exactly, they can't just eliminate it. And if they manage to guess or crack someone else's 12 character random string, more power to them.

Thanks,

Carrie

Anatoli · January 26, 2002

smile.gif" border="0

This has nothing to do with your security settings! Everyone in the world equipped with Internet connection and browser can list all your as well as mine databases WITHOUT ANY PASSWORD WHATSOEVER.

Until FMI does something about that FM is WIDE OPEN TO EVERYONE!

It is job for around 1 hour, and FMI is just neglecting this.

Because FMI doesn't respond to any of such reports I will probably post report of this major security hole to all boards everywhere. FMI is behaving much worse, than Microsoft.

mad.gif" border="0

Garry Claridge · January 27, 2002

Carrie,

I was just looking over your original question and found that the URL was missing the "&-op=eq&" tag. Including this will allow you to do what you wish. In combination it with the [FMP-If] and [FMP-Include] tags you can feel reasonably secure.

I tested "Web Security/Exact Match" with '-raw' and '-fmp_xml' and '-findall'. It excluded all attempts.

All the best.

Garry

clevow · January 27, 2002

Cool. Thanks. I'll check that out tomorrow when I'm back at work. If that doesn't work, I'll check into the other solution you offered.

Thanks for the help.

-Carrie

Anatoli · January 27, 2002

RE: Carrie,

I was just looking over your original question and found that the URL was missing the "&-op=eq&" tag. Including this will allow you to do what you wish. In combination it with the [FMP-If] and [FMP-Include] tags you can feel reasonably secure.

I tested "Web Security/Exact Match" with '-raw' and '-fmp_xml' and '-findall'. It excluded all attempts.

All the best.

Garry

Garry,

this has nothing to do with Web Security database!

The command FMPro?-db=database.fp5&-format=-raw&-findall can be executed with or without setting in Security Database, just try that.

Even if you will disable all access it still displays everything from the database.

Let's do the test. Give me URL address of your hosted database and I will see everything from it.

Did you look at the thread "Security Loophole"? There is even tool for displaying everything from this talented "chazboi" gentleman!

Steven H. Blackwell · January 27, 2002

For reasons having nothing to do with CDML or XML, I don't think this database is very secure.

Old Advance Man

Garry Claridge · January 27, 2002

That is correct. I had port 5003 open on my router (Apple Airport). I just use this for testing. I've now closed that port on the router and the new IP is 210.84.184.26

We are currently testing the 'strength' of the "Exact Search" feature of the "Web Security" database. Any positive input appreciated!

All the best.

Garry

Anatoli · January 27, 2002

IMHO -- the "Exact Search" is displaying just result from single field with "Exact Search".

How do you then display another 100 fields? They cannot be "Exact Search" matched in WS databases.

As soon that will be in use, with the -raw format all fields (maybe without the "Exact Search" field) are downloadable.

Your "Exact Search" is not working for http://210.84.184.26:1154/FMPro?-dbnames not for http://210.84.184.26:1154/FMPro?-db=combotest.fp5&-layoutnames and not for http://210.84.184.26:1154/FMPro?-db=combotest.fp5&-scriptnames

That is real problem in any security requirements.

I just received first two protection programs.

First is blocking application, doesn't work very well and the second is for Mac based on modification (hacking) of WC.

Anatoli · January 28, 2002

RE: Exact search.

This link is the right syntax for Exact search:

http://localhost/FMPro?-db=test.fp5&-Op=eq&id=1&-format=-raw&-find

It also reveals all content of all fields + names of fields.

To use the exact search for slightly better security there are 2 ways:

1. hidden field. That is ok until hacker gets the hidden field, work for 1 minute.

2. all users must enter "secret code" into "exact search" field. That will be the best security so far, but who wants to bother user with that?

Any other ideas?

Garry Claridge · January 28, 2002

Anatoli,

Try this:

http://210.84.184.26:1154/FMPro?-db=combotest.fp5&-lay=web&-format=hworld.html&-op=eq&tryme=hello&-find

The format file contains other fields.

I know that "Exact Search" does not stop somebody from seeing the names of databases, layouts and fields. However, if you don't mind this, your data is safe.

All the best.

Garry

Anatoli · January 28, 2002

http://210.84.184.26:1154/FMPro?-db=combotest.fp5&-lay=web&-format=-raw&-op=eq&tryme=hello&-find

will again reveal more than any author wishes.

And to use fixed "exact search" is no security at all. I am trying improving on existing FMI web software for 3 years and it is still open to the world. But our protection gizmos are promising.

Garry Claridge · January 28, 2002

Any fields with "Dont Show" checked in the "Web Security" database will not return data with the '-raw' format.

This could be a pain setting-up a lot of fields which need to be protected. However, it does the job of hiding the data.

I'm learning more everyday!

All the best.

Garry

Anatoli · January 28, 2002

That is very unlikely someone can really use that. Other people might need that. Furthermore, to use fixed value "exact search" is no security at all. That is good for password fields, direct access to not shared info etc.

Have good day! I am going to bed smile.gif" border="0

Garry Claridge · January 28, 2002

Anatoli,

I have tested it. Here is the URL for a test database; this is a dial-up however the IP address should be OK for about the next 6 hours.

http://210.84.184.26:1154/FMPro?-db=combotest.fp5&-format=-raw&-findall

I have an exact match restriction on the field "tryme". Try the values "hello" and "help"; I only have two records in the database.

Good Luck.

Garry

Keith M. Davie · January 29, 2002

Sorry for the delay in responding, I've been having 'puter troubles. Am responding from a public library today.

On the 25th Carrie asked (I assume in regards to my earlier response), "Where do scripts come into play at all with this?"

Gee, I don't know Carrie. I guess it was your statement prior to my response which went, "As it stands now, I have a script that reads in a username from our campus authentication scheme. It then assigns a preselected 12 character random string as the field "sodsc.""

I took that statement to mean what it said. Sorry to have troubled you with my response to it.

SIMPLIFY ...

Keith

clevow · February 1, 2002

ah. my script is external to filemaker. it's a perl script that generates the URL that does the initial find in filemaker. i'm trying really hard not to use scripts within filemaker, at least for the web.

Anatoli · February 8, 2002

What will happen with request like:

http://www.url.com/FMPro?-db=yourfm.fp5&-format=-raw&-findall

and the other "hacking" syntax?

Hammerton · February 9, 2002

Happily, the answer is "nothing". Nothing happens when localhost is the front door. Nothing happens when localhost is the FMP machine. Cool huh? Tell the people at IPNetSentry that Dr.J sent you.

Hammerton · February 9, 2002

I have employed the following set-up to enhance security. Webstar on one Macbox, filemaker on a separate Macbox which runs IPNetsentry set to exclude all remote requests other than those coming from the front door Webstar server.

IPNetSentry is designed to monitor and filter and block various types of requests to the TCP/IP connection. It can be set up to block all requests to filemaker other than those coming from your own server. Seems to work, but I'm no pro.

http://www.sustworks.com/site/prod_ipns_overview.html

Anatoli · February 9, 2002

Great! It is probably based on the same principle like we are developing for Windows.

FM did lousy job with security in WebCompanion

camcorp · February 12, 2002

Wow

what kind of application is Filemaker that can expose critical data to hackers.

I put to work all hacking commands in the filemaker website, and they really don't work. It is consequence of the use of apache servers that can denied any specific URl. I read somewhere else in this forum that eith the use of apache and some url restrictions you can avoid the problem with this hacking code.

Does anybody have a list of this hacking code, and some way to protect from hackers. What will happened with custom security or login solutions based in filemaker, should we move to a web server solution??

regards,

cAmcOrp

Garry Claridge · February 12, 2002

cAmcOrp,

The two main offenders are the '-raw' and '-fmp_xml' tags. However, use of the 'Web Security' database can reduce their effectiveness in some situations. The use of a web server with 'FM Unlimited' and the 'Web Connector' can also help.

All the best.

Garry

Keith M. Davie · February 12, 2002

On Jan. 27, Garry wrote, "Any fields with "Dont Show" checked in the "Web Security" database will not return data with the '-raw' format."

I think I see a problem in this discussion.

-----

I have format files and a db which I used for this test, events_.fp3. I set Web Security for events_.fp3 as follows:

User Name: all users

User Password: blank (none)

User Permissions: blank (none)

Field Name: Field Restrictions:

expire Don't Show

toady Don't Show

parse Don't Show

Run over a fake LAN I can display data from these fields called by html/cdml vis a vis my format files and on a record-by-record basis.

When I use the force command (&-format=-raw&-findall) in the url I can display all the data in all the fields in all the records from that db in my browser window.

Let's say you have a site which, when accessed, pops-up a window which requires a name and password (the standard FileMaker entry). For the public you tell them enter the word "ethereal". When they do they gain access to certain databases and format files. When you or your trusted parties get this dialog box they enter their name and individual password and get access to other databases through their browser. If a public client uses something like D-Base the "private" databases will be listed (in D-Base, assuming it is used) since those db files are being served through WC over the web at the xxx.xxx.xxx.xxx which is also displayed. That "private", password protected database can have all its data accessed and displayed in a browser even with all the field restrictions checked through the use of the force command.

--

I'm not sure, but I think we are talking about two different things. I believe that Garry is referring to using a cdml tag which includes the raw parameter on a format file, and that such a tag will not display data if the field has been marked "Don't Show" in Web Security.

[ February 12, 2002, 02:32 PM: Message edited by: Keith M. Davie ]

Anatoli · February 12, 2002

The FileMaker site interrogated with http://prdb.filemaker.com/FMPro?-dbnames URL is sending to the browser:

0 ets fsa_stories poweredby etspr_login_temp etspr_login ets_Questionnaire_temp ets_Questionnaire contacts fm_newsletter web_survey xmlstory madewithfm resellers PlugInReg tirelevence ti contactsales customerassistance PRYourStory Evaluation Stories intl PReval Press_Edit PressExt PRCustStories PR feedback jobsext jobemail Web Fields_ Web Security

The link http://tidb.filemaker.com/ti/FMPro?-db=ti.fp5&-findall=&-format=-raw

is also working.

To use "don't show" is OK for fields, which are not for web which in my design is around 10%.

To use "exact search" is OK in some cases, but not always.

WSC offers no protection, but some kind of filter, proxy filter can help in 10-100%.

Sign In

web security db and -find

Recommended Posts

Create an account or sign in to comment

Create an account

Sign in

Important Information