Повідомлення про помилки

З точки зору безпеки висновок повідомлень про помилки несе як плюси, так і мінуси.

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

Приклад #1 Атака на змінні в HTML-сторінці

Помилки, що виникають під час роботи скриптів, є досить цінною інформацією для розробника, що містить такі дані, як функція або файл, а також номер рядка, в якому виникла помилка. Вся ця інформація може бути використана для злому. Для PHP-розробника досить звично скористатися такими функціями, як show_source() highlight_string() або highlight_file() з метою налагодження, але на працюючих сайтах це може відкрити інформацію про приховані змінні, неперевірений синтаксис та інші потенційно небезпечні моменти. Особливо небезпечною є наявність коду з вбудованим механізмом налагодження в публічних частинах сайту. Зломщик може спробувати запустити налагоджувальний механізм, підбираючи основні ознаки налагодження:

Приклад #2 Використання стандартних змінних налагоджувальних

Незалежно від методу обробки помилок, можливість перевірки системи на наявність помилок забезпечує зломщика додатковою інформацією.

Наприклад, стандартний висновок про помилку вказує на операційну систему, в якій виконуються PHP-скрипти. Якщо зломщик аналізує звичайну сторінку сайту з розширенням.

Також повідомлення про помилку може дати інформацію про базу даних, що використовується, або, наприклад, як побудована логіка роботи скриптів. Це, у свою чергу, може дозволити зломщику підключитися до відкритого порту бази даних або знайти певні помилки в коді. Спробуючи почергово різні невірні блоки даних, зловмисник може визначити порядок автентифікації у скрипті (наприклад, за номерами рядків з помилками) чи перевіряти наявність дір різні ділянки коду.

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

Існує три основні способи вирішення цієї проблеми. Перший полягає в тому, щоб структурувати всі функції і спробувати компенсувати обсяг помилок, що видаються. Другий спосіб - повністю відключити у діючому коді виведення повідомлень про помилки. І, нарешті, третій спосіб – використовувати спеціальні засоби PHP для створення власного обробника помилок. Залежно від політики безпеки, яку ви використовуєте, ви можете застосувати у вашій конкретній ситуації всі три способи.

Один із можливих способів убезпечити ваш код перед його публікацією у спільний доступ – це використання функції PHP error_reporting()що може допомогти виявити потенційно небезпечні змінні. Тестуючи код перед випуском релізу за допомогою значення **E_ALL**Ви можете легко знайти ділянки коду, в яких змінні можуть бути замінені або модифіковані. Після закінчення тестування, ви можете або повністю відключити всі повідомлення про помилки встановивши error_reporting() в 0, або вимкнути їх виведення за допомогою директиви php.ini display_errors, ізолювавши таким чином ваш код від промацування. Якщо ви вирішили використовувати останній спосіб, необхідно також вказати шлях до лог-файлу за допомогою директиви error_log та включити директиву log_errors

Приклад #3 Пошук потенційно небезпечних змінних за допомогою E_ALL

Loading...