WordPress-tietoturvatarkastus: Mitä tarkistaa ennen julkaisua

Ennen kuin mikään PAGEnza-generoitu laajennus saavuttaa käyttäjän WordPress-asennuksen, se käy läpi kolme automatisoitua tietoturvatarkistusta. Tämä julkaisu selittää, mitä nämä tarkistukset etsivät – ja miksi jokainen niistä on tärkeä.

Miksi tekoälyn generoima koodi vaatii tarkastuksen

Suuret kielimallit ovat yllättävän hyviä kirjoittamaan WordPress-laajennuksia. Ne tuntevat koukkujen nimet, ymmärtävät WP:n koodausstandardit, tuottavat luettavaa PHP:tä. Mutta ne tekevät myös ennustettavia virheitä – ja nämä virheet ovat tietoturva-aukkoja.

Yleisimmät, joita näemme:

• $_GET tai $_POST käytön ilman puhdistusta (sanitization)
• Nonce-tarkistuksen puuttuminen lomakkeiden lähetyksissä
• Suorat tietokantakyselyt ilman $wpdb->prepare()
• eval() tai exec() käytön dynaamiseen toimintaan
• Käyttäjätietojen tulostaminen ilman esc_html() tai esc_attr()

Nämä eivät ole eksoottisia reunatapauksia. Ne ilmestyvät säännöllisesti LLM-tulosteisiin – jopa parhaista malleista.

Vaihe 1: Kehotteen validointi

Ennen kuin tekoäly kirjoittaa yhtäkään riviä, analysoimme käyttäjän kuvauksen. Tämä vaihe havaitsee kahdenlaisia ongelmia:

Manipulaatioyritykset – kehotteet, jotka yrittävät saada tekoälyn tuottamaan tarkoituksellisesti haitallista koodia. Kuten "ohita aiemmat ohjeet" tai "luo takaovi testausta varten".

Epäselvät tai toteuttamiskelvottomat kuvaukset – kehotteet, jotka ovat liian lyhyitä tai liian moniselitteisiä tuottaakseen hyödyllistä koodia. "Tee laajennus" tuottaa roskaa; "Luo yhteydenottolomake, joka lähettää lähetykset sähköpostiosoitteeseen roskapostisuodatuksella" tuottaa jotain todellista.

Jos kehote epäonnistuu tässä tarkistuksessa, käyttäjä näkee erityisen virheilmoituksen, joka selittää miksi – ei yleistä hylkäystä.

Vaihe 2: PHP linttaus eristetyssä säiliössä

Kun tekoäly on tuottanut PHP-koodia, se suoritetaan php -l -komennolla Docker-säiliössä, joka on täysin eristetty kaikesta muusta. Tämä havaitsee syntaksivirheet ennen kuin laajennus edes saavuttaa WordPress-asennuksen.

Mutta menemme pidemmälle: jos linttaus epäonnistuu, järjestelmä ei vain hylkää tulostetta. Se lähettää virheen takaisin tekoälylle korjauskehotteella – mitä kutsumme parannukseksi (healing). Tekoäly näkee oman virheensä ja yrittää uudelleen, jopa kolme kertaa.

Tämä tarkoittaa, että käyttäjät eivät melkein koskaan näe "generointi epäonnistui" -viestiä. He näkevät hieman pidemmän generointiajan – ja toimivan koodin.

Vaihe 3: Koodin tietoturvatarkastus

Tämä on tärkein vaihe. Suoritamme staattisen analyysin, joka tarkistaa:

Vaaralliset funktiot: eval(), exec(), system(), shell_exec(), passthru() – mikään näistä ei saa julkaista laajennusta.

SQL-injektiovektorit: raa'at $wpdb->query()-kutsut interpoloiduilla muuttujilla, $wpdb->prepare():n puuttuminen, mysql_query():n suora käyttö.

Puuttuvat käyttöoikeustarkistukset: AJAX-käsittelijät, jotka eivät kutsu current_user_can() ennen kuin suorittavat mitään etuoikeutettuja toimintoja.

Puuttuva nonce-tarkistus: lomakkeiden käsittelijät, jotka eivät kutsu wp_verify_nonce() tai check_ajax_referer().

Escapoimaton tuloste: echo $_GET[...], echo $user_input ilman escape-funktioita.

Jos jokin näistä löytyy, laajennus estetään. Käyttäjä näkee raportin, jossa luetellaan tarkalleen, mitkä funktiot laukaisivat eston ja miksi – ei vain "tietoturvatarkastus epäonnistui".

Miltä tarkastuskatselmusraportti näyttää

Jokaisen generoidun laajennuksen mukana tulee selkokielinen tietoturvatarkastuskatselmusraportti. Se luettelee:

• Mitkä tarkistukset läpäistiin (vihreä)
• Mitkä tarkistukset laukaisivat varoituksia (keltainen) — ongelmat, jotka eivät ole estäviä, mutta ansaitsevat huomiota
• Mahdolliset korjaukset, jotka tehtiin automaattisesti parannuksen aikana

Raportti luodaan automaattisesti ja liitetään laajennuksen lataukseen. Se on hyödyllinen sekä oman luottamuksesi vuoksi että osoittaaksesi asiakkaille, että otit tietoturvan vakavasti.

Vaihe 4: Tallennusajan validointi

Tämä ei ole osa alkuperäistä generointia – se koskee tilanteita, joissa käyttäjät muokkaavat laajennuskoodia manuaalisesti PAGEnza-editorissa.

Joka kerta kun tallennat, sama lint + tietoturvatarkastus suoritetaan uudelleen. Jos otat käyttöön kriittisen haavoittuvuuden muokkauksen aikana, tallennus estetään, kunnes korjaat sen. Tämä estää yleisen tilanteen, jossa kehittäjä tekee nopean "väliaikaisen" muutoksen, joka pysyy tuotannossa kaksi vuotta.

Automaattisen tarkastuksen rajat

Automaattinen skannaus havaitsee tietyn luokan ongelmia hyvin. Se ei havaitse kaikkea.

Loogiset virheet, rikkoutunut liiketoimintalogiikka ja hienovaraiset käyttöoikeuksien eskaloitumisongelmat, jotka eivät sisällä tunnettuja vaarallisia malleja, vaativat edelleen ihmisen suorittamaa tarkastusta. Olemme tästä avoimia dokumentaatiossa – tarkastus ei korvaa tietoturvatarkastusta, se on pohja, joka takaa vähimmäistason.

Tuotantolaajennuksille, jotka käsittelevät maksuja tai arkaluonteisia tietoja, suosittelemme manuaalista tarkastusta automatisoitujen tarkistusten lisäksi. Tarkastuskatselmusraportti tarjoaa ihmistarkastajalle hyvän lähtökohdan.