Voorkom directe toegang geüploade bestanden

[Storm90]

Ik heb deze vraag elders ook al gesteld, maar zonder reacties, dus hopelijk dat hier iemand op tweakers mij kan vertellen of dit de juiste manier is of niet.

Mijn webserver bevat een folder met bestanden, die door gebruikers van de website zijn geüpload (nog niet overigens, maar dat is de bedoeling zodra we live gaan). Ik wil voorkomen dat niet-geautoriseerde personen zomaar bestanden kunnen downloaden.

Wat ik zover heb gedaan:

Ik heb onderstaand .htaccess bestand toegevoegd aan de folder met bestanden om te voorkomen dat bestanden direct te benaderen zijn:

code:

Deny All

Maar ik moet nog wel in staat zijn een download link te genereren, waarmee de bestanden wel te downloaden zijn, dus ik heb onderstaande code getest:

PHP:

$file_url = '/uploadfolder/myfile.zip';
header('Content-Type: application/octet-stream');
header("Content-Transfer-Encoding: Binary"); 
header("Content-disposition: attachment; filename=\"" . basename($file_url) . "\""); 
readfile($file_url);

En dat lijkt prima te werken! Gezien er iets van een ID of URL wel te zien is in de front-end en ik wil voorkomen dat men deze kan manipuleren, wil ik tenslotte nog Json webtoken toepassen zodat de URL niet aan te passen is (tenzij men beschikt over de privatekey die op de server is opgeslagen, bijna onmogelijk dus )

Volgens mij is het nu wel volledig secure, maar ik zou toch graag een second opinion willen hebben. Wat denken jullie, safe? Of zie ik nog een groot veiligheidslek over het hoofd?

[Viper®]

Hoe zit het als ik als gebruiker 2 bestanden met dezelde filename upload ?

Ik ben geen web developer, maar is het niet beter om met guid's te werken en in een database de originele filename bij te houden bijvoorbeeld.

[Storm90]

Viper® schreef op maandag 16 november 2015 @ 10:49:
Hoe zit het als ik als gebruiker 2 bestanden met dezelde filename upload ?

Ik ben geen web developer, maar is het niet beter om met guid's te werken en in een database de originele filename bij te houden bijvoorbeeld.

De bestanden worden geüpload met een timestamp. We maken gebruik van een bestaand CMS, dus willen het proberen redelijk eenvoudig te houden, maar veilig! De exacte locatie wordt in de database opgeslagen, gelinkt aan een ID. Een GUID lijkt me een goede oplossing, maar dan is een implementatie bijna net zo veilig of wellicht veiliger, en eenvoudiger te implementeren nietwaar?

[Firefly III]

-

[ Voor 110% gewijzigd door Firefly III op 23-10-2016 15:08 . Reden: Leeg vanwege privacy. ]

[Storm90]

Wat ik nog mis is het eigenaarschap en de status van die geüploade bestanden op je harde schijf.

Als het goed is zijn zulke bestanden alleen te lezen/schrijven door je webserver, en door niemand uit te voeren. Als een gebruiker een eng script uploadt, mag dat niet uit te voeren zijn.

Neem aan dat je dan een chmod van 770 bedoeld?

Verder hoor je uploads buiten je webserver-root op te slaan, zodat je er vanaf het internet niet bij kan. Dus niet op www.example.com/uploadfiles/.

Dat is een goede! Die ga ik erin verwerken.

[raptorix]

Ik ben geen PHP developer, maar ik neem aan dat je in PHP een bestand kunt inlezen, en deze via een FileStream terug kan serveren, op die manier hebben gebruikers geen directe toegang tot de uploads nodig.
Hou trouwens in je code even goed rekening met security, zorg dat je functionaliteit alleen bestanden uit de upload kan downloaden! Denk aan constructies als http://www.test.com/displayfile.php?path=/config/db.config.

[Storm90]

Ik ben geen PHP developer, maar ik neem aan dat je in PHP een bestand kunt inlezen, en deze via een FileStream terug kan serveren, op die manier hebben gebruikers geen directe toegang tot de uploads nodig.

Hmmm bedankt! Ga ik eens naar kijken. Maar volgens mij is dat hetzelfde principe als mijn oplossing nietwaar?

code:

$file_url = '/uploadfolder/myfile.zip';
header('Content-Type: application/octet-stream');
header("Content-Transfer-Encoding: Binary"); 
header("Content-disposition: attachment; filename=\"" . basename($file_url) . "\""); 
readfile($file_url);

Omdat je dan niet het pad hoeft te weten, want vanuit de back-end wordt er een bestand uitgelezen en weer terug geserveerd. Ik zou dan iets van een ID kunnen geven en de back-end regelt de rest. Of werkt FileStream weer heel anders....

Hou trouwens in je code even goed rekening met security, zorg dat je functionaliteit alleen bestanden uit de upload kan downloaden! Denk aan constructies als http://www.test.com/displayfile.php?path=/config/db.config.

Dit wil ik al afvangen met JWT. Dan wordt er een hash gebruikt in de URL. Weliswaar wordt er dan een ID van het bestand meegegeven, maar als men deze probeert te veranderen is de hash ongeldig en gaat het decrypten met de private key in de back-end fout. Dus pretty safe

Bedankt voor jullie hulp zover! Ik zal alle tips meenemen bij het verbeteren van het script Ondertussen ook maar eens gekeken naar het boek The Web Application Hacker's Handbook, want volgens mij heb ik wel wat bij te spijkeren op het gebied van online security. Mocht iemand nog een ander boek aan kunnen bevelen, please let me know

[ Voor 11% gewijzigd door Storm90 op 16-11-2015 12:45 ]

[H!GHGuY]

Storm90 schreef op maandag 16 november 2015 @ 11:05:
[...]

Neem aan dat je dan een chmod van 770 bedoeld?

Help, nee!

770=
user: read, write, execute
group: read, write, execute
other: /

Dat betekent dat een bug in je webserver kan misbruikt worden om een geupload bestand uit te voeren!
Als eerste stap wil je 660, of 600/060, afhankelijk van hoe je permissie-structuur in elkaar zit.

Je zou eventueel kunnen kijken naar het volgende:
webserver proces 1, user WS1, group WS1 & download, serveert static files
webserver proces 2, user WS2, group WS2 & upload, serveert de rest en handlet te upload
klein tooltje, user WS2, group upload & download, verplaatst files van upload dir naar download dir

dir-structuur:
files/upload
files/download

webserver 2 heeft 200 access op upload-directory, dus write-only. Schrijft files gewoon in de dir, en zet rechten van files op WS2/upload 000.
tooltje pikt (via inotify bvb) de files op, maakt ze WS1/download 040 (read-only) en zet ze in de download dir.
Vervolgens kan webserver 1 de file aanbieden.

tooltje kun je met CAP_CHOWN zegenen zodat hij de nodige operaties kan doen op een 000 file.

Goedbedoeld, maar als je dit soort vragen met deze aangetoonde kennis hier komt vragen: huur een professional. Het enige wat je nu doet is schijnveiligheid creëren.

[ Voor 6% gewijzigd door H!GHGuY op 16-11-2015 12:58 ]

[Storm90]

Achja 660, my bad! Bedankt voor je uitgebreide response!

Ik ga jouw methode eens goed overwegen. En zodra het een top prioriteit wordt dat het systeem helemaal potdicht moet zitten zullen we zeker een professional inhuren.

Ik kan wel moeilijk begrijpen waarom jouw methode zoveel veiliger is dan gebruikers gewoon te laten schrijven/lezen van eenzelfde folder? Tenslotte kunnen ze dan al schrijven naar een folder, en welke bestanden ze mogen downloaden wordt bepaald in de back-end. Dus waarom is het dan extra veilig downloads naar een aparte folder te verplaatsen? Om mogelijke modificatie van bestanden te voorkomen, is het enige wat ik me kan bedenken?

[ Voor 43% gewijzigd door Storm90 op 16-11-2015 13:38 ]

[H!GHGuY]

Storm90 schreef op maandag 16 november 2015 @ 13:31:
Achja 660, my bad! Bedankt voor je uitgebreide response!

Ik ga jouw methode eens goed overwegen. En zodra het een top prioriteit wordt dat het systeem helemaal potdicht moet zitten zullen we zeker een professional inhuren.

Ik kan wel moeilijk begrijpen waarom jouw methode zoveel veiliger is dan gebruikers gewoon te laten schrijven/lezen van eenzelfde folder? Tenslotte kunnen ze dan al schrijven naar een folder, en welke bestanden ze mogen downloaden wordt bepaald in de back-end. Dus waarom is het dan extra veilig downloads naar een aparte folder te verplaatsen? Om mogelijke modificatie van bestanden te voorkomen, is het enige wat ik me kan bedenken?

Jij ziet het probleem niet omdat je uitgaat van veilige en foutloze software.
Hoeveel componenten moeten een fout bevatten vooraleer er in het oorspronkelijke geval problemen ontstaan met het proces van uploaded files beschikbaar stellen? Hoeveel componenten moeten er een fout bevatten vooraleer het in mijn opzet fout gaat?

Maar om ook even nog wat beter de educeren, de principes die hier toegepast zijn zijn gewoon die van het 'principle of least privilege', gecombineerd met het "principle of single responsibility".
Beide zijn goed google-bare zoektermen waar je best verder mee komt. Er zijn ongetwijfeld nog andere oplossingen (zoniet betere?!), maar ongetwijfeld zullen ze allemaal in een of andere vorm deze 2 principes toepassen. En waarschijnlijk nog wel enkele andere ook.

[ Voor 17% gewijzigd door H!GHGuY op 16-11-2015 22:14 ]

[Hydra]

Als het niet de bedoeling is dat die bestanden te direct te downloaden zijn waarom sla je ze dan uberhaupt in de document root op? Beetje suf om dat via .htaccess te regelen als ze gewoon buiten de doc root opslaan veel simpeler is.