Form php plugin 'forbidden' (403)

[wezetel]

I have created two forms, which should use the php-plugin. This did work fine, but suddenly (I didn't do anything or should I say I did so much I can't remember?) I'm not able to edit the form settings in backend and get an 403 error, as soon as I want to close the form.
As soon as I removed the php-plugin from one form (form: Nachricht), the error disappeared. The other form (?berweisung) still has the php plugin. It's possible to see all details and settings, but even a simple 'close' w/o any changes results in an access error.
Admin credentials are available in 'my sites' list and activated.

 

[wezetel]

Just to check the error and be sure nothing else has an influence, I installed Fabrik on a new (empty) site (wezetel.de). Same error with the testform: as soon as I want to add the php-form plugin I get a no-access error.
Superadmin credentials are listed under 'my sites'.

 

[cheesegrits]

403's are usually down to things like mod_security on the server. Talk to your host support, see if there's any clues in the access logs, and whether you need to whitest or tweak a specific security rule.

Sent from my HTC6545LVW using Tapatalk

 

[wezetel]

Thanks for the tip. Checked the error log and part of the thrown error msg is:
ModSecurity: [msg "COMODO WAF: PHP Injection Attack: High-Risk PHP Function Name Found||wezetel.de|F|2"] [data "Matched Data: require_once found within ARGS_NAMES:jform[params][form_php_require_once][0]: jform[params][form_php_require_once][0]"] [severity "CRITICAL"] Access denied with code 403 (phase 2).

 

[wezetel]

Some deeper investigation showed, that the firewall rule is triggered by the parameter 'form_php_require_once'. As I don't can or want to change firewall rules and the parameter is just a name I made two modifications to the php plugin:

1. Renamed in fields.xml the field name to 'form_php_requireonce'
2. Changed in php.php line 498 to: $require_once = $params->get('form_php_requireonce', '0') == '1';

In fact I just needed to remove two underscores and now the problem is gone!

Would be good, if this changes could be done in the official fabrik code, so other users don't need to touch the source code, if they face this security issue.

 

[wezetel]

Thought again about changing the paramater name in fabrik code. This may cause problems for php-plugins in existing forms as the parameter name is saved in the database.
But if more host providers apply the security rule new applications may get problems.
The only solution would be to check in php.php which name is used in parameter settings (for backward compability).

 

[cheesegrits]

Hmmm, this is irritating, for some reason Tapatalk isn't posting my responses on this thread. It works on all others, but I've responded twice through tapatalk on my phone here, and neither one posted. What I was trying to say was ...

I'm usually very reluctant to change param names (as in, won't do it) because (as you noticed), it breaks backward compat, and there is no way to "check which name is used". Or rather, we can continue to use the original setting when running the plugin, by defaulting the new param value to the old one when we fetch the value ... $params->get('newname', $params->get('oldname')) ... but as soon as they edit and save the form settings on the backend, 'oldname' gets lost, and 'newname' is written out to the forms metadata table with the default value from the XML (unless of course they happen to notice the change in setting and correct it). All of the plugin setting form display on the backend is being handled by the Joomla JForm API, we just provide XMl files (well, and element types, but that doesn't help). So there's no way for us to somehow dynamically change the value of the new param name in the XML to the old one.

I'm especially reluctant when the problem is aggressive Comodo mod_security rules, that don't use a regex to constrain the string they are looking for with word breaks. There's really no reason form_php_require_once should trigger anything. The rule should match /\brequire_once\b/, not /require_once/.

In this case I might consider changing the param name, as I doubt there's more than a tiny handful of people who use it. However, as a first step, I would suggest using feedback to Comodo (I think there's a 'feedback' button in their CPanel widget) to report the false positive, and suggest they add word breaks to that rule.

-- hugh

 

[wezetel]

I fully agree to your point of view, especially as the problem seems to be a recent change in the rules. I haven't had the problem in the past.
My host provider is using Plex and so I need to check which is the best way to report this false positive.