Veilige bestandsupload in PHP: ontwerp van begin tot eind

Een veilige bestandsupload in PHP bestaat niet uit het accepteren van een formulier en het verplaatsen van een bestand naar de server. Een bijlage kan een manier worden om code uit te voeren, een informatielek, een belasting die resources uitput of een document dat ontoegankelijk is wanneer het bedrijfsproces het nodig heeft. Het ontwerp moet de volledige levenscyclus omvatten: ontvangst, validatie, opslag, verwerking, toegangsautorisatie, auditing en verwijdering.

Definieer het bedrijfscontract voordat u bestanden accepteert

De eerste controle is niet technisch: beperk welke behoefte elke bijlage oplost. Een identiteitsbewijs, een factuur en een profielfoto hebben verschillende formaten, eigenaars, bewaartermijnen en inzagerechten. Ze onderbrengen onder een generieke optie om een bestand te uploaden maakt het moeilijker om passende controles toe te passen.

Definieer voor elk documenttype een expliciet contract:

• Welke formaten nodig zijn en welke uitgesloten worden.
• De maximale grootte, het maximale aantal bijlagen per bewerking en de cumulatieve quota per account of dossier.
• Wie het kan uploaden, in welke processtatus en of diegene het kan vervangen of verwijderen.
• Welke automatische validatie en welke menselijke beoordeling nodig zijn.
• Wie het kan bekijken, downloaden of een nieuwe versie kan aanvragen.
• Hoe lang het wordt bewaard en welke gebeurtenis de verwijdering activeert.

Dit contract voorkomt dat bestanden worden geaccepteerd «voor het geval dat». Het maakt het ook mogelijk om een validatiefout, die de gebruiker kan corrigeren, te onderscheiden van een bedrijfsbeperking, zoals proberen een document toe te voegen wanneer het dossier al gesloten is.

Waarom extensie en opgegeven type niet volstaan

De extensie van de oorspronkelijke naam en het type dat in $_FILES['type'] wordt verzonden, zijn gegevens die door de client worden aangeleverd. Ze dienen als aanvullende interface-informatie, maar bewijzen de inhoud niet. Een bestand hernoemen is triviaal en een client kan willekeurige HTTP-headers verzenden.

De technische validatie moet gebruikmaken van meerlaagse verdediging. Detecteer in PHP het type op basis van de ontvangen bytes met mechanismen zoals finfo; pas vervolgens formatspecifieke validators toe wanneer het risico of het gebruik dat vereist. Voor een afbeelding die getoond zal worden, volstaat het niet om deze als afbeelding te identificeren: het is raadzaam om haar te decoderen met een geschikte bibliotheek en een nieuwe representatie te genereren. Valideer voor een PDF of een kantoordocument de verwachte structuur met gespecialiseerde tools in een geïsoleerde omgeving.

Een toelatingslijst is veiliger dan een blokkeerlijst. Als de toepassing JPEG en PNG toestaat, wijs dan al het overige af in plaats van gevaarlijke formaten te proberen opsommen. Gecomprimeerde bestanden vereisen een aanvullende controle: een limiet voor de gecomprimeerde grootte beperkt de expansie bij het uitpakken niet. Stel limieten in voor de uitgepakte grootte, het aantal items, de nestingdiepte en de analysetijd.

Ook namen zijn niet betrouwbaar. Gebruik ze niet als pad, identificator of fysieke naam. Reeksen zoals ../, besturingstekens, dubbele extensies en naamconflicten moeten irrelevant worden doordat het systeem zijn eigen ondoorzichtige identificator genereert.

Gecontroleerde ontvangst en afhandeling van gedeeltelijke fouten

Beperk het invoeroppervlak voordat u de inhoud verwerkt. Configureer consistente limieten in PHP, de webserver en de reverse proxy. Als de proxy 100 MB accepteert maar PHP 10 MB toestaat, zal het gedrag verwarrend zijn; als PHP meer toestaat dan voorzien, kan een aanvaller geheugen, tijdelijke schijfruimte of werkverbindingen verbruiken.

Controleer expliciet de individuele grootte, het totaal van het verzoek, het aantal bestanden en de uploadduur. Controleer de foutcode van elke invoer in $_FILES, verifieer dat deze afkomstig is van een HTTP-upload en behandel elke bijlage als een onafhankelijke eenheid. Bepaal bij een meervoudige bewerking vooraf of het resultaat atomair of gedeeltelijk is. Als gedeeltelijke resultaten worden geaccepteerd, moet het antwoord nauwkeurig aangeven welk bestand is ontvangen, welk is afgewezen en waarom, zonder interne serverdetails prijs te geven.

Verwerk een bestand niet rechtstreeks vanaf een pad dat door het verzoek wordt beheerd en vertrouw er niet op dat een onderbroken upload onschadelijk is. Onvolledige tijdelijke bestanden moeten worden opgeruimd en herpogingen moeten idempotent zijn wanneer het product deze ondersteunt. Een bewerkingstoken of een idempotentiesleutel voorkomt dat na herverzendingen via het netwerk meerdere equivalente bijlagen worden aangemaakt.

Privéopslag, quarantaine en verwerking

De binaire bestanden mogen niet onder de publieke directory van de applicatie terechtkomen. Sla ze op in privéopslag, met toegangsgegevens met minimale rechten, en koppel elk object aan een door het systeem gegenereerde interne identificator. De database kan metadata bewaren zoals eigenaar, bedrijfscontext, gedetecteerd type, grootte, cryptografische hash, status, datums en retentiebeleid. Vermijd het opslaan van onnodige persoonsgegevens in de naam of operationele logs.

Een robuust proces scheidt ontvangst en beschikbaarheid:

1. De applicatie ontvangt het bestand en maakt een registratie aan met de status pendiente of en_cuarentena.
2. Het binaire bestand wordt geplaatst op een locatie die niet toegankelijk is voor downloads.
3. Een asynchroon proces voert antimalwareanalyse, diepgaande validatie, transformatie of toegestane extractie uit.
4. Het resultaat wijzigt in disponible, rechazado of requiere_revision.
5. De interface toont de operationele status zonder voor te doen dat een upload al bruikbaar is.

Wachtrijen verkorten de responstijd, maar introduceren eigen fouten: dubbele taken, vertraagde berichten en uitgevallen verwerkingsprocessen. Ontwerp idempotente taken, herpogingslimieten, waarschuwingen voor vastgelopen elementen en een gecontroleerd herverwerkingspad. Als de analyse niet beschikbaar is, is het veilige alternatief doorgaans om de bijlage in quarantaine te houden, niet om haar te publiceren.

Autoriseer elke download en lever inhoud zonder deze uit te voeren

Het kennen van een identificator verleent niemand toegang. Elke download moet de geauthenticeerde identiteit, de huidige relatie met de resource en de bedrijfscontext controleren: lidmaatschap van een organisatie, toewijzing aan het dossier, actuele rol, documentstatus en tijdelijke beperkingen. Hergebruik niet de autorisatie die bestond toen het bestand werd geüpload; rechten kunnen daarna zijn ingetrokken.

De download moet via een controller verlopen die deze beslissing toepast voordat het object wordt gelezen of gedelegeerd. Ondertekende URL's kunnen nuttig zijn voor levering vanuit externe opslag, maar vereisen een beperkte reikwijdte, korte vervaltijd en controles die voorkomen dat ze worden uitgegeven voor niet-geautoriseerde resources.

Lever actieve typen voorzichtig. Gebruik voor documenten die niet bedoeld zijn om in de browser te worden gerenderd Content-Disposition: attachment. Stel het contenttype in op basis van het gevalideerde type, niet van de extensie, en voeg X-Content-Type-Options: nosniff toe. Een voorvertoning is niet simpelweg een ingebedde download: deze moet getransformeerde representaties gebruiken, potentieel actieve inhoud isoleren en voorkomen dat interne paden worden onthuld.

Auditing, herstel en tests vóór productie

Registreer relevante gebeurtenissen: aanmaak, vervanging, statuswijziging, download, verwijdering, analysefout en wijziging van rechten. Het log moet actor, tijdstip, resource en resultaat bevatten, maar hoeft het binaire bestand of gedupliceerde gevoelige gegevens niet op te slaan. Bescherm deze gebeurtenissen tegen wijzigingen en bepaal wie ze mag raadplegen.

Herstel vereist dat bekend is wat er gebeurt als de opslag, de database of het verwerkingsproces faalt. Markeer een document pas als beschikbaar wanneer het binaire bestand en de metadata consistent zijn. Ontwerp reconciliatietaken om registraties zonder object, verweesde objecten en elementen die te lang in quarantaine blijven te detecteren.

Checklist voor vrijgave

• De toegestane formaten beantwoorden aan een gedocumenteerd gebruiksdoel en worden op inhoud gevalideerd.
• Er zijn limieten voor grootte, aantal, tijd en expansie van gecomprimeerde bestanden.
• De oorspronkelijke namen bepalen geen paden of fysieke namen.
• De binaire bestanden worden buiten de publieke directory opgeslagen en gaan waar van toepassing door quarantaine.
• De download evalueert de autorisatie opnieuw en stelt geen interne paden bloot.
• Er worden tests uitgevoerd met slecht gevormde bestanden, duplicaten, onderbroken uploads, ingetrokken rechten en opslagfouten.
• Er is monitoring van afwijzingen, vastgelopen taken, leveringsfouten en verbruikte capaciteit.
• Het retentie-, verwijderings- en auditbeleid heeft een operationeel verantwoordelijke.

Een upload omzetten in een proces met statussen en controles kan duurder lijken dan een uploadmap gebruiken. Toch vermindert het geïmproviseerde beslissingen wanneer er een verdacht bestand, een toegangsclaim of een operationele onderbreking optreedt. Die traceerbaarheid maakt deel uit van het product en is geen latere toevoeging.