jquery.cookie.js incompatible with Apache mod_security by default

If renaming to cookie.js would solve the issue then...

one option, I already considered was to create a new sub-directory for external jQuery libraries shipped with core in /misc, i.e. /misc/jquery/cookie.js

However, given that jquery.cookie.js, compared to jquery.cookies.js, is a bit lightweight (in terms of features), it may also be possible that we'll do what most often do: Enhance and adapt libraries to our own needs. So, it's possible that we could just rename it to /misc/cookie.js.

I'm not sure we want to support brain-dead "security" tools. Do we have more information about why this particular naming triggers a mod_security rules, and could we file a bug against mod_security?

The offending rule is:

SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES "(?:\b(?:(?:type\b\W*?\b(?:text\b\W*?\b(?:j(?:ava)?|ecma|vb)|application\b\W*?\bx-(?:java|vb))script|c(?:opyparentfolder|reatetextrange)|get(?:special|parent)folder|iframe\b.{0,100}?\bsrc)\b|on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|down|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell|http)|ivescript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|background-image|mocha):|s(?:(?:tyle\b\W*=.*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|shell|http):)|a(?:ctivexobject\b|lert\b\W*?\(|sfunction:))|<(?:(?:body\b.*?\b(?:backgroun|onloa)d|input\b.*?\btype\b\W*?\bimage)\b| ?(?:(?:script|meta)\b|iframe)|!\[cdata\[)|(?:\.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|innerhtml)|\@import)\b)"

Which... makes no sense at all. I hope this regexp is compiled automatically from something else. If it's not, I call mod_security a #fail.

I've spent a while looking for known exploits why this rule is in place.
if there's anything, I couldn't find it

I'm on a shared host server, I don't have the authority to tell the hosting company to update anything unless they're already good and ready... changing hosting companies is more likely, painful but sure.

There are quite a number of hosts running mod_security where the users don't have control. jquery.cookie.js being blocked could be a non-starter for them using Drupal. And, because Drupal would be broken on their sites they would look at Drupal as being broken providing for a bad reputation.

The problem is with the name cookie in the filename, if I read the rule right. What if we just renamed jquery.cookie.js to jquery.c.js. Since the library API handles the files we would just need to change the file name the and path in system_library().

I'm all for working around bugs in PHP, Apache and the OS, but I draw the line at working around some silly (and generally useless) WAF that is deliberately breaking the web with catch-all nonsense rules.

What if mod_security's next update labels "query" as a forbidden word? Should we start using random filenames (c034f05d.js)?

I agree. If at all, the Drupal community could rather come up with a custom, working modSecurity rule-set. The defaults as well as sets found on the net are rather sloppy and break a lot, by design.

I had a very successful time of requesting a correction of the CRS rule set for ModSecurity in their issue tracker: https://www.modsecurity.org/tracker/browse/CORERULES-30

For clarity sake, this isn't ModSecurity really. It's a specific rule set that is causing this. It is the most popular by virtue of it being hosted on the main ModSecurity list among other things I expect.

When you submit the request, provide a full audit log entry around the event (scrub the personal stuff out) and explain whey they are wrong. They have been fine with me on this. I have not run into this particular issue so can't be of much help in that regard. If you post the audit log entry here, I'll take care of representing Drupal at ModSecurity for this since I already have an account and some minor reputation.

Ah, apparently I'm feeling impatient. I went ahead and created the issue at ModSecurity. If someone can get the audit log entry, I'll be glad to append that.

https://www.modsecurity.org/tracker/browse/CORERULES-31

@Damien, the ModSecurity folks want to know "What version of CRS is being used?" Do you have that information?

Just noticed this in my install, which is CRS version 2.0.5

And here's the audit log attached.

Note to Damien: you may be able to work around this if your host lets you *add* additional mod_security rules.

subscribing

Sorry for leaving this for so long.

I just dug in a bit. My original bug was marked a duplicate of another that is now resolved. The resolution of that rule problem came in CRS 2.0.8. You can see details in the following. https://www.modsecurity.org/tracker/browse/CORERULES-29

I'm going to mark this fixed since it is now good as long as you update the core rules.

I am facing the same problem . What should I do? I still dont know the solution. Should I rename the file jquery.cookie.js ?

@www.phodphad.com and everyone else with mod_security problems:

If you maintain the server, update the mod_security rule set and/or seek support http://modsecurity.org/ .

If you do not maintain the server, bug the person/company that does.

I'm having the same problem, My hosting admin had to block the rule to stop blacklisting my IP.

Is there any workorund for this?

The workaround is to remove the rule.

The fix is to update the rules to the ones that were fixed (see above).

You can remove the rule based on certain parameters. My host has done this for me. I can give him paths that should be allowed for certain activity for example or sometimes he'll just do it for my entire domain. That makes the workaround a bit more palatable until the rule set gets updated and the host updates (hopefully your host is as flexible).

How do I update the mod_security rules?

Does anyone have the rule id which I can just ignore per domain?

Drupal is a bad place to look for that info. I think the ModSecurity community would be more helpful. You can find their user mailing list at http://www.modsecurity.org/contact/ and the documentation on it at http://www.modsecurity.org/documentation/.

If fighting with your host is a pain in the ass (mine insisted mod_security was not at fault, then told me hours later they had fixed the problem! -- by renaming the file…), you can throw this in your site's .htaccess file as a workaround:
Redirect 302 /misc/jquery.cookie.js /misc/jquery-cookie.js
Of course, you'll need to rename (or copy) your jquery.cookie.js to jquery-cookie.js.

Hope this helps someone!

A neat fix was pointed out to me; aggregate your js files in "performance". Meanwhile, I've written to Greengeeks (my host) pointing out thsi thread to them as evidence of the incompatibility between D7 and Apache Mod_security.

Can anyone tell me what fix worked for you? I am having the same issue and can't even post a single page on my drupal website! The hosting guys are not ready to disable mod_security or change any rule.

Can any one tell me in which files do i need to change the filename of jquery.cookie.js

rubydubee

the jquery.cookie.js file is located in core /misc/jquery.cookie.js....

Not sure if this helps, did this work-around work at all for you. We have ended up at this issue from an ajax and break with ckeditor after files are uploaded.

has anyone tried the .htaccess ?

DrupalUP Nasty 4sure;)

The best solution is to modify the ModSecurity rules. Strictly speaking, the incompatibility isn't with ModSecurity, but rather with one of the rules in the set being used and those can be modified.

@lesseen: actually, an .htaccess workaround is proposed in #25

The .htaccess workaround is proposed in #25 worked for me.

tried the suggestion in #25 but it doesn't work for me. it didn't make any changes. any help? thanks ahead! ^^

#26 worked for me. :)

This issue has been locked.

Should you need mod_security configuration support, contact your host or the mod_security developers.

Sometimes when the JS aggregation does not include some js files e.g. using a custom jquery version inside your theme or JQery update, and if you have a root access to your sever you can add the following lines to the modesec2.conf:

SecRuleEngine Off

the PATHE_TO_YOUR_FILE might looks like

this will disable the detection of that specific path for all your virtual hosts if you have any.

I hope that helps in this specific situation.

Sometimes when the JS aggregation does not include some js files e.g. using a custom jquery version inside your theme or JQery update, and if you have a root access to your sever you can add the following lines to the modesec2.conf:

<Location Match PATHE_TO_YOUR_FILE>
  <IfModule mod_security2.c>
    SecRuleEngine Off
  </IfModule>
</LocationMatch>

the PATHE_TO_YOUR_FILE might looks like <LocationMatch /sites/all/modules/jquery_update/replace/ui/external/jquery.cookie.js>

this will disable the detection of that specific path for all your virtual hosts if you have any.

I hope that helps in this specific situation