Filuppladdning i AI-kod: filändelsen räcker inte

Ett trovärdigt kodförslag med ett hål i mitten

Anta att en kodassistent föreslår följande pseudokod för ett profilfoto. Den är avsiktligt förenklad och ska läsas som en granskningsskiss, inte som en implementation att köra. Funktionen kontrollerar filnamnets slut och använder sedan samma namn när filen sparas i en katalog som webbservern kan läsa:

function upload(file, user) {
  if (!file.name.endsWith('.png')) return reject('Fel filtyp');
  save('/public/uploads/' + file.name, file.bytes);
  return '/uploads/' + file.name;
}

Frågan i kodgranskningen är inte om endsWith fungerar för strängen foto.png. Frågan är vad som händer med en fil vars namn ser rätt ut men vars innehåll inte är en bild, med ett namn som påverkar lagringsvägen, med en för stor kropp eller med en fil som blir direkt tillgänglig efter uppladdning. OWASP skiljer mellan risker i metadata, såsom namn och sökväg, och risker i innehåll eller storlek. Effekten beror på hur appen bearbetar och lämnar ut filen i nästa steg (OWASP, Unrestricted File Upload).

Exemplet säger heller inget om vem som får ladda upp eller se filen. Det kan inte avgöras från denna funktion om ett yttre lager redan stoppar obehöriga. Be därför om bevis från faktisk routning och behörighetskontroll, inte ett antagande i kodkommentaren. Vår bredare säkerhetsgranskning av en AI-byggd kodbas visar hur du inventerar sådana gränser; här följer vi just filens väg.

Skilj ändelse, MIME och signatur åt

Börja med att skriva ner vilka format produkten faktiskt behöver. Om profilfoto bara behöver PNG ska en allowlist för PNG vara tydlig; lägg inte till andra format som råkar fungera i testmiljön. Normalisera och avkoda filnamnet innan ändelsen bedöms. OWASP nämner dubbeländelser, skiftläge och tecken som kan förändras vid tolkning som exempel på varför en enkel strängkontroll är svag. Låt inte originalnamnet bli serverns lagringsnamn bara för att ändelsen godkändes.

Klientens Content-Type, ofta kallad MIME-typ i granskningar, är en uppgift i begäran. Den kan jämföras med det förväntade formatet för att fånga misstag, men OWASP påpekar att avsändaren kan förfalska den. En filsignatur, bytes i början av filen, ger ett annat slags kontroll. OWASP säger uttryckligen att signaturkontroll inte ska användas ensam eftersom den kan kringgås. Varken ett matchande MIME-värde eller en matchande signatur intygar att resten av filen är ofarlig eller ens att den går att bearbeta som avsett.

För en bild bör granskningsfrågan därför vara: kan den bildparser som appen använder faktiskt avkoda filen inom rimliga resursgränser, och skapas en kontrollerad representation innan filen visas för andra? OWASP tar upp innehållsvalidering och bildomskrivning som möjliga lager, samt skanning eller isolerad bearbetning där behovet motiverar det. Valet beror på format, bibliotek och användning; det är inget universellt recept. Dokumentera vad parsern accepterar och vilka filer som avvisas.

Följ namn, storlek och plats efter kontrollen

Be kodassistenten visa var filnamnet kommer ifrån och var det används. Ett användarvalt namn ska inte kunna styra lagringsvägen eller skriva över en annan fil. OWASP rekommenderar ett applikationsgenererat namn och gränser för längd och tecken om originalnamnet alls behöver behållas. Spara i så fall originalnamnet som separata visningsdata och behandla det som användarindata också när det visas senare. Ett servervalt ID gör det lättare att mappa en godkänd hämtning till rätt fil.

Bestäm en storleksgräns för programmets behov och kontrollera den i den inkommande begäran och efter eventuell avkodning eller uppackning. Ett vanligt foto och en orimligt stor fil ska ge olika utfall. OWASP kopplar storleksgränsen till lagringskapacitet och påminner om att bearbetad eller uppackad storlek kan skilja sig från det som först laddades upp. För ett PNG-flöde behövs ett beslut om bilddimensioner och parserns resursgränser utöver gränsen för begärans antal byte.

Lagringsplatsen är ett eget beslut. OWASP föredrar separat värd eller lagring utanför webbrot, med snäva filsystemrättigheter. Om appen erbjuder nedladdning behöver en kontrollerad hämtningsrutt kontrollera vem som får se filen och vilket innehåll som lämnas ut. En publik URL direkt till den ursprungliga uppladdningen tar bort den kontrollpunkten. Granska också vem som får anropa uppladdningsvägen och vilket CSRF-skydd webbgränssnittet använder. Artikeln om ägarkontroll är en fördjupning om varför ett giltigt konto inte automatiskt ger rätt till någon annans objekt.

Två prov som visar vad ändringen gör

Negativt prov: ta en ofarlig textfil med innehållet ”prov, ingen bild”, döp kopian till foto.png och skicka den genom samma uppladdningsväg som en användare använder. Den ska avvisas utan att sparas eller bli åtkomlig via hämtningsvägen. Om skissen ovan accepterar den visar provet exakt vilken kontroll som saknas: ändelsen godkänns, medan innehållet inte granskas. Det är en demonstration av ett saknat lager, inte ett påstående om att en viss server kan utnyttjas.

Positivt prov: ladda upp en liten, giltig PNG som appen själv eller en känd bildredigerare har skapat. Den ska accepteras, få ett servervalt lagringsnamn och kunna hämtas av en behörig användare genom den avsedda vägen. Kontrollera samtidigt att ett obehörigt konto inte kan läsa den om filen ska vara privat. Ett negativt prov utan ett positivt kan lura teamet att tro att en funktion som avvisar allt är klar.

Komplettera vid kodgranskningen med en fil över den beslutade storleksgränsen och ett ovanligt långt originalnamn. De ska ge kontrollerade fel utan kvarlämnad fil. Kör proven i en isolerad testmiljö med syntetiska filer. Skriv ner faktisk begäran, svarskod, om något sparades och om hämtning gick att göra. Samma struktur i guiden till Playwright Trace Viewer hjälper när ett UI döljer vilket anrop som skickades, men själva filkontrollen ska verifieras på servern.

Lämna ett beslut med ägare och rest

Avsluta granskningen med en rad per kontroll: vad koden gör, vilket prov som visar det, och vem som äger det som återstår. En rimlig granskningskommentar kan säga: ”Ändelsen begränsas till PNG, men jag hittar ingen kontroll av avkodbart bildinnehåll, ingen storleksgräns och inget servervalt lagringsnamn. Låt oss lägga till de lagren och visa ett avvisat textfilprov samt ett godkänt PNG-prov innan ändringen slås ihop.” Det är mer användbart än att märka hela funktionen ”osäker” utan konkret nästa steg.

Även efter godkända prov återstår risk i parsern, lagringsmiljön och den framtida hämtningsvägen. OWASP:s poäng är försvar i flera lager; MIME eller filsignatur ger inte full säkerhet när de kombineras med ett par tester. Sätt därför en ägare för bibliotek, konfigurering, loggning och återkommande granskning när filtypen eller användningen ändras.