Накратко: Логването в PHP с оглед на защитата на данните означава: да се записват изцяло събитията, свързани със сигурността, но никога пароли, токени, идентификатори на сесии и чувствителни данни на клиенти да не попадат в журнала. Грешките принадлежат в журнала, а не на екрана, журналите стоят извън уеб корена и са защитени от промяна. Колко дълго остават журналите, решавате съзнателно заедно с длъжностното лице по защита на данните.
Между запазване на следите и теч на данни
След PHP2Shell специализираните медии посъветваха журналите на уеб сървъра да се съхраняват от 20.10.2026 г. Който искаше да го приложи, често установяваше две неща. Или журналите отдавна бяха ротирани и изтрити. Или съдържаха неща, които никога не е трябвало да са там: пълни въведени данни от формуляри, пароли от неуспешни входове, API ключове в URL адреси.
И двете са проблем. Без журнали един инцидент трудно може да се възстанови. С твърде много съдържание журналът сам става цел, защото който получи достъп до сървъра, с готовност го чете. Доброто логване е между двете: достатъчно за търсене на следи, възможно най-малко защитавани данни.
Какво трябва да записва едно PHP приложение
OWASP Logging Cheat Sheet назовава събития, които са важни за сигурността и проследимостта. За типични PHP приложения те могат да се обобщят така:
| В журнала | Не в журнала |
|---|---|
| успешни и неуспешни входове | пароли, дори въведени погрешно |
| неуспешни проверки на правата | идентификатори на сесии в явен текст |
| промени в акаунти и права | Access Token-и и API ключове |
| грешки при проверка на входните данни | данни за достъп до базата данни |
| качвания, импорти и експорти | платежни и банкови данни |
| промени в конфигурацията, старт и стоп | здравни данни и други особено защитавани данни |
| грешки по време на изпълнение с място, без полезни данни | пълно съдържание на формуляри |
Всеки запис трябва да отговаря на въпросите кога, къде, кой и какво: времеви печат, приложение и хост, адрес на източника, идентификатор на потребителя, вид на събитието и резултат. Имена или имейл адреси често могат да се маскират или да се заменят с вътрешен идентификатор, без да се губи ползата.
Два източника на нежелани данни в журнала често се пренебрегват. Първият са URL адресите: ако в query string стои токен, ключ за нулиране на парола или имейл адрес, той попада автоматично в журнала за достъп на уеб сървъра, в журналите на прокси и в историята на браузъра. Такива стойности принадлежат в тялото на заявката или в заглавна част, а не в адреса. Вторият източник е режимът за отстраняване на грешки (debug). Фреймуърците и добавките в debug режим често записват пълни заявки, заявки към базата данни и променливи на средата. Ако този режим остане активен след търсене на грешка, неусетно расте файл с точно информацията, която атакуващият търси. Проверявайте след всяко търсене на грешки дали debug изходите са изключени отново, и изтривайте файловете, които са възникнали при това.
Логване в PHP: основните настройки
Първото ниво е самият PHP. В продукция грешките трябва да се записват, но да не се извеждат. Журналът стои извън уеб корена, за да не може да бъде извикан през URL.
; php.ini или FPM пул за продукция
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log
Защо видимите грешки са опасни, описва Изключване на изхода на грешките в продукция. Как са свързани грешките и изключенията в PHP, обяснява Грешки и изключения в PHP.
Второто ниво е приложението. Много фреймуърци ползват за това библиотека по стандарта PSR-3 на PHP-FIG, който определя единен интерфейс на логъра. Важна не е библиотеката, а дисциплината: избирайте контекстните данни съзнателно, вместо да записвате цели заявки или обекти в журнала.
<?php
// Обезвреждане и маскиране на входните данни преди логване
function logSicher(string $text): string {
return mb_substr(str_replace(["\r", "\n"], ' ', $text), 0, 200);
}
function maskiereMail(string $mail): string {
[$name, $domain] = array_pad(explode('@', $mail, 2), 2, '');
return mb_substr($name, 0, 1) . '***@' . $domain;
}
$logger->warning('Anmeldung fehlgeschlagen', [
'benutzer' => maskiereMail(logSicher($_POST['email'] ?? '')),
'ip' => $_SERVER['REMOTE_ADDR'] ?? '',
// никога: 'passwort' => $_POST['passwort']
]);
Log Injection и манипулирани записи
Ако едно приложение записва входни данни нефилтрирани в журнала, атакуващият може с нови редове да създава фалшифицирани записи. Това обърква анализа и може да прикрие следи. OWASP Cheat Sheet препоръчва структурирани формати като JSON, премахване или кодиране на новите редове и ограничаване на дължината на входните данни в журнала.
Също толкова важна е защитата на самите журнали:
- Съхранение извън уеб корена и с права, които потребителят на уеб сървъра има за писане, но не и за изтриване на стари файлове.
- Копие на втора система, например чрез Syslog през шифрована връзка. Който превземе сървъра, не бива лесно да изтрие следите.
- Ограничете достъпа за четене и го записвайте. Журналите почти винаги съдържат лични данни.
- Разпознайте отпадане: ако журналът внезапно остане празен, това е предупредителен сигнал.
- Синхронизирайте часа: всички сървъри вземат часа от един и същ източник и записват в журнала еднозначна часова зона. Иначе записите на уеб сървъра, PHP и базата данни след инцидент трудно могат да се съберат във времева линия.
Журнал, който стои само на компрометирания сървър, е слабо доказателство. Текущо копие на отделна система след инцидент често е единственият надежден източник.
Съзнателно решение за съхранението и защитата на данните
Колко дълго журналите могат и трябва да се съхраняват, е преценка между интереса към сигурността, свеждането на данните до минимум и законови или договорни изисквания. Чл. 32 от ОРЗД изисква подходящи за риска технически и организационни мерки, наред с другото за трайно осигуряване на поверителността, целостта и наличността на системите; водене на журнали може да допринесе за това. Същевременно личните данни не бива да се съхраняват по-дълго от необходимото.
Определете затова срок за всеки вид журнал, запишете обосновката и съгласувайте и двете със своето длъжностно лице по защита на данните. При текущо разследване може да е нужно журналите да се запазят извън обичайния срок. Това трябва тогава също да се документира. Тази страница е обща информация, а не правна консултация; при конкретни въпроси помагат длъжностното лице по защита на данните и адвокат. Как да анализирате журналите след атака, показва Анализ на журналите на уеб сървъра след атака.
Как помага PHP SOS конкретно?
- Проверяваме Вашите съществуващи журнали за пароли, токени и други данни, които не принадлежат там.
- Настройваме PHP и приложението така, че грешките да се записват, но да не се показват.
- Въвеждаме защитено копие на журналите на отделна система.
- Чрез Security мониторинг анализираме непрекъснато записите, свързани със сигурността, и съобщаваме разбираемо за забелязаното.
Заключение: Добрите журнали са пестеливи по съдържание и щедри по защита. Който днес определи какво се записва и какво никога, има в най-лошия случай използваеми следи, а не допълнителен теч на данни.
Често задавани въпроси
Може ли IP адреси да стоят в лог файловете?
IP адресите могат да бъдат лични данни. Дали и за колко време ги съхранявате, зависи от целта и правното основание. Изяснете обема и срока на съхранение със своето длъжностно лице по защита на данните; тази страница не е правна консултация.
Колко дълго трябва да се съхраняват журналите?
Толкова дълго, колкото е нужно и правно допустимо за сигурността и търсенето на грешки, и не повече. След PHP2Shell специализираната преса препоръча журналите на уеб сървъра да се съхраняват от 20.10.2026 г. Определете сроковете съзнателно и ги документирайте.
Какво е Log Injection?
Ако входни данни съдържат нови редове или управляващи знаци и се записват нефилтрирани в журнала, те могат да създадат фалшифицирани записи. Това изкривява анализите. Структурирани формати като JSON и премахването на новите редове предотвратяват това.
Трябва ли display_errors да е изключено в продукция?
Да. Грешките трябва да отиват в журнала, а не в изхода към посетителите. Видимите съобщения за грешки издават пътища, заявки и понякога данни за достъп.