Closed caswal closed 2 years ago
Hi @caswal, thank you for your report.
(I've edited your comment: I've put the logs between ``` characters)
Unfortunately, a false positive like this can sometimes occur, even if the paranoia level is lower - this rule is activated in PL1.
I've made a quick research about possible solutions in case of Dreamhost, but unfortunately I didn't find any method how can you make an exclusion - looks like you can't access the rules, and using of .htaccess
is also disabled. I'm afraid the only thing is you can do that contact the support, and notice them about this issue, and/or ask an exclusion, like this:
SecRule REQUEST_URI "@beginsWith /api.php" \
"id:10001,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=932115"
Please let us know if we can help anything.
Let me add that the subsequent alerts were not due to rule violations, but due to PCRE match limit hits. That means the PCRE Match limits are overly low (a frequent problem we see when people leave the default settings or do not raise it enough) or your wiki payload is very large.
Thanks for the support guys, is appreciated. It looks like this issue is pretty common: https://www.mediawiki.org/wiki/Topic:Vv23nm75ef2cyxtn
Various topics about it, and so far no mention that it could be that ModSecurity rules are catching it. At least I have made a comment letting people know a possible solution.
@dune73 from my googling, I did learn that the PCRE Match limit was a rate-limiting error, and noticed it came from editing large wiki pages.
Not sure if asking for an exclusion like that really works. It will end up being a game of whack-a-mole, checking over the logs, other pages have also triggered 921130, 921110, 932100, 932105, 932110, 932130, 932140, 942190, 942240.
This won't make for a good user experience, when a user edits a wiki page, attempts to save it and gets an HTTP 500 Error, triggering a rule that hasn't been excluded.
Dreamhost has the ability to turn off ModSecurity, so I have opted for this as a solution, and rely on that MediaWiki is robust, and Dreamhost keeps the shared hosting fully up to date.
Hi @caswal,
thanks for feedback - if you need any help, please let us know.
If you think we can't help anymore in this problem, please close this issue.
@caswal: Securing a free form text entry application, namely a wiki, is a whack-a-mole. We have rule exclusion packages for other software, including dokuwiki, but it takes a certain effort. It's an effort we can not do on ourselves, it takes support from the community behind said software. So if the Media Wiki crowd wants to be able to run CRS seamlessly, then we would be more than happy to cooperate and come up with a rule exclusion package.
Until then, I think disabling ModSec is a pragmatic step given your situation.
This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days
Description
MediaWiki's Visual Editor is causing false positives. Especially when editing pages with tables, parenthesis etc. This has occurred to me on Dreamhost's Shared Hosting, so I'm not sure how much log/info I can pull due to my limited ssh account rights.
Audit Logs / Triggered Rule Numbers
Your Environment
I can't seemingly make calls to apache2, httpd, apachectl etc. No sudo rights, so can't go poking around in /var/ etc
Confirmation
[ ] I have removed any personal data (email addresses, IP addresses, passwords, domain names) from any logs posted.