WordPress saugos auditas: Ką tikrinti prieš paleidžiant

Prieš bet koks PAGEnza sukurtas papildinys pasiekia vartotojo WordPress diegimą, jis pereina tris automatizuotus saugos patikrinimus. Šis įrašas paaiškina, ko šie patikrinimai ieško – ir kodėl kiekvienas iš jų yra svarbus.

Kodėl AI sugeneruotas kodas reikalauja audito

Daugiakalbiai modeliai stebėtinai gerai rašo WordPress papildinius. Jie žino kabliukų (hooks) pavadinimus, supranta WP kodavimo standartus, gamina skaitomą PHP. Tačiau jie taip pat daro nuspėjamas klaidas – ir šios klaidos yra saugumo pažeidžiamybės.

Dažniausiai, ką matome:

• $_GET arba $_POST naudojimas be valymo (sanitization)
• Nonce patvirtinimo trūkumas pateikiant formas
• Tiesioginės duomenų bazės užklausos be $wpdb->prepare()
• eval() arba exec() naudojimas dinamiškam elgesiui
• Vartotojo duomenų išvedimas be esc_html() arba esc_attr()

Tai nėra egzotiški kraštutiniai atvejai. Jie reguliariai pasirodo LLM išvestyse – net ir iš geriausių modelių.

1 etapas: Komandinės eilutės (Prompt) patvirtinimas

Prieš AI parašydamas eilutę, mes analizuojame vartotojo aprašymą. Šis žingsnis aptinka dvi problemų kategorijas:

Manipuliacijos bandymai – komandinės eilutės, kurios bando priversti AI gaminti sąmoningai kenkėjišką kodą. Tokie dalykai kaip „ignoruoti ankstesnes instrukcijas“ arba „sukurti testavimo užpakalines duris“.

Neaiškūs arba neįgyvendinami aprašymai – komandinės eilutės, kurios yra per trumpos arba per neaiškios, kad sukurtų naudingą kodą. „Sukurti papildinį“ gamina šiukšles; „Sukurti kontaktinę formą, kuri siunčia pateiktis į el. pašto adresą su šlamšto filtravimu“ gamina ką nors realaus.

Jei komandinė eilutė nepraeina šio patikrinimo, vartotojas mato konkrečią klaidos žinutę, paaiškinančią kodėl – ne bendrą atmetimą.

2 etapas: PHP linting izoliuotame konteineryje

Kai AI sugeneruoja PHP kodą, jis vykdomas per php -l Docker konteineryje, kuris yra visiškai izoliuotas nuo visko kito. Tai aptinka sintaksės klaidas dar prieš papildiniui pasiekiant WordPress diegimą.

Bet mes einame toliau: jei linting nepavyksta, sistema neatsisako išvesties. Ji siunčia klaidą atgal AI su pataisymo komandine eilute – tai, ką mes vadiname gydymu (healing). AI mato savo klaidą ir bando dar kartą, iki trijų kartų.

Tai reiškia, kad vartotojai beveik niekada nemato pranešimo „generavimas nepavyko“. Jie mato šiek tiek ilgesnį generavimo laiką – ir veikiantį kodą.

3 etapas: Kodo saugos patikrinimas

Tai svarbiausias etapas. Mes vykdome statinę analizę, kuri tikrina:

Pavojingos funkcijos: eval(), exec(), system(), shell_exec(), passthru() – bet kuri iš jų blokuoja papildinio išleidimą.

SQL injekcijos vektoriai: neapdoroti $wpdb->query() kvietimai su interpoliuotais kintamaisiais, $wpdb->prepare() trūkumas, tiesioginis mysql_query() naudojimas.

Trūkstami leidimų patikrinimai: AJAX tvarkytuvai, kurie nekviečia current_user_can() prieš atlikdami bet kokius privilegijuotus veiksmus.

Nonce patvirtinimo trūkumas: formų tvarkytuvai, kurie nekviečia wp_verify_nonce() arba check_ajax_referer().

Neapdorota išvestis (Unescaped output): echo $_GET[...], echo $user_input be apdorojimo funkcijų.

Jei kas nors iš šių randama, papildinys yra blokuojamas. Vartotojas mato ataskaitą, kurioje tiksliai išvardijama, kurios funkcijos sukėlė blokavimą ir kodėl – ne tik „saugos patikrinimas nepavyko“.

Kaip atrodo audito ataskaita

Kiekvienas sukurtas papildinys pateikiamas su aiškios kalbos saugos audito ataskaita. Jame išvardijama:

• Kokie patikrinimai praėjo (žalia)
• Kokie patikrinimai sukėlė įspėjimus (gintarinė) — problemos, kurios nėra blokuojančios, bet nusipelno dėmesio
• Bet kokie pataisymai, kurie buvo automatiškai pritaikyti gydymo metu

Ataskaita generuojama automatiškai ir pridedama prie papildinio atsisiuntimo. Ji yra naudinga tiek jūsų pačių pasitikėjimui, tiek klientams parodyti, kad saugumą vertinote rimtai.

4 etapas: Patvirtinimas išsaugojant

Tai nėra pradinio generavimo dalis — tai taikoma, kai vartotojai rankiniu būdu redaguoja papildinio kodą PAGEnza redaktoriuje.

Kiekvieną kartą, kai išsaugote, vėl paleidžiamas tas pats lint + saugos patikrinimas. Jei redaguodami įvedate kritinę pažeidžiamybę, išsaugojimas bus blokuojamas, kol ją pataisysite. Tai užkerta kelią įprastam scenarijui, kai kūrėjas atlieka greitą „laikiną“ pakeitimą, kuris lieka gamyboje dvejus metus.

Automatizuoto audito apribojimai

Automatinis skenavimas gerai aptinka tam tikrą problemų klasę. Jis neaptinka visko.

Loginės klaidos, sugedusi verslo logika ir subtilios leidimų eskalavimo problemos, kurios neapima žinomų pavojingų modelių, vis tiek reikalauja žmogiškojo peržiūros. Mes esame skaidrūs dėl to dokumentacijoje – auditas nepakeičia saugos peržiūros, tai yra pagrindas, garantuojantis minimalų standartą.

Dėl mokėjimus ar jautrius duomenis tvarkančių papildinių gamybos mes rekomenduojame atlikti rankinę peržiūrą papildomai prie automatizuotų patikrinimų. Audito ataskaita suteikia žmogui-recenzentui gerą pradžios tašką.