#16940 closed defect (bug) (wontfix)
Prevent 403 errors in Press This
Reported by: | scribu | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.2 |
Component: | Press This | Keywords: | |
Focuses: | Cc: |
Description
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
Attachments (1)
Change History (16)
This ticket was mentioned in IRC in #wordpress-dev by aubreypwd. View the logs.
11 years ago
#3
@
11 years ago
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.
#4
in reply to:
↑ description
@
10 years ago
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.
#5
follow-up:
↓ 7
@
10 years ago
- Keywords has-patch removed
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.
#6
@
10 years ago
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.
#7
in reply to:
↑ 5
;
follow-up:
↓ 8
@
10 years ago
- Version set to 4.2.1
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.
#8
in reply to:
↑ 7
;
follow-up:
↓ 10
@
10 years ago
- Version changed from 4.2.1 to 4.2
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.
#10
in reply to:
↑ 8
@
10 years ago
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.
#11
@
10 years ago
- Keywords reporter-feedback removed
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.
#12
@
9 years ago
- Keywords close 2nd-opinion added
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?
#13
@
9 years ago
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.
#14
@
9 years ago
- Keywords close 2nd-opinion removed
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from new to closed
See comment:13.
#15
@
9 years ago
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.
Patch to fix issue with PressThis and mod_security