Ревизија безбедности WordPress-а: Шта проверити пре објављивања

Пре него што било који додатак генерисан од стране PAGEnza дође до WordPress инсталације корисника, он пролази кроз три аутоматизоване безбедносне провере. Овај пост објашњава шта те провере траже – и зашто је свака од њих важна.

Зашто код генерисан од стране AI захтева ревизију

Велики језички модели су изненађујуће добри у писању WordPress додатака. Они познају имена кука (hooks), разумеју WP стандарде кодирања, производе читљив PHP. Али такође праве предвидљиве грешке – и те грешке су безбедносне рањивости.

Најчешће које видимо:

• Коришћење $_GET или $_POST без чишћења (sanitization)
• Недостајућа провера nonce-а при слању образаца
• Директни упити бази података без $wpdb->prepare()
• Коришћење eval() или exec() за динамичко понашање
• Излаз корисничких података без esc_html() или esc_attr()

Ово нису егзотични гранични случајеви. Редовно се појављују у излазима LLM-а – чак и код најбољих модела.

Фаза 1: Валидација упита (Prompt validation)

Пре него што AI напише иједан ред, анализирамо опис корисника. Овај корак открива две категорије проблема:

Покушаји манипулације – упити који покушавају да натерају AI да произведе намерно злонамеран код. Ствари попут „игнориши претходна упутства“ или „креирај задња врата за тестирање“.

Нејасни или неизводљиви описи – упити који су превише кратки или превише нејасни да би произвели користан код. „Направи додатак“ генерише смеће; „Креирај контакт формулар који шаље уносе на имејл адресу са филтрирањем нежељене поште“ генерише нешто стварно.

Ако упит не прође ову проверу, корисник види специфичну поруку о грешци која објашњава зашто – не опште одбијање.

Фаза 2: Linting PHP-а у изолованом контејнеру

Када 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().

Необрађени излаз (Unescaped output): echo $_GET[...], echo $user_input без функција за обраду.

Ако се било шта од овога пронађе, додатак се блокира. Корисник види извештај који тачно наводи које су функције покренуле блокаду и зашто – не само „провера безбедности није успела“.

Како изгледа извештај о ревизији

Сваки генерисан додатак долази са извештајем о ревизији безбедности једноставним језиком. Он наводи:

• Које су провере прошле (зелено)
• Које су провере покренуле упозорења (ћилибар) — проблеми који нису блокирајући, али заслужују пажњу
• Сва исправљања која су аутоматски примењена током исцељења

Извештај се генерише аутоматски и прилаже преузимању додатка. Користан је како за ваше самопоуздање, тако и за показивање клијентима да сте безбедност схватили озбиљно.

Фаза 4: Провера приликом чувања

Ово није део почетног генерисања — примењује се када корисници ручно уређују код додатка у PAGEnza уређивачу.

Сваки пут када сачувате, поново се покреће иста провера lint + безбедности. Ако током уређивања унесете критичну рањивост, чување ће бити блокирано док је не поправите. Ово спречава уобичајени сценарио у којем програмер прави брзу „привремену“ промену која остаје у продукцији две године.

Ограничења аутоматске ревизије

Аутоматско скенирање добро открива одређену класу проблема. Не открива све.

Логичке грешке, пословна логика која је покварена и суптилни проблеми ескалације дозвола који не укључују познате опасне обрасце и даље захтевају људски преглед. Ми смо транспарентни у вези са тим у документацији — ревизија не замењује безбедносни преглед, она је подлога која гарантује минимални стандард.

За производне додатке који обрађују плаћања или осетљиве податке, препоручујемо ручни преглед поред аутоматизованих провера. Извештај о ревизији пружа човеку-рецензенту добру полазну тачку.