WordPressi turbeaudit: Mida kontrollida enne avaldamist

Enne kui PAGEnza poolt genereeritud pistikprogramm jõuab kasutaja WordPressi installatsiooni, läbib see kolm automatiseeritud turvakontrolli. See postitus selgitab, mida need kontrollid otsivad – ja miks igaüks neist on oluline.

Miks AI-ga genereeritud kood vajab auditit

Suured keelemudelid on üllatavalt head WordPressi pistikprogrammide kirjutamisel. Nad tunnevad konksude (hooks) nimesid, mõistavad WP kodeerimisstandardeid, toodavad loetavat PHP-d. Kuid nad teevad ka ettearvatavaid vigu – ja need vead on turvaauke.

Kõige sagedasemad, mida näeme:

• $_GET või $_POST kasutamine ilma puhastamiseta (sanitization)
• Nonce'i kontrolli puudumine vormide esitamisel
• Otsesed andmebaasipäringud ilma $wpdb->prepare()-ta
• eval() või exec() kasutamine dünaamiliseks käitumiseks
• Kasutajaandmete väljastamine ilma esc_html() või esc_attr()-ta

Need ei ole eksootilised erijuhud. Need ilmuvad regulaarselt LLM-i väljundis – isegi parimatest mudelitest.

Etapp 1: Käsu (Prompt) valideerimine

Enne kui AI kirjutab ühegi rea, analüüsime kasutaja kirjeldust. See samm tuvastab kahte tüüpi probleeme:

Manipulatsioonikatsed – käsud, mis üritavad panna AI-d tahtlikult pahatahtlikku koodi tootma. Asjad nagu „ignoreeri eelnevaid juhiseid“ või „loo testiks tagauks“.

Ebamäärased või teostamatud kirjeldused – käsud, mis on liiga lühikesed või liiga mitmetähenduslikud, et toota kasulikku koodi. „Tee pistikprogramm“ toodab prahti; „Loo kontaktvorm, mis saadab esitused rämpspostifiltriga e-posti aadressile“ toodab midagi reaalset.

Kui käsk selle kontrolli ei läbi, näeb kasutaja konkreetset veateadet, mis selgitab miks – mitte üldist tagasilükkamist.

Etapp 2: PHP lintimine isoleeritud konteineris

Kui AI on PHP koodi genereerinud, täidetakse see php -l abil Docker-konteineris, mis on täielikult isoleeritud kõigest muust. See tuvastab süntaksivead enne, kui pistikprogramm üldse WordPressi installatsiooni jõuab.

Kuid me läheme kaugemale: kui lintimine ebaõnnestub, ei lükka süsteem väljundit lihtsalt tagasi. See saadab vea tagasi AI-le paranduskomandoga – mida me nimetame parandamiseks (healing). AI näeb oma viga ja proovib uuesti, kuni kolm korda.

See tähendab, et kasutajad peaaegu kunagi ei näe „generimine ebaõnnestus“ sõnumit. Nad näevad veidi pikemat genereerimisaega – ja töötavat koodi.

Etapp 3: Koodi turvakontroll

See on kõige olulisem etapp. Käivitame staatilise analüüsi, mis kontrollib:

Ohtlikud funktsioonid: eval(), exec(), system(), shell_exec(), passthru() – mis tahes neist blokeerib pistikprogrammi väljalaskmise.

SQL-i süstimise vektorid: $wpdb->query() toored väljakutsed interpolatsioonimuutujatega, $wpdb->prepare() puudumine, mysql_query() otsene kasutamine.

Puuduvad õiguste kontrollid: AJAX-käitlejad, mis ei kutsu current_user_can() enne mis tahes privileegitud toimingu sooritamist.

Puuduv Nonce'i kontroll: vormitöötlused, mis ei kutsu wp_verify_nonce() või check_ajax_referer().

Puhastamata väljund: echo $_GET[...], echo $user_input ilma puhastusfunktsioonideta.

Kui mõni neist leitakse, blokeeritakse pistikprogramm. Kasutaja näeb aruannet, mis täpselt loetleb, millised funktsioonid blokeeringu käivitasid ja miks – mitte ainult „turvakontroll ebaõnnestus“.

Kuidas auditiaruanne välja näeb

Iga genereeritud pistikprogrammiga kaasneb selgesõnaline turbeauditi aruanne. See loetleb:

• Millised kontrollid läbisid (roheline)
• Millised kontrollid käivitasid hoiatusi (kollane) — probleemid, mis ei ole blokeerivad, kuid väärivad tähelepanu
• Parandused, mida parandamise ajal automaatselt rakendati

Aruanne genereeritakse automaatselt ja lisatakse pistikprogrammi allalaadimisele. See on kasulik nii teie enda kindlustunde suurendamiseks kui ka klientidele näitamiseks, et võtsite turvalisuse tõsiselt.

Etapp 4: Salvestamisel valideerimine

See ei ole osa esialgsest genereerimisest — see kehtib siis, kui kasutajad redigeerivad pistikprogrammi koodi käsitsi PAGEnza redigeerijas.

Iga kord, kui salvestate, käivitatakse uuesti sama lint + turvakontroll. Kui tutvustate redigeerimise ajal kriitilise haavatavuse, blokeeritakse salvestamine, kuni te selle parandate. See takistab tavalist stsenaariumi, kus arendaja teeb kiire "ajutise" muudatuse, mis jääb tootmisse kaheks aastaks.

Automaatse auditi piirangud

Automaatne skannimine tuvastab teatud tüüpi probleeme hästi. See ei tuvasta kõike.

Loogikavead, rikutud ärireeglid ja peened õiguste eskaleerimise probleemid, mis ei hõlma teadaolevaid ohtlikke mustreid, nõuavad endiselt inimlikku ülevaadet. Oleme selles dokumentatsioonis läbipaistvad — audit ei asenda turbeülevaadet, see on alus, mis tagab miinimumnormi.

Makseid või tundlikke andmeid töötlevate tootmispistikprogrammide puhul soovitame lisaks automatiseeritud kontrollidele ka käsitsi ülevaadet. Auditiaruanne pakub inimülevaatajale head lähtepunkti.