WordPress drošības audits: Ko pārbaudīt pirms publicēšanas

Pirms jebkurš PAGEnza ģenerēts spraudnis sasniedz lietotāja WordPress instalāciju, tas iziet trīs automatizētas drošības pārbaudes. Šis ieraksts izskaidro, ko šīs pārbaudes meklē — un kāpēc katra no tām ir svarīga.

Kāpēc AI ģenerētajam kodam ir nepieciešams audits

Lielie valodu modeļi ir pārsteidzoši labi WordPress spraudņu rakstīšanā. Viņi zina āķu (hooks) nosaukumus, saprot WP kodēšanas standartus, rada salasāmu PHP. Bet viņi arī pieļauj paredzamas kļūdas — un šīs kļūdas ir drošības ievainojamības.

Visbiežākās, ko redzam:

• $_GET vai $_POST lietošana bez attīrīšanas (sanitization)
• Nonce pārbaudes trūkums veidlapu iesniegšanā
• Tieši datu bāzes vaicājumi bez $wpdb->prepare()
• eval() vai exec() lietošana dinamiskai uzvedībai
• Lietotāja datu izvadīšana bez esc_html() vai esc_attr()

Šīs nav eksotiskas galējās situācijas. Tās regulāri parādās LLM izvada datos — pat no labākajiem modeļiem.

1. posms: Pamudinājuma (Prompt) validācija

Pirms AI raksta vienu rindiņu, mēs analizējam lietotāja aprakstu. Šis solis uztver divas problēmu kategorijas:

Manipulācijas mēģinājumi — pamudinājumi, kas mēģina likt AI radīt apzināti ļaunprātīgu kodu. Lietas, piemēram, "ignorēt iepriekšējās instrukcijas" vai "izveidot aizmugures durvis testēšanai“.

Nenoteikti vai neizpildāmi apraksti — pamudinājumi, kas ir pārāk īsi vai pārāk neprecīzi, lai radītu noderīgu kodu. "Izveido spraudni" rada atkritumus; "Izveido kontaktformu, kas nosūta iesniegumus uz e-pasta adresi ar surogātpasta filtrēšanu" rada kaut ko reālu.

Ja pamudinājums neiziet šo pārbaudi, lietotājs redz konkrētu kļūdas ziņojumu, kas izskaidro, kāpēc — nevis vispārīgu noraidījumu.

2. posms: PHP lintēšana izolētā konteinerī

Kad AI ir ģenerējis PHP kodu, tas tiek izpildīts, izmantojot php -l Docker konteinerī, kas ir pilnībā izolēts no visa cita. Tas uztver sintakses kļūdas, pirms spraudnis vispār sasniedz WordPress instalāciju.

Bet mēs ejam tālāk: ja lintēšana neizdodas, sistēma nevis vienkārši noraida izvadi. Tā nosūta kļūdu atpakaļ AI ar labošanas pamudinājumu — ko mēs saucam par dziedināšanu (healing). AI redz savu kļūdu un mēģina vēlreiz, līdz trīs reizēm.

Tas nozīmē, ka lietotāji gandrīz nekad neredz ziņojumu "ģenerēšana neizdevās". Viņi redz nedaudz ilgāku ģenerēšanas laiku — un strādājošu kodu.

3. posms: Koda drošības skenēšana

Šis ir vissvarīgākais posms. Mēs veicam statisko analīzi, kas pārbauda:

Bīstamas funkcijas: eval(), exec(), system(), shell_exec(), passthru() — jebkura no tām bloķē spraudņa izlaišanu.

SQL injekciju vektori: neapstrādāti $wpdb->query() izsaukumi ar interpolētām mainīgajiem, $wpdb->prepare() trūkums, mysql_query() tieša lietošana.

Trūkstošās atļauju pārbaudes: AJAX apstrādātāji, kas neizsauc current_user_can() pirms jebkādu privilēģētu darbību veikšanas.

Nonce pārbaudes trūkums: veidlapu apstrādātāji, kas neizsauc wp_verify_nonce() vai check_ajax_referer().

Neattīrīta izvade (Unescaped output): echo $_GET[...], echo $user_input bez attīrīšanas funkcijām.

Ja kāds no šiem tiek atrasts, spraudnis tiek bloķēts. Lietotājs redz atskaiti, kas precīzi uzskaita, kuras funkcijas izraisīja bloķēšanu un kāpēc — ne tikai "drošības pārbaude neizdevās“.

Kā izskatās audita atskaite

Katra ģenerētā spraudnis nāk ar drošības audita atskaiti vienkāršā valodā. Tā uzskaita:

• Kuras pārbaudes tika izpildītas (zaļš)
• Kuras pārbaudes izraisīja brīdinājumus (dzintars) — problēmas, kas nav bloķējošas, bet pelna uzmanību
• Jebkuri labojumi, kas tika automātiski piemēroti dziedināšanas laikā

Atskaite tiek ģenerēta automātiski un pievienota spraudņa lejupielādei. Tā ir noderīga gan jūsu pašu pārliecībai, gan lai parādītu klientiem, ka drošību uztvērāt nopietni.

4. posms: Saglabāšanas laikā veikta validācija

Šis nav sākotnējās ģenerēšanas daļa — tas attiecas uz gadījumiem, kad lietotāji manuāli rediģē spraudņa kodu PAGEnza redaktorā.

Katru reizi, kad saglabājat, tiek palaista tā pati lint + drošības skenēšana. Ja rediģēšanas laikā ieviešat kritisku ievainojamību, saglabāšana tiks bloķēta, līdz to novērsīsit. Tas novērš izplatīto scenāriju, kurā izstrādātājs veic ātru "pagaidu" izmaiņu, kas paliek ražošanā divus gadus.

Automātiskās audita ierobežojumi

Automātiskā skenēšana labi uztver noteiktu problēmu klasi. Tā neuztver visu.

Loģiskās kļūdas, bojāta biznesa loģika un smalkas atļauju eskalācijas problēmas, kas neietver zināmus bīstamus modeļus, joprojām prasa cilvēka pārskatīšanu. Mēs esam par to caurspīdīgi dokumentācijā — audits neaizstāj drošības pārskatīšanu, tas ir minimums, kas garantē minimālo standartu.

Ražošanas spraudņiem, kas apstrādā maksājumus vai sensitīvus datus, mēs iesakām veikt manuālu pārskatīšanu papildus automatizētajām pārbaudēm. Audita atskaite sniedz cilvēkam-recenzentam labu sākumpunktu.