Closed gene1wood closed 2 weeks ago
@gene1wood Unfortunately the WordPress plugin only supports Vanilla WordPress, false positives that are due to a plugin must be resolved via a custom rule exclusion.
This is probably too broad as it disables all PHP injection protection from the post.php interface but it did enable me to make my page update
Yes your right, that rule exclusion is too broad, you can disable a rule for specific targets by using SecRuleUpdateTargetById
instead of disabling the rule completely. It should look something like this:
<locationmatch "/wp-admin/post.php">
SecRuleUpdateTargetById 933150 "!ARGS_NAMES:h2m_strip_tags"
</locationmatch>
Thanks @EsadCetiner . I had to move the SecRuleUpdateTargetById
directive outside of VirtualHost and outside of LocationMatch to get it to work as it sounds from this issue https://github.com/owasp-modsecurity/ModSecurity/issues/89 that in modesecurity 2.9.x it won't work in those blocks.
Anyhow, thanks for the pointer to the custom rule exclusion.
I'm unsure if this is the right place to report this. Any guidance is most welcome. I could imagine these paths
h2m_strip_tags
to something else that doesn't trigger the CRS rule (I reported it in https://github.com/terrylinooo/githuber-md/issues/382 )strip_tags
(not sure exactly how to do this as I'm new to CRS and modsecurity)The problem
The WP Githuber MD Wordpress plugin (which is developed in https://github.com/terrylinooo/githuber-md ) causes all posts to be blocked by modsecurity with CRS.
The plugin uses an argument called
h2m_strip_tags
which triggersand blocks posting pages or posts
A local workaround
This is probably too broad as it disables all PHP injection protection from the
post.php
interface but it did enable me to make my page updateLogs
error.log
modsecurity audit log