Варто обмежити прямий доступ до файлів тем?


31

Час від часу я стикався з наступним фрагментом у темах:

if ( ! defined('ABSPATH')) exit('restricted access');

Це на початку деяких (усіх?) PHP-файлів у темі, і це повинно перешкоджати прямому доступу до файлу з нечесних джерел.

Я бачу, що це не входить у двадцять десять чи одинадцять, і я ніколи не бачив його рекомендувати в офіційній документації WordPress. Мені це здається гарною ідеєю, але я також не знаю достатньо про безпеку, щоб судити про це і не можу знайти багато з Google.

Це щось, що я маю мати у своїх спеціальних темах? Якщо так, чи має бути він у всіх PHP-файлах чи лише деяких?


7
Просто для пізніших читачів це можна написати коротше і приємніше:defined('ABSPATH') OR exit;
— кайзер

або навіть коротше:: defined('WPINC') ? : die();P
— Тім Ельсасс

Мені також цікаво, чи варто вводити такий код, як цей, щоб уникнути помилок PHP щодо невизначених функцій у моїх журналах помилок. Ботам, здається, іноді подобається безпосередньо потрапляти на ці файли, і я отримую помилки на кшталт "Заклик до невизначеної функції query_posts ()", тому що завантажувальний пакет WP не завантажений
— Метт Кіс

Відповіді:


26

Зазвичай вам це не потрібно. Але ... є принаймні один крайній випадок:

  • Якщо файл теми - це частина шаблону ,
  • і він використовує глобальні змінні з контексту виклику (батьківський файл),
  • і register_globals є on,
  • і це просто використання цих змінних без будь-якої перевірки безпеки ...

... зловмисник може назвати цей файл, встановити відсутні змінні GETабо POSTі зробити файл теми друку таких проблем . І тоді це проблема безпеки.

Отже ... найкращий варіант - це не контекстна перевірка, як ця у вашому прикладі, а хороший код: уникайте глобальних змінних, перевіряйте їхній вміст перед тим, як роздрукувати його.

У деяких випадках я додаю перевірку контексту, коли думаю, що хтось інший буде використовувати мій код і змінити його, не маючи на увазі безпеки. Це не боляче.


Якщо частина шаблону все ще містила принаймні один виклик функції, який би спричинив фатальну помилку PHP, чи можливий цей сценарій?
— Chris_O

@Chris_O Залежить від порядку появи.
— fuxia

Має сенс і повністю погоджуватись з іншою причиною не використовувати глобальні змінні між файловими дзвінками.
— Chris_O

1
Завжди краще бути безпечним, ніж шкодувати. Занадто багато безпеки не може зашкодити, чи не може?
— Шон Берг

2
Якщо ви все зробите правильно, не слід використовувати код, який не потрібен. Це питання є доказом того, що це ускладнює дотримання коду.
— фуксія
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.