I am trying to use TinyMCE Editor on a Laravel project and it works perfectly fine on localhost, but when deployed to the server, Mod security blocks the form submission due to the HTML elements in the form fields. I have searched the web and found options that advised to disable Mod Security, but that leaves my server vulnerable, so I don't want to do that.
Please can someone help with a work around that would allow me to submit formatted text to my database without disabling Mod security on my server?
The text in the link below is a sample of the text I am trying to paste which throws a Mod security error:
[https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet.html][1]
The log currently gives:
[:error] [pid 982063] [client IP] [client IP] ModSecurity: Access denied with code 403 (phase 2). Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required. [file "/etc/modsecurity/modsecurity.conf"] [line "88"] [id "200004"] [msg "Multipart parser detected a possible unmatched boundary."] [hostname "domain.tld"] [uri "/admin/createblog"] [unique_id "ZON9Wu1tOJTfII0SM9EoYAAAAAs"], referer: https://domain.tld/admin/createblog
It's a Laravel project.
Any help would be greatly appreciated.
OWASP ModSecurity Core Rule Set Dev on Duty reporting. Thanks for adding the log output to your question: that will be essential to resolving your issue.
Here are the most interesting parts of your log excerpt:
ModSecurity: Access denied with code 403 (phase 2). Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required.… [id "200004"] [msg "Multipart parser detected a possible unmatched boundary."]… [uri "/admin/createblog"]
What can we tell from this? Firstly, there was an error with the multipart parser, which suggests that the offending HTTP transaction was an upload of some sort. The URI was /admin/createblog. That all aligns with what you mentioned about the problem occurring when trying to post some HTML (posting a blog post consisting of HTML, we can assume.)
We can also see that the specific rule that matched was rule 200004. This rule is responsible for checking the variable MULTIPART_UNMATCHED_BOUNDARY. That variable is set by ModSecurity when it “encounters what feels like a [multipart message] boundary but it is not.” [Source]
200004 is a really twitchy rule and is well known for causing many false positives (see here for an expert opinion on why it's safe to turn off this rule.) Legitimate text can easily cause rule 200004 to match if a line of text starts with some hyphens, which starts to look a bit like a multipart boundary. Consider some totally legitimate input like the following list:
Things I would not put on a pizza:
-- Pineapple
-- Bacon
-- Anchovies
That clearly isn't malicious content but it does cause rule 200004 to match (I just tested it to double-check).
To prevent future false positives of this type, disable rule 200004 by using a directive like the following:
# Disable 'ModSecurity recommended' rule 200004, "detected a possible unmatched
# boundary", as it's known to cause frequent false positives and isn't useful.
# (Reference: https://stackoverflow.com/questions/76908930)
SecRuleRemoveById 200004
Alternatively, if you know where rule 200004 is being defined (you'll probably find it in a file named something like modsecurity.conf-recommended) then you can comment it out so that it is never executed:
#SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" \
# "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
Then be sure to reload your web server service (Apache?) and you should be good to go.