Upload folder afschermen

[Goodfellas]

Goede avond,

Ik werk aan een website waar gebruikers kunnen inloggen (mysql, sessies) en daarna bestanden downloaden.

Aan de achterkant zit gebruikersbeheer en versiebeheer (de downloads dus). Omdat ik de bestanden maar 1 keer per gebruiker wil aanbieden en bijhouden wie welke versies(s) download gebruik ik een script om de downloads aan te bieden (php readfile) en de downloads op te slaan (mysql). So far, so good.

Maar nu komt het: de bestanden die ik aan bied mogen niet rechtstreeks te downloaden zijn (dat als je toevallig de link weet dat je dan mijn script kunt omzeilen). Het script moet dus rechten hebben om het bestand aan te bieden, maar eigenlijk wil ik gebruikers helemaal geen rechten geven in de uploads directory.

Chmod rechten ontnemen werkt niet want dan werkt mijn script niet meer. De uploads folder staat in de www folder (dus httpdocs/uploads). Het is niet mijn server maar ik kan wel htaccess plaatsen.

Kan iemand me verder helpen?

[alex3305]

Laten downloaden via een PHP script op basis van sessie id. Daarnaast kun je de user 'server' waarschijnlijk wel alle rechten geven en dan de user (van buitenaf) geen rechten, zodoende kan je de bestanden wel aan via PHP, maar niet direct.

[Matis]

Als je de bestanden buiten jouw documentroot plaatst en middels PHP script/site doorstuurt aan de browser, zouden ze nooit buiten het PHP script om het bestand kunnen downloaden.

[leuk_he]

Neem aan dat er een of andere scripting tussen zit zoiets...

http://www.finalwebsites.com/forums/topic/php-file-download


Dan regel je toch in de webserver dat de directory waar de file in staat niet via de webserver geshared wordt, maar enkel via het php script. Dus niet met chmod maar met .htaccess ("deny from all" lijkt me afdoende)

[Matis]

leuk_he schreef op woensdag 13 juli 2011 @ 22:42:
Dan regel je toch in de webserver dat de directory waar de file in staat niet via de webserver geshared wordt, maar enkel via het php script. Dus niet met chmod maar met .htaccess ("deny from all" lijkt me afdoende)

Voorbeeldje: http://www.ryboe.com/tuto...files-with-htaccess-rules

Bovenstaande kun je eventueel combineren met het volgende: http://www.ryboe.com/tutorials/php-headers-force-download
Ik weet niet of jouw bestanden een specifieke extensie hebben (zip, pdf, jpg), maar anders zou je ook nog een stukje logica moeten bouwen, om de juiste content-type te serveren

[ Voor 26% gewijzigd door Matis op 13-07-2011 22:47 ]

[Goodfellas]

Bedankt voor de snelle reacties! Ik gebruik inderdaad header force download icm readfile, content type is geen issue, gebruik oa deze header en dat werkt voor alle bestandstypen:

header('Content-Type: application/octet-stream');

Morgen ga ik een htaccess instellen en kijken of dat voldoende resultaat oplevert. Vanmiddag heb ik daarmee zitten rommelen maar toen lukte het me niet helemaal. Misschien sowieso slim om de uploads buiten de documentroot te plaatsen, gewoon voor de zekerheid

[NMe]

Je hebt niet eens per se .htaccess nodig. Je hebt doorgaans een public_html-directory, maar daarnaast ook een private_html. Die is sowieso al niet benaderbaar via de browser.

[8088]

publich_html private_html wordt in shared omgevingen doorgaans gebruikt voor https content.

[ Voor 14% gewijzigd door 8088 op 14-07-2011 02:37 . Reden: argh ]

[NMe]

8088 schreef op donderdag 14 juli 2011 @ 02:09:
public_html wordt in shared omgevingen doorgaans gebruikt voor https content.

Ik neem aan dat je daar private_html bedoelde.

Nouja, meestal kun je ook gewoon zelf mappen aanmaken op dat niveau in de directory tree. Het gaat er in elk geval om dat ik het sowieso altijd buiten de webroot zou plaatsen. Als je het binnen de webroot hebt en beveiligt met .htaccess heb je kans dat je bij een migratie of het terugzetten van een backup de .htaccess vergeet en daarmee een open dir maakt of de bestanden gewoon zo beschikbaar zet, lijkt me niet handig.

[Verwijderd]

Inderdaad, uitgaande van een map buiten de docroot kun je als het goed is het volgende doen:

PHP:

$path = Config::get('private_file_path') . DIRECTORY_SEPERATOR . basename($_GET['file']);
if(!is_file($path) || !is_readable($path)) {
 // error
}

header('Content-Type: application/octet-stream');
header('Content-Length: ' . filesize($path));
readfile($path);

Helaas is filesize vanwege 32-bit signed integers (zelfs op 64-bit platformen volgens mij) beperkt tot 2GiB, je kunt dit eventueel ophogen naar 4GiB door

code:

filesize($path)

te vervangen door

code:

sprintf("%u", filesize($path))

.

[ Voor 29% gewijzigd door Verwijderd op 14-07-2011 09:22 ]

[Goodfellas]

Deze fantastische hoster (van klant, zelf niet gekozen natuurlijk), staat het mij niet toe om bestanden buiten /httpdocs/ te zetten. Linken naar een directory hoger (bijvoorbeeld private) gaat simpelweg niet en ik mag op dat niveau ook geen mappen aanmaken.

Wel heb ik het voor elkaar gekregen om de upload directory te beschermen met:

<FilesMatch ".(docx|doc|jpg)$">
Order Allow,Deny
Deny from all
</FilesMatch>

Hier komen nog wat bestandsextenties bij voor de files waar het echt om gaat

Nu kan ik mijn php scripts ook niet buiten de documentroot plaatsen, wat ik wel jammer vind, maar deze heb ik dan wel weer zo ingesteld dat alle scripts van belang niet uit te voeren zijn zonder ingelogd te zijn.

Bedankt voor de hulp zo ver

[Verwijderd]

Je kunt alles in de upload directory tegenhouden, ongeacht de extensie. Dat maakt het wat makkelijker

En de meeste hosters bieden iets van een private directory aan waar je alleen zelf bij kan misschien kan je het hier in zetten

[Matis]

Goodfellas schreef op donderdag 14 juli 2011 @ 10:42:
Deze fantastische hoster (van klant, zelf niet gekozen natuurlijk), staat het mij niet toe om bestanden buiten /httpdocs/ te zetten. Linken naar een directory hoger (bijvoorbeeld private) gaat simpelweg niet en ik mag op dat niveau ook geen mappen aanmaken.

Wel heb ik het voor elkaar gekregen om de upload directory te beschermen met:

<FilesMatch ".(docx|doc|jpg)$">
Order Allow,Deny
Deny from all
</FilesMatch>

Hier komen nog wat bestandsextenties bij voor de files waar het echt om gaat

Nu kan ik mijn php scripts ook niet buiten de documentroot plaatsen, wat ik wel jammer vind, maar deze heb ik dan wel weer zo ingesteld dat alle scripts van belang niet uit te voeren zijn zonder ingelogd te zijn.

Bedankt voor de hulp zo ver

Je kunt in de download-folder toch ook gewoon een wildcard zetten, zodat toegang op ALLE bestanden geweigerd wordt?
Dan hoef je je daar iig geen zorgen meer om te maken en kunnen eventuele evol_scriptz.php ook niet uitgevoerd worden in die map

Just my 0,02

[Goodfellas]

@Ifs: er is inderdaad een private directory, maar die is zo private dat mijn scripts er ook niet bij mogen. Een eigen folder mag ik zoals gezegd niet aanmaken.

@Matis: Dat is inderdaad wel wat slimmer, zal er eens naar kijken.

[NMe]

Altijd leuk, die "voor een dubbeltje op de eerste rang"-sharedhostingoplossingen. Ik snap nooit waarom klanten het maken van websites willen uitbesteden maar vervolgens zelf een hoster willen uitkiezen.

[Goodfellas]

Die webhoster hebben ze al sinds ze een statische website hadden, daar ben ik gewoon op verder gaan werken (nadat ik eerst wat puin heb geruimd van jaren zelf aanmodderen met html en tabellen).

Ik doe nu trouwens dit (de wildcard) en daarmee lijkt alles mooi afgeschermd:

<FilesMatch ".*">
Order Allow,Deny
Deny from all
</FilesMatch>

[NMe]

Goodfellas schreef op donderdag 14 juli 2011 @ 15:25:
Die webhoster hebben ze al sinds ze een statische website hadden, daar ben ik gewoon op verder gaan werken (nadat ik eerst wat puin heb geruimd van jaren zelf aanmodderen met html en tabellen).

Maar een statische website is ook heel wat anders dan een dynamische waar je nu mee bezig bent. De specs zijn gewijzigd en dus je requirements ook. Eigenlijk hoort daar ook vanuit jouw kant een advies bij om bij deze host te blijven danwel een andere host te zoeken op basis van de gewijzigde eisen.

[MueR]

Goodfellas schreef op donderdag 14 juli 2011 @ 15:25:
<FilesMatch ".*">
Order Allow,Deny
Deny from all
</FilesMatch>

Als je toch op alles matcht, waarom doe je dan nog de moeite om een filematch te pakken?

[Goodfellas]

Ja NMe, eigenlijk heb je daar wel gelijk in. Als ik de handel verhuis kan ik ook mooi de php scripts - die ik include - buiten de documentroot zetten. Bij mijn "standaard" hosting provider kan ik dat soort dingen wel mooi regelen.

@MueR, omdat het zo goed werkt.Voorheen probeerde ik het met directory, maar daarmee blokkeerde ik ook het php script. Dan maar alle bestanden.

[NMe]

MueR bedoelt dat je die hele <FilesMatch> "tag" eromheen weg kan laten.