AI-code: Snel, makkelijk, onveilig?

Experiment 1

Tijdens de initiële prompt hebben we ons bewust niet beziggehouden met security. In deze fase wilden we onderzoeken of je de AI naar een veilige applicatie kunt sturen zonder dat je kennis hebt van specifieke kwetsbaarheden. Met onze naïeve houding nog steeds in stand, stelden we de volgende vraag:

"A friend of mine checked the code and said it is very insecure. Can you fix all security vulnerabilities and make it extremely safe?"

Na deze aanpassing hebben we de functionaliteit en de eerder gevonden kwetsbaarheden opnieuw gecontroleerd. De AI heeft de volgende aanpassingen gemaakt:

• Brute-force bescherming: De applicatie blokkeert nu IP-adressen na 10 foutieve inlogpogingen. Hoewel dit een verbetering is, blijft deze methode eenvoudig te omzeilen via een VPN of proxy.
• XSS: De standaardbeveiliging van het framework werd hersteld, waardoor de eerder gevraagde opmaak (dikgedrukte tekst) niet meer werkte. Pas nadat we de AI op deze fout wezen, werd er overgeschakeld op output sanitization.
• Factuur URL’s: Facturen zijn nu beveiligd met een combinatie van het oorspronkelijke ID en een GUID. Dit maakt het raden van URL's aanzienlijk moeilijker.
• Bestandsuploads: Er vindt nu een controle plaats op het MIME-type. Bij een onbekende extensie vervangt de applicatie deze automatisch door .png.
• CSRF: In eerste instantie voegde de AI CSRF-bescherming toe. Echter, nadat de applicatie herhaaldelijk niet meer wilde opstarten, koos de AI ervoor om de volledige bescherming weer te verwijderen om de app werkend te krijgen.
• Verouderde software: Er zijn geen updates uitgevoerd voor Node of NPM. Sterker nog: de AI voegde een nieuw pakket toe dat een publiekelijk bekende kwetsbaarheid bevat.
• Security headers: Er zijn drie basis-security headers toegevoegd om de browserbeveiliging te verbeteren.

Experiment 2

In het volgende experiment namen we opnieuw de basisversie van de applicatie als startpunt - de versie zonder enige beveiligingsupdates. Dit keer zetten we onze naïeve houding opzij. In plaats van een vage hulpvraag, gaven we de AI specifieke instructies over de aanwezige kwetsbaarheden.

Hierbij lieten we bewust in het midden hoe de kwetsbaarheid opgelost moest worden; we wezen enkel het probleem aan. Voor de ontbrekende brute-force bescherming gebruikten we bijvoorbeeld de prompt:

"The login is vulnerable to brute force, fix that."

Vervolgens hebben we gecontroleerd of de AI, wanneer hij gericht op een probleem wordt gewezen, wel met de juiste technische oplossingen komt. De resultaten van deze aanpak waren als volgt:

• Brute-force bescherming: De applicatie blokkeert pogingen nu op basis van een combinatie van inlognaam en IP-adres. Hoewel dit de drempel verhoogt, blijft omzeiling via een VPN of proxy nog steeds mogelijk.
• XSS: De AI schreef een eigen sanitizeHTML-functie. Deze functie is echter erg basaal, waardoor de bescherming relatief eenvoudig te omzeilen blijft met meer geavanceerde payloads.
• Factuur URL’s: Er werd gekozen voor een oplossing vergelijkbaar met het vorige experiment. In plaats van een GUID voegt de AI nu een willekeurige string van 64 karakters toe aan de URL, wat enumeratie effectief voorkomt.
• Bestandsuploads: De beveiliging is aanzienlijk aangescherpt. De AI controleert nu op MIME-type, extensie en de magic bytes van het bestand. Als een van deze waarden niet overeenkomt, wordt het verzoek geweigerd.
• CSRF: De AI bouwde een eigen CSRF-bescherming middels middleware die op alle POST-verzoeken wordt toegepast.
• Verouderde software: Alle gebruikte software is bijgewerkt naar de meest recente versies, inclusief de Node-omgeving, NPM en alle dependencies.
• Security headers: Voor het zetten van de headers werd het pakket helmet geïnstalleerd. Dit zorgde echter voor een conflict: de Content Security Policy (CSP) blokkeerde de opmaak in de facturen. Nadat we de AI vroegen dit op te lossen, werden de waarden 'unsafe-inline' en 'unsafe-eval' toegevoegd, wat de effectiviteit van de CSP-header grotendeels tenietdoet.

Experiment 3

Tot nu toe hebben we de AI elke keer de autonomie gegeven om zelf oplosssingen te bedenken. In het laatste experiment bekijken we hoe de AI oplossingen implementeert wanneer de oplossing ook gegeven is.

• Brute-force bescherming: Op ons verzoek om gebruikers te blokkeren na tien foutieve inlogpogingen binnen een kwartier, implementeerde de AI exact deze logica.
• XSS: We instrueerden de AI om DOMPurifier te gebruiken en alle HTML-tags te strippen, met uitzondering van <i>, <b>, <ul> en <ol>. Ook hier werd de instructie nauwgezet opgevolgd.
• Factuur URL's: De AI kreeg de opdracht om een cryptografisch veilig token van 32 bytes toe te voegen aan factuur-URL's. Verzoeken waarbij dit token niet overeenkomt met de database, moeten worden geweigerd. De AI voerde dit zonder haperen uit.
• Bestandsuploads: We stelden strikte eisen aan bestandsuploads: alleen .png, .jpeg en .jpg zijn toegestaan. Daarnaast voegde de AI op ons verzoek een controle toe op het MIME-type. Bij een mismatch tussen de extensie en het MIME-type wordt het verzoek geweigerd en direct gelogd.
• CSRF: Ook zonder hulp van externe libraries slaagde de AI erin om handmatig CSRF-tokens te genereren en te valideren voor alle non-GET-verzoeken.
• Verouderde software: Het updaten van NodeJS, NPM en diverse project-dependencies naar de laatste versies verliep volledig probleemloos.
• Security headers: Dit bleek het enige struikelblok. Vanwege een rich-text editor met inline JavaScript liep de AI aanvankelijk vast op de Content Security Policy (CSP). Na 20 minuten vruchteloos proberen, gaven we de instructie om tijdelijk de (onveilige) unsafe-inline te gebruiken, wat direct werd uitgevoerd. Om de veiligheid vervolgens weer op niveau te krijgen, vroegen we de AI de unsafe-inline te vervangen door een nonce. Deze complexere aanpassing werd daarna snel en correct doorgevoerd.