Накратко: Код ревюто за сигурност на PHP е целенасочено четене на изходния код с един въпрос: къде външни входни данни могат да направят нещо, което не им е позволено? Доказали са се две форми, ревю на всяка промяна и базово ревю на целия проект, подкрепени от статичен анализ с PHPStan или Psalm. Уязвимости в интерпретатора на PHP като PHP2Shell ревюто не открива, но открива многото грешки, които възникват в собствения код.
Защо точно сега да погледнем в собствения код?
PHP2Shell зае през последната седмица на октомври 2026 г. най-вече администраторите. Пачване, рестарт, доказване: работата беше на сървъра. За екипите по разработка след това остава неудобен въпрос. Ако атакуващ може да изпълни код през друга уязвимост, какво намира в нашето приложение? И колко от тези уязвимости сме написали сами?
OWASP Top 10 показва от години, че повечето слабости в уеб приложенията не са екзотични. Липсващ контрол на достъпа, инжекции и несигурна конфигурация стоят високо. Това са грешки, които един опитен поглед открива в изходния код много преди атакуващ да ги изпробва.
Към това се добавя практична причина. Много фирми така или иначе в момента проверяват, пачват и заздравяват сървърите си. Който прегледа и собственото си приложение наведнъж, затваря пропастта между експлоатацията и разработката. Заздравен сървър с уязвимо приложение остава атакуем, както и чисто написано приложение върху непачнат PHP.
Базово ревю или ревю на промените?
OWASP Cheat Sheet за Secure Code Review разграничава два вида, които на практика се допълват:
| Вид | Кога | Обем | Цел |
|---|---|---|---|
| Базово ревю (Baseline) | нов проект, голямо издание, след инцидент | целият проект, претеглен по риск | Да се отчете наличното количество слабости |
| Ревю на промените (Diff) | всеки pull request | само променения код | Да се предотвратят нови грешки |
Базовото ревю след инцидент е особено ценно. Който току-що е почистил сървър, трябва да знае дали приложението предлага други входни точки. Ревюто на промените поддържа състоянието чисто след това, защото всяка промяна преди сливането се чете и от гледна точка на сигурността.
Код ревю в PHP: къде се трупат грешките за сигурност
В PHP проектите си струва целенасочен поглед върху определени функции и образци. Те не са забранени, но за всяко намерено място трябва да се зададе въпросът дали външни данни могат да попаднат в него.
| Образец в кода | Възможен риск | Задълбочаване |
|---|---|---|
| SQL чрез конкатенация на низове с променливи | SQL инжекция | Предотвратяване на SQL инжекция в PHP |
unserialize() върху данни отвън |
Инжектиране на обекти | Несигурна десериализация в PHP |
include или require с променлив път |
Включване на чужди файлове | Предотвратяване на Local и Remote File Inclusion |
exec(), system(), shell_exec(), proc_open() |
Изпълнение на команди | Command Injection |
Изход без htmlspecialchars() |
Cross-Site Scripting | екраниране според контекста |
== при токени или хешове |
Преобразуването на типове заобикаля проверките | hash_equals(), стриктни сравнения |
eval(), extract() върху входни данни |
Инжектиране на код или променливи | най-често да се премахнат без заместване |
Бърз първи преглед се постига с просто търсене. То не замества ревюто, но показва откъде да се започне:
# Места с рискови функции в собствения код (vendor е изключен)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Поне толкова важно е какво липсва в кода. Проверява ли всеки контролер дали влезлият потребител има право да вижда или променя точно този запис? Ограничават ли се качванията по тип и място на съхранение? Такива пропуски не открива никое търсене по имена на функции, а само четенето на процеса.
Инструменти, които подкрепят ревюто
Статичният анализ проверява кода, без да го изпълнява. PHPStan и Psalm откриват грешки в типовете, недостижим код и погрешни предположения за върнатите стойности. Psalm предлага допълнително Taint анализ, който проследява дали данни от заявки текат непроверени към критични места. И двата могат да се пооставят стъпка по стъпка, така че да започнат и по-стари проекти. Преглед дава Статичен анализ: PHPStan и Psalm.
# Статичен анализ в проекта, повишавайте нивото стъпка по стъпка
vendor/bin/phpstan analyse src --level=5
# Taint анализ с Psalm
vendor/bin/psalm --taint-analysis
Инструментите дават указания, а не присъди. Всяко попадение изисква оценка, а празен отчет не означава, че приложението е сигурно.
Също толкова важно като откриването е записването. Всяка находка трябва да се записва с местонахождение, кратко описание, оценка на риска, препоръчана корекция и статус, най-добре директно в системата за билети на екипа. Така може да се проследи какво е отстранено, какво е съзнателно прието и какво още е отворено. След отстраняването си струва втори поглед: отстранена ли е причината или само един симптом? Появява ли се същият образец на други места в кода? Грешка, направена веднъж, по опит рядко се крие само на едно място.
Контролен списък за собствения екип
За ревюта на промените се е доказал кратък, фиксиран списък. Той принадлежи в шаблона за pull request:
- Откъде идват всички данни, които тази промяна обработва, и проверяват ли се от страна на сървъра?
- Заявките към базата данни изграждат ли се изключително с заместители?
- Екраниран ли е всеки изход за своя контекст, тоест HTML, атрибут, JavaScript или URL?
- Проверява ли кодът правото точно за този обект, а не само влизането в системата?
- Попадат ли пароли, токени или лични данни в журнали или съобщения за грешки?
- Има ли тайни в кода или във версионирани файлове?
- Добавени ли са нови зависимости и поддържат ли се?
Давайте критичните за сигурността части като вход, управление на права, процеси на плащане и качвания винаги да бъдат прочетени от втори човек, който не е участвал в кода. Чуждият поглед открива предположения, които авторът смята за самоочевидни.
Как помага PHP SOS конкретно?
- Извършваме със специализирани партньори базово ревю на Вашето PHP приложение, претеглено по частите с най-висок риск.
- Настройваме PHPStan или Psalm според състоянието на Вашия проект и пишем контролния списък за Вашите pull request-и.
- Свързваме ревюто с поглед върху сървъра и конфигурацията, защото много уязвимости възникват едва във взаимодействието.
- Където е желана проверка отвън, допълваме ревюто с одит на сигурността и тест за проникване.
Заключение: Код ревюто е най-евтиното място за отстраняване на грешки в сигурността, а именно преди те да бъдат доставени. Който проверява всяка промяна с кратък списък и от време на време преглежда проекта изцяло, намалява трайно повърхността за атака.
Често задавани въпроси
Каква е разликата между код ревю и тест за проникване?
Код ревюто чете изходния текст и открива грешки, преди да бъдат доставени. Тестът за проникване атакува работещото приложение отвън. И двете се допълват: ревюто открива причините, тестът показва какво действително може да се използва.
Открива ли код ревюто уязвимости като PHP2Shell?
Не. PHP2Shell е в интерпретатора на PHP, а не в кода на приложението. Срещу това помага само актуализация на PHP с рестарт. Ревюто открива грешки в собствения код, например инжекции, липсващи проверки на правата или несигурна десериализация.
Достатъчни ли са PHPStan или Psalm за ревю за сигурност?
Те са добра основа и откриват автоматично много грешки. Логически грешки, липсващи проверки на правата и погрешни предположения за процесите обаче разпознава само човек, който знае какво трябва да прави приложението.
Колко време отнема едно код ревю за сигурност?
Зависи от обема. Ревю на всяка промяна в pull request отнема малко време. Пълно ревю на разраснал се проект е отделно начинание, което се ограничава по риск до най-важните части.