Link to home
Start Free TrialLog in
Avatar of Lance McGrew
Lance McGrewFlag for United States of America

asked on

403 FORBIDDEN ON WORDPRESS SITE

Is mixed content causing 403 Forbidden You don't have permission to access /weekly-rides/ on this server?   Our club recently installed an SSL Cert on their website.  Searching Google for Prairie Cycle Club now shows links that end up as for example:  "Forbidden You don't have permission to access /weekly-rides/ on this server."  When the URL is typed in directly, the page will display.  Other than needing to fix image URL's to avoid mixed content, what else can cause this 403 error?  Potentially the .htaccess needing an edit or rebuild?  This is a wordpress site and I'm not the admin, just a club member with an EE account.  Other clues, seems like maybe a redirect needs to be added to the .htaccess since www.prairiecycleclub.org yields Not Secure whereas https://www.prairiecycleclub.org yields "circle w/i" to indicate mixed content.   They said this started a couple weeks ago.  I noticed the cert date is May 1, 2019.
Avatar of David Favor
David Favor
Flag of United States of America image

Sounds like there are many problems.

Let's clear up one problem in this question only, then open other questions to resolve additional problems.

We'll take care of the 403 Forbidden error, as this question's title relates to this specific problem.

Both main site + /weekly-rides/ both return a 200 success, so there's no 403 Forbidden error returned.

imac> curl -I -L https://www.prairiecycleclub.org
HTTP/1.1 200 OK
Date: Sun, 19 May 2019 16:54:17 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Server: Apache/2
X-Powered-By: PHP/7.1.1
X-Pingback: https://www.prairiecycleclub.org/xmlrpc.php
Link: <https://www.prairiecycleclub.org/wp-json/>; rel="https://api.w.org/"
Link: <https://www.prairiecycleclub.org/>; rel=shortlink
Age: 0

imac> curl -I -L https://www.prairiecycleclub.org/weekly-rides/
HTTP/1.1 200 OK
Date: Sun, 19 May 2019 16:54:30 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Server: Apache/2
X-Powered-By: PHP/7.1.1
Link: <https://www.prairiecycleclub.org/wp-json/>; rel="https://api.w.org/"
Link: <https://www.prairiecycleclub.org/?p=142>; rel=shortlink
Age: 1

Open in new window


Might be you're typing in some other URL. If this is the case publish the exact/full/clickable URL returning the 403 Forbidden error.
Your cert validity...

Valid from	Wed, 01 May 2019 19:28:27 UTC
Valid until	Tue, 30 Jul 2019 19:28:27 UTC (expires in 2 months and 11 days)

Open in new window


So your cert's good for now.
Aside: If you're sending any traffic from your site to a Payment site - PayPal, Stripe, etc - be sure to disable TLSv1.0 + TLSv1.1 protocol support, as having these enabled will cause any payments to be blocked... with very odd messages + a lot of software won't have a clue how to recover or report this type of error.
Avatar of Lance McGrew

ASKER

David, what results do you see when using Chrome browser with Google Search?  Type in Prairie Cycle Club

For me, the links I click on from search results will either display a blank page or the 403 Forbidden message.
-ScreenCapture--2019-05-19-at-12.05..png
-ScreenCapture--2019-05-19-at-12.05..png
Images are far less useful than cut + paste text, which can be clicked or copied.
1) ScreenCapture--2019-05-19-at-12.05..png - shows no 403.

2) ScreenCapture--2019-05-19-at-12.05..png - references an /about/ link.

No problem with the /about/ link either.

imac> curl -I -L https://www.prairiecycleclub.org/about/
HTTP/1.1 200 OK
Date: Sun, 19 May 2019 17:17:04 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Server: Apache/2
X-Powered-By: PHP/7.1.1
Link: <https://www.prairiecycleclub.org/wp-json/>; rel="https://api.w.org/"
Link: <https://www.prairiecycleclub.org/?p=138>; rel=shortlink
Age: 5

Open in new window


/about/ works fine with curl + all browsers I tested.

Both HTTP + HTTPS seem to be working.
if you change from https: to http: you don't get the 403 forbidden.
David Johnson, so did you see the 403 forbidden?  I too can simply edit the URL from https to http and things work.  So the links Google Search return are https:, so why would simply changing to http: work?   Why do we only have issues when clicking on search result links and not when we type in the URL?
David Favor, the point is, we only seem to have issues when clicking on search result links.  Typing in the URL in a browser or using various terminal utilities do not yield the same results as searching phrase:  prairie cycle club then click on any of the results produce either a 403 message or simply a blank webpage.

That was my reason for posting screen captures in attempt to clarify.
the search results don't have the www and there is a 301 redirect to www.
David Johnson, please see attached.  Search results are displayed as https://www from what I am seeing.
-ScreenCapture--2019-05-19-at-1.24.0.png
Best if you cut + paste the exact clickable link.

I still see no 403 for any link I've clicked.

Inputting prairiecycleclub.org in browser bar returns 200 + content, no 403 Forbidden.
The link https://twitter.com/PrairieCycle returns a 403 + this is a Twitter link, so you have no control over this.

All other links return 200 + content... on every single clickable link in the search you provided...

I do notice sometimes your site returns a 200 + no content. This is a hosting problem.

You'll open a support ticket with The Endurance International Group, Inc. (which appears to be your hosting company) to resolve this problem.
1) Ah I see what appears to be the problem

You site is getting hit by an Index Attack, where someone populates pages on their site, with malformed links on your site, for the purpose of taking down your site.

Google + Bing + many other Crawlers (all dumb as a bag of hammers) stupidly index every link they find in the wild pointing to your site, instead of limiting indexing to links found in sitemap.xml links or links found by actually crawling your site.

Note: Many sites are getting hit with this type of attack traffic, so it's a good bet very shortly Google + Bing + other Crawlers will stop indexing Index Attack links like this in the near future.

2) Notice the link https://www.prairiecycleclub.org/weekly-rides/&usg=AOvVaw1dCADm9iMDjvwNBqj2aAS7 is malformed.

The "/&usg=..." is malformed, which will return either a 403 or 404, depending on your Webserver config.

The correct form should be /?usg=... or ?usg=... (no trailing slash).

3) What's curious is how you're able to get to this URL at all, because searching for - site:www.prairiecycleclub.org "usg=" - returns 0 results for me... unless an attack site has special code which generates these links specifically when Crawlers visit their site. This would result in no record of these links being anywhere online. This is likely what's occurring.

Attach a short video showing your exact search sequence + the exact link you click on. Be sure to move slow enough to see clearly your exact process.

This might give a clue about how you've hit this problem.

4) Note: It's to a point now where Index Attacks which were non-existent a few months ago are so common + egregious now, I've had to craft a set of Apache config rules, unique for each site I manage, to block specific Index Attacks for each site.

This is very ugly as it involves blocking all Crawlers attempting to index the site.

This results in sites dropping out of all indexes, till search companies change their policy of indexing links in the wild pointing to a site as actual site links.

You'll only have to take this step when Crawlers attempt indexing 1,000,000s of these links + your site starts going down.
David Favor, here is a link to the video I created.    https://vimeo.com/337185311
Update May 25, 2019

  • All page references on Google Search using site:prairiecycleclub.org still result 403 Forbidden error.
  • Only PDF's and Image references display on Bing.com and Yahoo.com
  • Google Search Validation reports Soft 404. https://bit.ly/2X6DEiA
  • StartLogic.com hosting.  After multiple chat sessions, support ticket has been escalated to level 2 tech group.
  • Appears all referral links reported by DuckDuckGo.com are working fine
I've attached a video showing some additional detail.

Looks like several possibilities.

1) You have an actual directory inside your WordPress install directory (DocumentRoot) called weekly-rides. If you do, you must delete this directory.

2) Look at your .htaccess file + Apache config for this site + ensure correct config, so nothing funny being done, like adding or stripping query parameters.

3) Next look at your Apache logs for difference between arriving request from Google + from browser bar.

4) If you're running FPM for PHP, also refer to your FPM logs.

No way to guess about this, without looking at entire log set, during live visits from Google search page + from browser bar.
2019-05-25-ee-site-review.mp4
Oh I wonder...

If you have any plugins doing any type of bot blocking, like reCAPTCHA v3, disable all these plugins + retest also.

This should be a factor + might be.
David Favor - thank you for your continued responses.  

Try using DuckDuckGo.com as the search engine and type in site:prairiecycleclub.org   The first page of search results are all PDF references, but click on More Results and you'll find additional referral links that work fine without any 403 errors.
ASKER CERTIFIED SOLUTION
Avatar of Lance McGrew
Lance McGrew
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Glad you found a solution!
Yes, finding the apparent solution is gratifying.  And as always, we appreciate the dedication and contributions from all the EE contributors who volunteer and share their skill sets.
05/26/19 Mitigation Notes

Wordfence was used to scan our website and identify the likely infected Blogsonry child-theme functions.php file.  Attached is a redacted screen-shot of the malware found embedded in the original functions.php.  The code was engineered to affect Googlebot, bingbot, yahoo, msnbot, and aol.  This would explain why we did not experience 403 errors when using DuckDuckGo.  Our speculation is, the attack vector was a server-side injection.  This would further confirm the need to properly sanitize user-form entry keystrokes.
exploit.png
Be great if you could attach an actual copy of the infected file, for people to archive + analyze.

This looks to be an interesting hack.

Some of us actually analyze files like this to develop countermeasures + also determine if there's a way to counter attack the source of hackers.
Posting the infected file seems like an unwise move?  I understand the potential benefits you point out however posting would also further educate nefarious individuals stumbling onto this thread.  Seems now, simply having a malware detection plugin such as Wordfence is the best countermeasure.
Best counter measure is to always ensure you're never hacked.

WordFence only tells you a hack has occurred.

WordFence does nothing to close the exploit vector (how hacker injected hack).

Note: If you're hacked once + don't change anything, you will be hacked again.

Best to review all your security polices + close the vector/backdoor.
Read through EE Threads about how to secure WordPress sites.

You can also search for other threads like WordPress or WordPress Security or LAMP Security.