ModSecurity causing headaches on WordPress Blogs

  • Kojichan

    (@kojichan)


    11 years, 8 months ago

    Just to note, I selected Version 3.4.1 as this is the latest, and the last version I checked this problem to occur on. This has happened to me as far back as the earliest release of WordPress 3.0, and it’s been frustrating me for years.

    I’m running a few blogs on WordPress through my server. I am with MidPhase but this may occur on other hosts who use ModSecurity (mod_security) as a way to prevent malicious SQL injections.

    Whenever I submit ANYTHING through the dashboard (New/Edit Post/Page, New/Edit Media description/titles), and the text boxes contain accented characters (or sometimes even a single one), ModSecurity comes along and bashes WordPress over the back of the head causing an Error 404 to be generated.

    Here is a sentence I’ve verified to fail on WordPress 3.0+ on hosts running ModSecurity, when placed into the Body of a Post/Page. If you’re curious, try it out yourself.

    offrir à nos clients satisfaction et pleines écoute

    Take note to the à and é in that sentence. If you remove those characters the post/page will publish fine. But with those characters, WordPress bails.

    I’ve verified with my web host that the ModSecurity rule that is broken is #390620, but he won’t tell me much else is wrong beyond “Mod Security typically blocks updates like this as a precaution because hackers can use them to inject harmful data into databases or other files”.

    All I know is it’s a MySQL Update that is triggering it. It seems to be how WordPress handles UTF-8 encoded form submissions. Closest I could find is this config file:
    http://www.pfsense.com/packages/config/apache_mod_security/rules/10_asl_rules.conf

    which states that the specified error is a ‘Totally bogus request’.

    #totally bogus request
    #SecRule REQUEST_LINE “!^(?:(?:[a-z]{3,10}\s+(?:\w{3,7}?://[\w\-\./]*(?::\d+)?)?/[^?#]*(?:\?[^#\s]*)?(?:#[\S]*)?|connect (?:\d{1,3}\.){3}\d{1,3}\.?(?::\d+)?|options \*)\s+[\w\./]+|get /[^?#]*(?:\?[^#\s]*)?(?:#[\S]*)?)$” \
    # “t:none,t:lowercase,phase:2,msg:’Atomicorp.com – FREE/UNSUPPORTED RULES – WAF Rules: Bogus HTTP Request Line’,id:’390620′,rev:1,severity:’2′”

    Now this problem has been “fixed” on my site, as they added an exception to this rule for me so I could continue to run French WordPress installs, so I’m not sure what to say.

    I hope this can someday be fixed, not sure who’s responsible. All I know, is that not every hosting place is going to be nice enough to allow exceptions to ModSecurity’s rules.

Viewing 1 replies (of 1 total)
  • oeconomist

    (@oeconomist)

    10 years, 11 months ago

    What WordPress often does is to replace an HTML escape sequences with the corresponding character, when what it ought to do is always to replace various characters (should the user enter them in bare form) with escape sequences. For example, your string should become

    offrir à nos clients satisfaction et pleines écoute

    But, while MidPhase’s behaviour could be worse, it ought to be better. MidPhase encourages customers to believe that MidPhase supports WordPress, but MidPhase keep hitting hosted ‘blogs with mod_security attacks. (Yes “attack” is the proper word.) Whenever MidPhase has effected a change that could produce these attacks, MidPhase should be checking the logs to see what is triggering mod_security to act, and MidPhase should be effecting exceptions quickly. Likewise for any other hosting service that purports to support WordPress.

Viewing 1 replies (of 1 total)
  • The topic ‘ModSecurity causing headaches on WordPress Blogs’ is closed to new replies.