WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 5 years ago

Last modified 5 years ago

#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)

16940.diff (663 bytes) - added by jacobwg 10 years ago.
Patch to fix issue with PressThis and mod_security

Download all attachments as: .zip

Change History (16)

@jacobwg
10 years ago

Patch to fix issue with PressThis and mod_security

#1 @jacobwg
10 years ago

  • Cc jacobwg added
  • Keywords has-patch added; needs-patch removed

This ticket was mentioned in IRC in #wordpress-dev by aubreypwd. View the logs.


7 years ago

#3 @aubreypwd
7 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.

Last edited 7 years ago by aubreypwd (previous) (diff)

#4 in reply to: ↑ description @mark4pros
6 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: @kraftbj
6 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 @azaozz
6 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.

Last edited 6 years ago by azaozz (previous) (diff)

#7 in reply to: ↑ 5 ; follow-up: @dkruse
5 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: @kraftbj
5 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.

#9 @kraftbj
5 years ago

  • Keywords reporter-feedback added

#10 in reply to: ↑ 8 @dkruse
5 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 @kraftbj
5 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 would avoid the 403 error, 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.

Version 0, edited 5 years ago by kraftbj (next)

#12 @kraftbj
5 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 @dd32
5 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 @DrewAPicture
5 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 @CK MacLeod
5 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.

Note: See TracTickets for help on using tickets.