# Код ревю за сигурност в PHP проекти

> Код ревю за сигурност на PHP: базова линия или diff, рискови функции, инструменти като PHPStan и Psalm и контролен списък за собствения екип.

Източник: https://phpsos.de/bg/blog/sicherheits-code-review-php/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Код ревюто за сигурност на 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](https://phpsos.de/bg/ratgeber/sql-injection-php/) |
| `unserialize()` върху данни отвън | Инжектиране на обекти | [Несигурна десериализация в PHP](https://phpsos.de/bg/ratgeber/deserialisierung-php/) |
| `include` или `require` с променлив път | Включване на чужди файлове | [Предотвратяване на Local и Remote File Inclusion](https://phpsos.de/bg/ratgeber/lfi-rfi/) |
| `exec()`, `system()`, `shell_exec()`, `proc_open()` | Изпълнение на команди | Command Injection |
| Изход без `htmlspecialchars()` | Cross-Site Scripting | екраниране според контекста |
| `==` при токени или хешове | Преобразуването на типове заобикаля проверките | `hash_equals()`, стриктни сравнения |
| `eval()`, `extract()` върху входни данни | Инжектиране на код или променливи | най-често да се премахнат без заместване |

Бърз първи преглед се постига с просто търсене. То не замества ревюто, но показва откъде да се започне:

```bash
# Места с рискови функции в собствения код (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](https://phpsos.de/bg/php/statische-analyse/).

```bash
# Статичен анализ в проекта, повишавайте нивото стъпка по стъпка
vendor/bin/phpstan analyse src --level=5
# Taint анализ с Psalm
vendor/bin/psalm --taint-analysis
```

Инструментите дават указания, а не присъди. Всяко попадение изисква оценка, а празен отчет не означава, че приложението е сигурно.

Също толкова важно като откриването е записването. Всяка находка трябва да се записва с местонахождение, кратко описание, оценка на риска, препоръчана корекция и статус, най-добре директно в системата за билети на екипа. Така може да се проследи какво е отстранено, какво е съзнателно прието и какво още е отворено. След отстраняването си струва втори поглед: отстранена ли е причината или само един симптом? Появява ли се същият образец на други места в кода? Грешка, направена веднъж, по опит рядко се крие само на едно място.

## Контролен списък за собствения екип

За ревюта на промените се е доказал кратък, фиксиран списък. Той принадлежи в шаблона за pull request:

1. Откъде идват всички данни, които тази промяна обработва, и проверяват ли се от страна на сървъра?
2. Заявките към базата данни изграждат ли се изключително с заместители?
3. Екраниран ли е всеки изход за своя контекст, тоест HTML, атрибут, JavaScript или URL?
4. Проверява ли кодът правото точно за този обект, а не само влизането в системата?
5. Попадат ли пароли, токени или лични данни в журнали или съобщения за грешки?
6. Има ли тайни в кода или във версионирани файлове?
7. Добавени ли са нови зависимости и поддържат ли се?

> **Съвет:**
> Давайте критичните за сигурността части като вход, управление на права, процеси на плащане и качвания винаги да бъдат прочетени от втори човек, който не е участвал в кода. Чуждият поглед открива предположения, които авторът смята за самоочевидни.

## Как помага PHP SOS конкретно?

- Извършваме със специализирани партньори базово ревю на Вашето PHP приложение, претеглено по частите с най-висок риск.
- Настройваме PHPStan или Psalm според състоянието на Вашия проект и пишем контролния списък за Вашите pull request-и.
- Свързваме ревюто с поглед върху сървъра и конфигурацията, защото много уязвимости възникват едва във взаимодействието.
- Където е желана проверка отвън, допълваме ревюто с [одит на сигурността и тест за проникване](https://phpsos.de/bg/leistungen/sicherheitsaudit-penetrationstest/).

**Заключение:** Код ревюто е най-евтиното място за отстраняване на грешки в сигурността, а именно преди те да бъдат доставени. Който проверява всяка промяна с кратък списък и от време на време преглежда проекта изцяло, намалява трайно повърхността за атака.


## Често задавани въпроси

**Каква е разликата между код ревю и тест за проникване?**  
Код ревюто чете изходния текст и открива грешки, преди да бъдат доставени. Тестът за проникване атакува работещото приложение отвън. И двете се допълват: ревюто открива причините, тестът показва какво действително може да се използва.

**Открива ли код ревюто уязвимости като PHP2Shell?**  
Не. PHP2Shell е в интерпретатора на PHP, а не в кода на приложението. Срещу това помага само актуализация на PHP с рестарт. Ревюто открива грешки в собствения код, например инжекции, липсващи проверки на правата или несигурна десериализация.

**Достатъчни ли са PHPStan или Psalm за ревю за сигурност?**  
Те са добра основа и откриват автоматично много грешки. Логически грешки, липсващи проверки на правата и погрешни предположения за процесите обаче разпознава само човек, който знае какво трябва да прави приложението.

**Колко време отнема едно код ревю за сигурност?**  
Зависи от обема. Ревю на всяка промяна в pull request отнема малко време. Пълно ревю на разраснал се проект е отделно начинание, което се ограничава по риск до най-важните части.

## Източници

- [OWASP: Secure Code Review Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [PHPStan](https://phpstan.org/)