Prevent 403 errors in Press This

[scribu]

The problem:

Some hosts have lame mod_security rules that block unencoded urls, making Press This unusable.

Source: ​http://forums.hostgator.com/apache-upgrade-broke-feature-wordpress-t40603.html

The fix:

Replace:

u='+e(l.href)+'

With:

u='+e(l.href.replace(/\//g,'\\/'))+'

Source: ​http://wordpress.org/support/topic/press-this-results-in-404?replies=22#post-1008326

[jacobwg]

Patch to fix issue with PressThis and mod_security

[aubreypwd]

After discovering that applying this patch *seems* to do nothing other than replacing / with \/ which gets you /, I landed on ​http://stackoverflow.com/questions/14215419/mod-security-exception-rule-for-url-as-parameter that seems to show that passing a url via a parameter is not fun for mod_security

When I looked at what's happening in the patch ( ​http://jsfiddle.net/4s4Xb/4/ ) it appears that what actually get's sent to the parameter is \/, an escaped /. This causes, I think, the parameter to not be a URL, but be something like a URL.

So what we end up passing from JS to the URL is ?u=http:\/\/fiddle.jshell.net\/_display\/ or ?u=http%3A%2F%2Ffiddle.jshell.net%2F_display%2F which works when press-this.php processes it, see ​https://cloudup.com/cqDbBglTWO4

I did some Googling ​https://www.google.com/search?btnI=&q=press+this+404+error#q=press+this+404+wordpress&tbs=qdr:y and this has come up recently in some blogs, etc, so it might still be an issue with some people.

[mark4pros]

Replying to scribu:

Press this returns a 403 error.

The fix you recommended works perfectly, ty for saving me hours of frustration.

I just wanted to add one little note. The changes are done to the "Press This" short-cut on the local browser. ie: if you use Firefox then right click Pressthis button on the favourites bar and select properties, Copy and past the entire line into a new notepad document as a scratch pad. Now replace the string mentioned in this post and update the properties of the "Press This Button" save and close.

[kraftbj]

With 4.2 PT, Hostgator is throwing a 403 also when directly using wp-admin/press-this.php. I reached out to Hostgator asking for more information on what rule is being applied and determine if this is an area Core can improve or if HG needs to improve their rule, etc.

Since it occurs with direct input, the patch to change the bookmarklet shouldn't be applied, IMO.

[azaozz]

Not sure if this is the best solution. A better/more robust option is to strip the http:// part and add it back in PHP? To do that will need to pass another query arg indicating whether it is https or not.

[dkruse]

Replying to kraftbj:

With 4.2 PT, Hostgator is throwing a 403 also when directly using wp-admin/press-this.php. I reached out to Hostgator asking for more information on what rule is being applied and determine if this is an area Core can improve or if HG needs to improve their rule, etc.

Since it occurs with direct input, the patch to change the bookmarklet shouldn't be applied, IMO.

had the same 403 problem with 4.2 PT and it was resolved by my host changing a ModSecurity rule.

He said it was rule 211120, but can't find that rule in the docs anywhere.

[kraftbj]

Replying to dkruse:

He said it was rule 211120, but can't find that rule in the docs anywhere.

Could you ask them for additional information on what rule 211120 pertains to? I'm not seeing anything related to it via Google or Bing, nor searching their open-sourced (free) rule set: ​https://github.com/SpiderLabs/owasp-modsecurity-crs/search?utf8=%E2%9C%93&q=211120

My first thought is the rule number is an internal identifier for a custom rule.

[dkruse]

Replying to kraftbj:

Replying to dkruse:

He said it was rule 211120, but can't find that rule in the docs anywhere.

Could you ask them for additional information on what rule 211120 pertains to? I'm not seeing anything related to it via Google or Bing, nor searching their open-sourced (free) rule set: ​https://github.com/SpiderLabs/owasp-modsecurity-crs/search?utf8=%E2%9C%93&q=211120

My first thought is the rule number is an internal identifier for a custom rule.

More detail - I'm told that rule 211120 is the identifier for the rules from Comodo's WAF: ​https://waf.comodo.com/

Seems you need to subscribe to get the documentation.

[kraftbj]

FYI - Once you sign up (free), the rules are licensed under the Apache license.

The rule that is impacting Press This:

SecRule ARGS "^(?i)(?:ft|htt)ps?(.*?)\?+$" \
	"id:211120,msg:'COMODO WAF: Remote File Inclusion Attack',phase:2,severity:2,capture,block,setvar:'tx.points=+%{tx.points_limit4}',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',ctl:'auditLogParts=+E',t:'none'"

Since the bookmarklet and the direct entry form passes a complete URL, including protocol, as the u value, it is including http/https in the URL, which is triggering this rule.

Testing a direct URL, changing the u to remove http does avoid the 403 error on HostGator, but break the feature of PT since _limit_url returns '' if ! preg_match( '/^([!#$&-;=?-\[\]_a-z~]|%[0-9a-fA-F]{2})+$/' (ref).

I'm thinking of if there is ways around this that suitably work; open to suggestions.

[kraftbj]

Unless anyone else has suggestions, I'm leaning toward closing this as wontfix. PT has valid reasons for wanting to be semi-strict on whether or not the passed item is an URL (since we're make an outbound request to fetch it). Hosting providers are free to disable this rule, or modify it to allow it to work with WP installs.

Any other thoughts?

[dd32]

I'm leaning highly towards invalid/wontfix myself. If any users experience this, they should report it to their host to get the overzealous rules disabled or modified.

[DrewAPicture]

See comment:13.

[CK MacLeod]

Just thought I'd note that the fix specifying rule 211120 did not work for me. In order to enable Press This on a Hostgator site, I had to have mod_security rule 1234234 whitelisted. If I receive a fuller explanation from Hostgator as to the specific purpose of rule 1234234, I'll add it here.