Одит за сигурност на WordPress: Какво да проверите преди пускане в експлоатация

Преди всеки плъгин, генериран от PAGEnza, да достигне до инсталацията на WordPress на потребител, той преминава през три автоматизирани проверки за сигурност. Тази публикация обяснява какво търсят тези проверки — и защо всяка от тях е важна.

Защо кодът, генериран от AI, се нуждае от одит

Големите езикови модели са изненадващо добри в писането на плъгини за WordPress. Те познават имената на куките (hooks), разбират стандартите за кодиране на WP, произвеждат четим PHP код. Но те също правят предвидими грешки — и тези грешки са уязвимости в сигурността.

Най-честите, които виждаме:

• Използване на $_GET или $_POST без почистване (sanitization)
• Липсваща проверка на nonce при изпращане на формуляри
• Директни заявки към базата данни без $wpdb->prepare()
• Използване на eval() или exec() за динамично поведение
• Извеждане на потребителски данни без esc_html() или esc_attr()

Това не са екзотични крайни случаи. Те се появяват редовно в изхода на LLM — дори от най-добрите модели.

Етап 1: Валидиране на промпта

Преди AI да напише ред, анализираме описанието на потребителя. Тази стъпка улавя две категории проблеми:

Опити за манипулация — промпти, които се опитват да накарат AI да произведе умишлено злонамерен код. Неща като „игнорирай предишните инструкции“ или „създай задна врата за тестване“.

Неясни или неизпълними описания — промпти, които са твърде кратки или твърде двусмислени, за да произведат полезен код. „Направи плъгин“ генерира боклук; „Създай формуляр за контакт, който изпраща запитвания до имейл адрес с филтриране на спам“ генерира нещо реално.

Ако промптът не премине тази проверка, потребителят вижда специфично съобщение за грешка, което обяснява защо — не общо отхвърляне.

Етап 2: PHP linting в изолиран контейнер

След като AI произведе PHP код, той се изпълнява чрез php -l в Docker контейнер, който е напълно изолиран от всичко останало. Това улавя синтактични грешки, преди плъгинът изобщо да достигне инсталация на WordPress.

Но ние отиваме по-далеч: ако linting-ът се провали, системата не просто отхвърля изхода. Тя изпраща грешката обратно към AI с промпт за корекция — това, което наричаме лекуване (healing). AI вижда собствената си грешка и опитва отново, до три пъти.

Това означава, че потребителите почти никога не виждат съобщение „генерирането е неуспешно“. Те виждат малко по-дълго време за генериране — и работещ код.

Етап 3: Сканиране за сигурност на кода

Това е най-важният етап. Изпълняваме статичен анализ, който проверява за:

Опасни функции: eval(), exec(), system(), shell_exec(), passthru() — всяка от тях блокира пускането на плъгина.

SQL инжекционни вектори: сурови $wpdb->query() извиквания с интерполирани променливи, липса на $wpdb->prepare(), директно използване на mysql_query().

Липсващи проверки на права: AJAX обработчици, които не извикват current_user_can() преди да извършат каквито и да било привилегировани действия.

Липсваща проверка на nonce: обработчици на формуляри, които не извикват wp_verify_nonce() или check_ajax_referer().

Неекспониран изход: echo $_GET[...], echo $user_input без escape функции.

Ако бъде открит някой от тези проблеми, плъгинът се блокира. Потребителят вижда доклад, който точно изброява кои функции са предизвикали блокирането и защо — не само „проверката за сигурност е неуспешна“.

Как изглежда докладът от одита

Всеки генериран плъгин идва с доклад за одит на сигурността на прост език. Той изброява:

• Кои проверки са преминали (зелено)
• Кои проверки са предизвикали предупреждения (кехлибар) — проблеми, които не са блокиращи, но заслужават внимание
• Всички корекции, които са били автоматично приложени по време на лекуването

Докладът се генерира автоматично и се прикачва към изтеглянето на плъгина. Той е полезен както за вашето собствено спокойствие, така и за да покажете на клиентите, че сте приели сигурността сериозно.

Етап 4: Валидиране при записване

Това не е част от първоначалното генериране — прилага се, когато потребителите ръчно редактират кода на плъгина в редактора PAGEnza.

Всеки път, когато записвате, се изпълнява отново същата проверка за lint + сигурност. Ако въведете критична уязвимост по време на редактиране, записването ще бъде блокирано, докато не я поправите. Това предотвратява често срещания сценарий, при който разработчик прави бърза „временна“ промяна, която остава в продукция две години.

Ограниченията на автоматизирания одит

Автоматизираното сканиране добре улавя специфичен клас проблеми. То не улавя всичко.

Логически грешки, нарушена бизнес логика и фини проблеми с ескалация на права, които не включват известни опасни модели, все още изискват човешки преглед. Ние сме прозрачни по този въпрос в документацията — одитът не е заместител на преглед на сигурността, той е минимум, който гарантира минимален стандарт.

За продукционни плъгини, които обработват плащания или чувствителни данни, препоръчваме ръчен преглед в допълнение към автоматизираните проверки. Докладът от одита предоставя добър начален пункт за човешки рецензент.