Jump to content

WebDirect URL editing


This topic is 3193 days old. Please don't post here. Open a new topic instead.

Recommended Posts

We have been struggling to deal with the fact that anyone can manually edit the WebDirect URL to gain access to things that they normally wouldn't, from IWP or even Client versions. Is there any way to disable this glaring security flaw in WebDirect? Ideally, there would be a switch we could enable or disable to mask the URL (similarly to IWP) or not, as desired. Currently, here are the workarounds we've come up with:

 

/fmi/webd#<database>&lay=<layout name>&viewstyle=<form/list>&record=<record number>&mode=<browse/find>

 

1) Database: Technically not an egregious security hole, since you should have all your databases secured with login authentication anyways. This is fine.

 

2) Layout: A huge problem, with many potential kludgy partial solutions. Part of what complicates this is that changing the layout name to a layout of another table will set them at record number 1, full found count. For reference, the only direct way to stop them from going directly to a layout is to remove it from the user's security privileges. Here are some solutions we've bandied about (none of them are foolproof and/or easy to implement in a large existing solution):

 

   a) Using custom security options, lock the first record of every table, so that WebDirect users have no access to them. Combine with locked down toolbar and menu to effectively lock a user from seeing data they shouldn't. Downsides are obvious if the user actually needs to access the first record of a table. Also, this might not effectively stop all button scripts from firing and causing problems.

   b ) Name each layout with a long string of numbers and letters, making them unguessable. Downsides for developers is the obvious horror of maintenance on such a solution, and nothing stops the user from copying the layout name from one session into another.

   c) Using custom security options, lock every record for WebDirect users, on the condition that Get(LayoutName) = $$CurrentLayout, AND make sure ALL scripted layout navigation includes the appropriate Set Variable step. Downsides include a lot of work for large systems (less work if all navigation is funneled through a specific script or set of scripts).

 

The ideal fix for this is to either a) disallow layout access to layouts not listed in the layout list, or b ) allow calculation engine-driven layout permissions, as done with records and fields.

 

3) Viewstyle: Manually edit all layouts accessible to WebDirect users to remove either form or list view, as desired. This is easily done, but a tedious and repetitive task for very large systems. Also, requires each accessible layout to be single-function, or else a user might be able to see a list view when you are not ready for them to.

 

4) Record number: Hide and Lock (locking is important) the toolbar. As long as it remains hidden AND locked at all times, the WebDirect users cannot manually jump to another record.

 

5) Mode: In layout mode, select all layout objects, and set them to non-modifiable in Find mode (or Browse mode, if that's your desire). Repeat for EACH accessible layout. This will not stop users from entering Find mode, but it will stop them from doing anything in it that you do not want them to.

Link to comment
Share on other sites

Record Level Access is what I described in points 2) a and c, and layout based control of the window view (List, Form) is also described as my solution for point 3). Unfortunately, custom layout privileges in the security schema UI are of little use to me, since the problem chiefly exists with layouts I need the user to access at some point, but I do NOT want them to simply access at will. If we had the same "limited" security controls as records do, that could work, but I imagine that is too big of a change to easily implement for FileMaker.

 

As I said, I'd be perfectly content with WebDirect restricting direct layout access via URL to layouts that are only in the layout menu (in which case we'd simply remove all layouts from the menu except for the launching layout, which would restrict all navigation to scripts only).

Link to comment
Share on other sites

Steven

 

By locking down the toolbar you can keep the user in the pro client restricted to  layouts and records. I don't see what you mean by "some of these same issues exist in the desktop Pro client as well."  We also have noticed the big flaw in Web direct as we are unable to restrict access to the URL navigation. Why do I need to develop a workaround on a brand new product. Not well thought out in my opinion.

Link to comment
Share on other sites

Steven

 

By locking down the toolbar you can keep the user in the pro client restricted to  layouts and records. I don't see what you mean by "some of these same issues exist in the desktop Pro client as well."  

 

This is a commonly and widely-held belief.  But it is not correct. The UI is not part of the security schema.

 

This was part of the presentation I made in Chicago in October at the FileMaker Product Conference. In addition, there was an extended thread here on FM Forums at around the same time:

 

http://fmforums.com/forum/topic/90015-is-securing-a-stand-alone-fmp12-solution-really-that-hard/?hl=product+conference#entry413123

 

 

 

Steven

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
  • Newbies

Does this also relate (to what I understand to be possible) of embedding via an iframe, a FM13 form into a WordPress website? Is what's being discussed above if the user has access to the database(s) with the expanded layout of Webdirect vs the IWP view which limited functionality.

Link to comment
Share on other sites

Not exactly. The expanded layout you're referring to, I think, is the Filemaker Toolbar, which can be hidden along with menus via script step (though some report seeing it flashing briefly on file open, on slower browsers. This can reportedly be fixed by opening the file directly, off server, hiding the toolbar, then closing and re-hosting the file, but I haven't tried it myself yet). The problems described above are related only to accessing WebDirect directly in the main window, not when embedded in an iframe. In fact, we've discovered embedding it in an iframe is the only way to really lock down casual user URL editing. It is NOT a truly secure measure, though, since anyone can still access your webdirect address directly, if they happen to know it. Still, it is pretty useful.

Link to comment
Share on other sites

  • 3 months later...

I haven't used WebDirect much, but...

 

What about an OnLayoutEntry trigger that navigates away from the layout, unless some condition is met (perhaps via a global variable)? You've have to add that condition to the navigation scripts.

 

Is it true that WebDirect always defaults to the full record count, or is it like a FileMaker client that goes to the last found set for that TO? The default may be based on the found set of when the file was last closed locally, but I'm not sure. You could also have a startup script run through each layout and do a Show All/Show Omitted only.

 

Actually that might be the simplest to implement, an on LayoutTrigger that does a Show All/Show Omitted.

 

Yes, it's all still kludgy.

 

 

 


2) Layout: A huge problem, with many potential kludgy partial solutions. Part of what complicates this is that changing the layout name to a layout of another table will set them at record number 1, full found count. For reference, the only direct way to stop them from going directly to a layout is to remove it from the user's security privileges. Here are some solutions we've bandied about (none of them are foolproof and/or easy to implement in a large existing solution):

 

   a) Using custom security options, lock the first record of every table, so that WebDirect users have no access to them. Combine with locked down toolbar and menu to effectively lock a user from seeing data they shouldn't. Downsides are obvious if the user actually needs to access the first record of a table. Also, this might not effectively stop all button scripts from firing and causing problems.

   b ) Name each layout with a long string of numbers and letters, making them unguessable. Downsides for developers is the obvious horror of maintenance on such a solution, and nothing stops the user from copying the layout name from one session into another.

   c) Using custom security options, lock every record for WebDirect users, on the condition that Get(LayoutName) = $$CurrentLayout, AND make sure ALL scripted layout navigation includes the appropriate Set Variable step. Downsides include a lot of work for large systems (less work if all navigation is funneled through a specific script or set of scripts).

 

The ideal fix for this is to either a) disallow layout access to layouts not listed in the layout list, or b ) allow calculation engine-driven layout permissions, as done with records and fields.

  • Like 1
Link to comment
Share on other sites

Please note that the FileMaker Server 13.0v2 updater, issued earlier today, addresses the issue of the browser toolbar edits.

 

http://thefmkb.com/13183.

 

Steven

Yeap, "The capability to specify URL parameters or to bookmark specific locations within FileMaker WebDirect solutions has been removed for security reasons. You now specify only a filename in the URL to open that file.

"

It was a glaring hole, good to see it addressed and a pretty solid v. .02 update too, lots of fixes.

Link to comment
Share on other sites

  • 3 weeks later...
Here is an ugly flaw....
 
Once a normal user get's past all the regular security. They land on their record of choice.
In the url there is a part that says, "record=1"
If the user changes it to "record=2" right now, nothing really happens.
If the user does a refresh. Nothing really happens either.
But after the refresh, the user can change the url to read "record=4" and up pops a different record.
In fact you can change it to any record number you want.
 
Pretty ugly if you are serving secure info on these records?
 
Any ideas?
I'm serving on IIS
Can I do a custom cgi and still tie it to WebDirect?
Or, how about a php page with custom parameters that refeeds from WebDirect? Will it let me with the constant connection it wants to keep?
 
Link to comment
Share on other sites

I've have a workaround that may be convenient for everyone. I created an html file with a singe iframe. This will mask all the url dirty work in the browser.

 

<html><body style="margin:0px">
<iframe src="https://www.myserver.here/fmi/webd#MyExampleDatabase" width="100%" height="100%" frameborder=0 seamless>
</iframe>
</body></html>


Link to comment
Share on other sites

  • 2 weeks later...

 

Here is an ugly flaw....
 
Once a normal user get's past all the regular security. They land on their record of choice.
In the url there is a part that says, "record=1"
If the user changes it to "record=2" right now, nothing really happens.
If the user does a refresh. Nothing really happens either.
But after the refresh, the user can change the url to read "record=4" and up pops a different record.
In fact you can change it to any record number you want.
 
Pretty ugly if you are serving secure info on these records?
 
 

 

 

First, I am not seeing this with FileMaker Server 13.0v2.  Are you sure you are running the v2 updated FMS?  The so-called "deep linking" was removed in that updater.

 

Second, is the information truly is secured with appropriate Privilege Set options, then an unauthorized user will not see that information irrespective of the record or how that user got to the record.

 

Steven

Link to comment
Share on other sites

  • 1 month later...

Any updates about this issue?

 

I am very happy with my IWP solution but have committed to converting it to Web Direct but this issue is a show stopper!  I fooled around with the iFrame hack but really anyone with a little bit of HTML knowledge could easy by pass it.  I have the latest version of server installed "13.0.3.300" .  

 

It's really scary to think a user could just change the record ID - reload the browser and magically become another user......  

 

Perhaps I'm missing something - if so please enlighten me.

 

Ramble On!

 

Jordan

 

 

Link to comment
Share on other sites

Like Steven wrote, deep linking was removed in FMS13.0v2

So, you can only link to a specific WD file, but not inside the solution.

This was due to security concerns.

The url will not display anything other than the path to the file, that is open.

Also, make sure that your solution are properly secured with privileges sets.

Link to comment
Share on other sites

  • 2 weeks later...

I was using the deep linking technique!!!

http://<IP address>:<Port number>/fmi/webd#<database name>&lay=<layout name>&viewstyle=<view>&record=<record number>&mode=<mode>

Now that's its removed I am screwed.

It is the only quick and easy way to land on a specific record from a web link.

I was using it in emails, the user clicks the link and land on their own profile which is public information anyway and did not have to be secured.

 

Why cant you pass a variable into to FM simply?

 

I guess it is PHP for me.

Link to comment
Share on other sites

Currently, your only option is to use script triggers e.g. on layout enter, to do the navigation, e.g. based on the user name.

Or, a start layout, where the user e.g. identify themselves.

 

In the future, there might be some ways to do some kind of variable passing or other methods to bring back some of that functionality.

I would encourage you to write a feature request on FMI website. They are actually reading all of them.

Link to comment
Share on other sites

  • 8 months later...

Updates on this issue? The current db I am building still shows both menu and layout bars for a second when first loading. Using triple8 hosting right now not sure what version of the server they are using but it must be higher than 13.0.2 as it does only use one address for the whole db. I am just afraid to publish my db if someone might be able to quickly access those commands even if for a second.

Link to comment
Share on other sites

  • 3 months later...

I just did a job recently where I used a PHP page to accept the parameters, create a log record in FileMaker and then send the person on to IWP/WebDirect. The startup script checks the account that is logging in and then checks for a log record in the past few minutes and retrieves the parameters from that log to know where to send the client. I'm sure it's got some kind of security hole in it, but I don't immediately see where that might be if you take care to check for out-of-bounds parameters. The user has to know their username and password to take advantage of the solution, so I don't think it's TOO insecure.

Link to comment
Share on other sites

This topic is 3193 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.