Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#36837 closed defect (bug) (invalid)

<script> tags in Admin Options page input field triggering mod_security

Reported by: maddogprod's profile maddogprod Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.5.2
Component: Administration Keywords:
Focuses: administration Cc:

Description

I have a site with a custom admin Options page. There are three fields and it's a simple form that submits to options.php. One of the inputs is to include Google AdWords Conversion code. For at least a year it's worked fine on 100+ mini-sites. With the latest updates to 4.5x we ran into a problem. When we submitted this options page we went to a 404 Error saying "options.php can not be found."

The site host found that it triggered mod_security beause it includes <script> tags. They disabled that mod_security rule and it works fine.

The problem is there are over 100 sites using this theme or variations that include this. Testing them, if I get rid of the <script> tags in that field it updates and works fine. Add the Conversion Code (or even one <script> tag) and it triggers mod_security with the same problem.

The site host swears the mod_security rules haven't changed in years. So it appears that one of the WP 4.5x updates probably affected it. I can't pinpoint which one since they were updated to 4.5.2 before the problem was discovered.

In searching I can't find any mention of this problem from other people but again, it worked for a year and suddenly doesn't on any of the sites.

Change History (2)

#1 @dd32
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Hey @maddogprod,

Unfortunately there really isn't anything we can do about this - and it certainly isn't something we should attempt to work around in WordPress.

mod_security rules are often trigger-happy, as they are in this case, and it sounds like it's probably being triggered by the presence of <script> in any data sent to the server.

Although the host says nothing has changed, very little has changed in WordPress as well - and definitely nothing of substance that would cause us to suddenly start triggering such a rule.

The only suggestion I can offer you, is to use a plugin/shortcode instead to add the tracking data, so that you aren't required to add the <script> tags in the input, and only have to specify a tracking ID.

#2 @maddogprod
9 years ago

Thanks. I'm wondering if while the site host hasn't updated the rules maybe they did update mod_security and that's why. I have an alternate way of handling this that should work easily but if it doesn't I'll go the plugin or shortcode route.

Thanks again.

Note: See TracTickets for help on using tickets.