Pāriet uz saturu

WordPress kodola faili, atverot tos tieši, ģenerē kļūdas

Brīdinājums Viss domēns Drošība

Vispārīgas instrukcijas. Atveriet šo rakstu no sava PageCheck pārskata, lai redzētu to aizpildītu ar Jūsu vietnes adresi un noteikumiem tās tīmekļa serverim.

Kas tas ir

Daži WordPress kodola faili, piemēram, wp-settings.php un faili mapē wp-includes/, ir paredzēti, lai tos ielādētu tikai pats WordPress. Atverot tos tieši pārlūkā, tie izpildās un apstājas ar PHP kļūdu.

Kas ir nepareizi

Ikreiz, kad kāds no šiem kodola failiem tiek atvērts, tas ģenerē kļūdu. Ja kļūdu rādīšana ir ieslēgta, kļūda parādās arī lapā ar pilnu vietnes mapes ceļu serverī, un tas uzbrucējiem atklāj, kā serveris ir iekārtots.

Kāpēc tas jālabo: ikviens – boti vai kāds ar ļauniem nolūkiem – var atvērt šos failus atkal un atkal. Katrs pieprasījums palaiž PHP un ieraksta servera žurnālā vēl vienu kļūdu, tāpēc žurnālus var apzināti piepūst: tie aizpilda disku un aprok svarīgās kļūdas. Katra atbilde turklāt apstiprina, ka vietne darbojas ar WordPress.

Kā labot

1. Paslēpiet PHP kļūdas darbojošajā vietnē. Kļūdām jānonāk privātā žurnālā, nekad lapā. Hostinga vadības panelī iestatiet display_errors uz Off:

  • Plesk: Websites & Domains → PHP Settings → display_errors izslēgts.
  • cPanel: MultiPHP INI Editor → display_errors Disabled.

Failā wp-config.php atstājiet atkļūdošanu ieslēgtu, bet sūtiet katru kļūdu tikai uz žurnāla failu ārpus vietnes publiskās mapes, lai nekas nenonāktu lapā un neviens nevarētu žurnālu lejupielādēt:

wp-config.php

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/path/outside/the/web/root/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

Šīs rindiņas neattiecas uz failiem, ko atver šī pārbaude: atverot tos tieši, tie apstājas, pirms WordPress nolasa wp-config.php, tāpēc to kļūdas paslēpj augstāk minētais hostinga iestatījums. Rotējiet žurnālu (piemēram, katru dienu, glabājot dažas nedēļas): ar ieslēgtu atkļūdošanu tas vāc arī paziņojumus un var ātri augt.

2. Aizveriet WordPress kodola failus tiešiem pieprasījumiem. Izmantojiet noteikumus savam tīmekļa serverim (hostings var pateikt, kurš tas ir):

Apache vai LiteSpeed: vietnes galvenās mapes failā .htaccess, virs rindiņas “# BEGIN WordPress”

# BEGIN Block WordPress internal files
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/(?!ms-files\.php$)[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
<Files "wp-settings.php">
    Require all denied
</Files>
# END Block WordPress internal files

nginx: vietnes server blokā, virs bloka, kas apstrādā .php failus

location ~* ^/wp-admin/includes/ { deny all; }
location ~* ^/wp-includes/(?!ms-files\.php$)[^/]+\.php$ { deny all; }
location ~* ^/wp-includes/js/tinymce/langs/.+\.php$ { deny all; }
location ~* ^/wp-includes/theme-compat/ { deny all; }
location = /wp-settings.php { deny all; }

Tie ir noteikumi no WordPress.org drošības pastiprināšanas ceļveža ar vienu izmaiņu: tie atstāj atvērtu wp-includes/ms-files.php. WordPress Multisite tīkli, kas izveidoti pirms WordPress 3.5, augšupielādētos failus pasniedz tieši caur šo vienu failu, un ceļveža ieteikums Multisite gadījumā – izlaist visu rindiņu par wp-includes/*.php – atkal atvērtu visus pārējos failus šajā mapē. Atsevišķā vietnē fails atbild tikai “Multisite support not enabled”. Ja WordPress ir apakšmapē, ierakstiet šo mapi RewriteBase un nginx ceļos.

3. Pārbaudiet. Atveriet https://example.com/wp-includes/theme-compat/embed.php: tagad tai jāatbild “Forbidden” (403) bez kļūdas teksta. Atveriet dažas vietnes lapas un administrācijas sadaļu, lai pārliecinātos, ka tās joprojām darbojas, un tad palaidiet šo pārbaudi vēlreiz. 

Stop WordPress's core PHP files on my site from running and generating errors when opened directly.
Why it matters: anyone (bots included) can request these core files repeatedly, and every request writes a PHP error to the server log, so the logs can be bloated on purpose.

Steps:
1. Turn display_errors off for the live site (hosting PHP settings or php.ini). In wp-config.php keep WP_DEBUG true, set WP_DEBUG_DISPLAY false, and point WP_DEBUG_LOG to a file outside the web root (not wp-content/debug.log), with log rotation. Do not set WP_DEBUG to false.
2. Deny direct HTTP requests to wp-admin/includes/, wp-includes/*.php, wp-includes/js/tinymce/langs/*.php, wp-includes/theme-compat/ and wp-settings.php — WordPress.org's hardening rules in .htaccess on Apache/LiteSpeed (above # BEGIN WordPress), or deny location blocks placed before the PHP handler on nginx. Exempt only wp-includes/ms-files.php (Multisite networks from before WordPress 3.5 serve uploads through it): use ^wp-includes/(?!ms-files\.php$)[^/]+\.php$ rather than dropping the wp-includes/*.php rule.
3. Verify those addresses answer 403 with no error text, and that the site, the admin area, the block editor and uploads still work.
Tell me exactly which files you changed.

Resources:
- Hardening WordPress, securing wp-includes (WordPress.org): https://developer.wordpress.org/advanced-administration/security/hardening/#securing-wp-includes
- Debugging in WordPress (WordPress.org): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
- display_errors (PHP manual): https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

Pārbaudiet savu vietni, lai uzzinātu, vai tai ir šī problēma. Pārbaudīt vietni