• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Security level - some considerations

lcollong

FabriKant d'applications web
Hi,

I've recently realized how easy it could be for someone to list some hidden tables.

In several apps, I use a lot of Fabrik's list together with a private area on the front (intranet, extranet). Most of the list are displayed through J! menus. These menus are reserved to some J! users access levels. Thus, public visitors can't have access to these lists. I use to carefully tuned them regarding ACL permissions. Except if there are good reasons for that (public access data), almost none of these rights are under the registred level.

Even on a SEF enable site, it's easy for someone (or a bot) knowing a little bit of Joomla and Fabrik, to test url like www.mysite.com/index.php?option=com_fabrik&view=list&listid=X
For most of them the answer will be a 500 error with an "incorrect list id" message (which is a proof of the Fabrik engine presence if you have no htacess redirection on this error number). For all the list used on the private part, the answer will be something like "you do not have right to access this ressource". Which is also a kind of encouragement to test further.

I also use some "service tables" to store parameters, internal rights, logs, n-m relationships table and so on. Most of them are not used in menus. There are used in DBjoin element, CDD, Php plugin etc... They are "hidden", so I've missed to change the ACL since I never "call" them directly on the front part of the app. These tables show up nicely with all their data after some tries on the listid number ! Including the #__users one I use frequently to check the app's right against the logged user.

Of course, this is not a Fabrik problem. I should have check ACL on all the list. It's a "programmer failure".

However, I think it could help to have the default ACL level on list creation set to "registred" rather than "public". Or at least that a parameter should give us the opportunity to set this default value for all further list creation. Or, ideally, to have a kind of batch process allowing us to set ACL on all the list.

Another solution I'll probably use meanwhile is to modify the default list template so that it throw a kind of "error 404 message" instead of displaying the table's data. But I guess I need to do it also for the detail and form template.

Just some thoughts......
 
Some SQL I've used to figure how many list where involved and modify ACL for those left in the "default" mode.
If it may help. Use with caution. It may break your setup. Always backup before modify anything directly in the Fabrik's tables.
 

Attachments

  • mass action on Fabrik list ACL.zip
    964 bytes · Views: 132
+1
Yes, it would be nice to have configurable list default settings.
I just tried with the content_type feature but this doesn't take over the list settings, only elements and groups.

So it could be in Fabrik Options and/or in content_types.
 
Don't know what is "content_type feature" ? What are you talking about ?

Meanwhile I wrote a "quick'n dirty little script" to check a given url again possible "open" lists.
I put it here in case some one would like to play with it and/or improve it. There is a lot to do ! :)

May be such a tool could be included in Fabrik core ? I would imagine some "magic url" like :
...index.php?option=com_fabrik&checkacl
which would go through all the lists verifying acl vs current registered user (or not). Debug switch dependent of course.
 

Attachments

  • checkFabrikAcl.zip
    1.3 KB · Views: 130
Content types: I thought there was something in the WIKI but I can't find it.
Rob added it about a year ago.
There's a new column "Content Type" in the form listing. You can "Export" your form and then use this exported content type during the list creation process (your new list will have the same groups and elements).
The created file (administrator\components\com_fabrik\models\content_types\your-form.xml) can be copied to other Fabrik installations, so it's some sort of "Package" feature.
 
Yes of course I know it. Indeed, could be a nice way to set some kind of default setup for further list creation.
I usually don't use it as I prefer set table dependent name for the columns (cust_id, cust_name, cust_address, etc...). I know Fabrik does it already with the "full name" but it makes things easier on big app with a lot of elements and external scripts doing extensive additional SQL.
 
In principle, I don't have a problem with changing the defaults for list ACL's to be Registered. And even set Delete to be Special.

@troester - can you think of any potential gotchas with doing that? It wouldn't affect existing lists, just new ones.

-- hugh
 
It would be really cool to have default access configurations, for lists and elements, in the Fabrik Global Configuration. Is that a big ask?
 
Hmmm. Not technically difficult, but potentially time consuming. Anything to do with adding global config settings, and inheriting those elsewhere, tends to involve a lot of tedious coding.

If I can't think of any gotchas with changing the defaults on list ACLs, I'll have a look at doing it when I do that, at least for lists to start with.

-- hugh
 
Hmmm. Not technically difficult, but potentially time consuming. Anything to do with adding global config settings, and inheriting those elsewhere, tends to involve a lot of tedious coding.

If I can't think of any gotchas with changing the defaults on list ACLs, I'll have a look at doing it when I do that, at least for lists to start with.

-- hugh

A lot of tedious coding for you, but potentially hours less tedious configuring for me :D
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top