akeeba / fof

Rapid Application Development framework for Joomla!™ 3 and 4
0 stars 0 forks source link

Upgrading to version >= 3.0.16 introduces ACL problem #643

Closed viryagroupdev closed 7 years ago

viryagroupdev commented 7 years ago

In our fof3 based component we have a custom account creation process which is now broken on the first step when using fof 3.0.17. Reverting to 3.0.15 will yield the desired behaviour

The view displays fine index.php?option=com_weconnect_business&view=Registration&layout=self

The form submission / "apply" task, which works fine in fof 3.0.15 and before, results in a 403 after upgrading to 3.0.16 or higher (3.0.17 )

Posts to

        <form action="<?php echo \JRoute::_('index.php'); ?>" method="post" name="adminForm" id="adminForm" class="form-horizontal form-validate">
            <input type="hidden" name="option" value="<?php echo $this->container->componentName; ?>" />
            <input type="hidden" name="view" value="<?php echo $this->getName(); ?>" />
            <input type="hidden" name="task" value="apply" />
            <input type="hidden" name="<?php echo $model->getKeyName() ?>" value="<?php echo $model->getId(); ?>" />
            <input type="hidden" name="format" value="<?php echo $this->container->input->getCmd('format', 'html'); ?>" />

After rendering

        ...
        <form action="/en/womens-business-enterprises/apply-now/register-selfreg" 
                     method="post" name="adminForm" id="adminForm" class="form-horizontal form-validate">
            <input type="hidden" name="option" value="com_weconnect_business" />
            <input type="hidden" name="view" value="Registration" />
            <input type="hidden" name="task" value="apply" />
        ...

Any thoughts on what happened and how to correct

nikosdion commented 7 years ago

Yes, I know exactly what happened. It's all about two security related commits.

The first commit is 4f1525674657193163236c71557d9ccce235c061 "# [MEDIUM] Joomla returns null instead of false in some ACL checks". I addressed a security issue affecting all versions of Joomla! 3 (at least since 3.2, I didn't bother with older versions). I also reported the security issue to the JSST, offered a solution and it was applied in Joomla! 3.6.5. 

The second commit is f530c951a5a6073013a4c9638644d3fe00a7e28b "# [HIGH] Checking against method ACL rules (&something) returning an event alias (@whatever) always returns true without evaluating the event alias". 

Both bugs did affect the save and apply tasks in controllers inheriting from FOF's DataController. Namely, FOF wouldn't be able to check whether the currently logged in user had core.create privileges. As a result any user, including guest, could save arbitrary data to the database.

The solution to your problem is adding a custom ACL entry in the taskPrivileges array of your Controller. Assuming that you want everyone to submit data to the Controller using apply you need to do $this->taskPrivileges['apply'] = true; in your constructor. Otherwise you can override the function getACLForApplySave since this is exactly what is being called when evaluating the ACL privileges for the apply and save tasks (that's what the ampersand notation does in the taskPrivileges array). Or you could have the apply task call your custom method by doing: $this->taskPrivileges['apply'] = '&customApplyAclMethod'; and then create a protected method customApplyAclMethod() which takes no arguments and returns an ACL definition (either an @-notation to have FOF look at a different taskPrivileges entry, a Boolean value to allow/forbid access or the name of a Joomla ACL privilege, either a core one like core.create or a custom one such as acme.rocket.launch).

Nicholas K. Dionysopoulos • Director and Lead Developer Akeeba Ltd  51 Metochiou Str., Flat 303, 1101 Nicosia, Cyprus  https://www.AkeebaBackup.com [https://www.akeebabackup.com/] On 7/1/2017 14:12:30, viryagroupdev notifications@github.com wrote: In our fof3 based component we have a custom account creation process which is now broken on the first step when using fof 3.0.17. Reverting to 3.0.15 will yield the desired behaviour The view displays fine index.php?option=com_weconnect_business&view=Registration&layout=self The form submission / "apply" task, which works fine in fof 3.0.15 and before, results in a 403 after upgrading to 3.0.16 or higher (3.0.17 ) Posts to

After rendering ... ... Any thoughts on what happened and how to correct — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [https://github.com/akeeba/fof/issues/643], or mute the thread [https://github.com/notifications/unsubscribe-auth/AAPoKdRweBobntoQcmWdW2vta_rtKo1yks5rP4D-gaJpZM4LdZ7_].
viryagroupdev commented 7 years ago

thanks nik for the time to explain, gonna digest that ;)