[php] Beveiligen van bestanden

[Verwijderd]

Hoi,

Ik heb een CMS'je gebouwd waarmee je eenvoudig HTML pagina's kan editten Deze drukt telkens de html in de database en de bestanden ergens op een centrale plek.

Van dit CMS maken meerdere accounts gebruik, die herkenbaar zijn door een uniek id.

Afbeeldingen uit zo'n html pagina staan dan bijvoorbeeld op http://www.centraaldomein/uniek_id/1.jpg.

Nu willen we de mogelijkheid bieden om bepaalde pagina's af te schermen (htaccess). Wat betreft de HTML kan dit heel makkelijk, gewoon pagina pas uit dbs ophalen als de PHP_AUTH_USER ok is.

Probleem hebben we met die bestanden en afbeeldingen die centraal staan en in afgeschermde pagina's gebruikt worden. Deze kunnen met het nodige gokwerk zo rechtstreeks door het url aangeroepen worden.

Is dit op de een of andere manier tegen te gaan? Dus iets van checken of een pagina het bestand ophaalt ofzo? Een ander idee was om beveiligde afbeeldingen en bestanden op te slaan als BLOB's in de dbs, maar hier heb ik slechte verhalen over gehoord met betrekking tot fragmentatie van de HDD.

Elke tip, idee of suggestie is welkom. Alvast bedankt.

[ripexx]

Enige wat ik zo snel kan bedenken is allle images buiten de webroot te zetten zodat deze niet door een browser direct te benaderen zijn. Daan een script maken wat deze images van het filesystem afhaalt en verstuurd. Je kan dan genoeg rechten checks inbouwen.

[Eastern]

Je referer checken met een .htaccess

of een .htaccess bouwen die de user verifieert aan je mysql database.

[pietje63]

Wat ik heb gedaan is een login via htaccess die opgeroept wordt door php. Verder .htaccess bestanden die door php worden weggeschreven na het wijzigen van een account.

verder directory structuur:
/images
/images/leden .ledenhtaccess (bevat alle leden incl bestuur
/images/bestuur .bestuurhtaccess (bevat alleen bestuur)
/downloads
/downloads/leden .ledenhtacces
etc

[Verwijderd]

Eastern, jouw oplossing lijkt me het meest eenvoudig, maar ik vraag me af of dat mogelijk en dan veilig is.

Hoe kan je nu checken met de .htaccess of iemand via een link een bestand download of dat diegene gewoon het url van het bestand in de urlbalk intypt?

Lijkt me onmogelijk.

[Spider.007]

Verwijderd schreef op 06 april 2004 @ 09:00:
Eastern, jouw oplossing lijkt me het meest eenvoudig, maar ik vraag me af of dat mogelijk en dan veilig is.

Hoe kan je nu checken met de .htaccess of iemand via een link een bestand download of dat diegene gewoon het url van het bestand in de urlbalk intypt?

Lijkt me onmogelijk.

Dat is dus exact hetgeen wat voortvloeit uit een htacess beveiliginh; ik zou zeggen; [u]lees je even in[/]

[Joen]

Ik zou de oplossing van ripexx als ik jou was. Eenvoudiger en doeltreffender.
Met die refferers in .htaccess heb ik ook wel eens zitten kl*ten, maar je zit altjd met direct links en dit en dat bla bla. Of je snapt er gewoon op den duur geen mallemoer van.

[Verwijderd]

En als BLOB opslaan in een dbs? Niet alles hoeft namelijk afgeschermd te worden. Zitten hier nog grote nadelen aan?

[Verwijderd]

Verwijderd schreef op 08 april 2004 @ 09:09:
En als BLOB opslaan in een dbs? Niet alles hoeft namelijk afgeschermd te worden. Zitten hier nog grote nadelen aan?

Performance

[Erkens]

Verwijderd schreef op 08 april 2004 @ 09:29:
[...]
Performance

verklaar je nader?
ik ben zelf geen fan van files in blobs gooien, omdat ik vind dat je dan het overzicht kwijt raakt, maar performance? de files komen nog steeds van een filesystem af lijkt me, al dan niet gecached.

[SAiKO]

Met blobs krijg je een grote logge database vol met binaire data. Naar mijn mening is een database daarvoor niet bedoeld. Je hebt dan ook niet echt zicht op de data die erin zit en het zoeken wordt zwaar vertraagd.

[Verwijderd]

Verwijderd schreef op 06 april 2004 @ 09:00:
Eastern, jouw oplossing lijkt me het meest eenvoudig, maar ik vraag me af of dat mogelijk en dan veilig is.

Hoe kan je nu checken met de .htaccess of iemand via een link een bestand download of dat diegene gewoon het url van het bestand in de urlbalk intypt?

Lijkt me onmogelijk.

.htaccess is DE oplossing. Bij .htaccess kun je gewoon een map met alle onderliggende mappen beveiligen. Alle pagina's die je dus in die map zet zijn NIET te bereiken zonder in te loggen, ook niet door in de adresbalk de code in te voeren. Mij lijkt dit DE oplossing

[SAiKO]

Ook nog een optie is om zaken buiten de public_html folder te zetten en deze door middel van een script tijdelijk in een map te zetten waar gebruikers wel leesrechten hebben. Je voorkomt dan dat mensen rechten hebben op bestanden die ze eigenlijk niet mogen zien. Is maar een idee...

[ripexx]

SAiKO schreef op 08 april 2004 @ 11:28:
Met blobs krijg je een grote logge database vol met binaire data. Naar mijn mening is een database daarvoor niet bedoeld. Je hebt dan ook niet echt zicht op de data die erin zit en het zoeken wordt zwaar vertraagd.

Als je een opzet neemt waarbij je uitgaat van preformance en dus je BLOB in een aparte tabel zet met een eigen primary key kan je heel snel een file er uit vissen. Maar je moet niet gaan zoeken in zo'n tabel want dan vraag je om problemen. Al hoewel een goed geoptimaliseerde (R)DBMS dat eventueel wel slim oplost

SAiKO schreef op 08 april 2004 @ 11:31:
Ook nog een optie is om zaken buiten de public_html folder te zetten en deze door middel van een script tijdelijk in een map te zetten waar gebruikers wel leesrechten hebben. Je voorkomt dan dat mensen rechten hebben op bestanden die ze eigenlijk niet mogen zien. Is maar een idee...

ripexx schreef op 05 april 2004 @ 15:34:
Enige wat ik zo snel kan bedenken is allle images buiten de webroot te zetten zodat deze niet door een browser direct te benaderen zijn. Daan een script maken wat deze images van het filesystem afhaalt en verstuurd. Je kan dan genoeg rechten checks inbouwen.

[ Voor 38% gewijzigd door ripexx op 08-04-2004 11:34 ]

[Verwijderd]

RibMax,

Probleem is dat de bestanden op een andere locatie staan als de htmlfiles. De htmlfiles kan ik makkelijk afschermen middels een .htaccess. Het enige probleem is dat er in de map met bestanden dus bestanden staan die wel gewoon gelezen mogen worden, en bestanden staan die afgschermd moeten worden.

Ik denk dat ik in mijn CMS een optie maak waarin je kan aangeven dat het bij een pagina om een beveiligde omgeving gaat. Alle bestanden in die pagina plaats ik dan in een aparte map, buiten de webroot, die ik met een scriptje dan ophaal oid.

[dingstje]

Je kan in je .htaccess alle toegang verbieden tot de beveiligde bestanden en die laten lopen via een PHP script. In dat PHP script check je of de user ingelogged is en of hij de file mag bekijken, zoja open je die (fopen of file_get_contents of ...) en gooi je die naar de browser. Zoniet stuur je een Error 403 ;-)

edit:
De methode van ripexx dus

[ Voor 7% gewijzigd door dingstje op 13-04-2004 23:01 ]

[Verwijderd]

dingstje schreef op 13 april 2004 @ 22:59:
Je kan in je .htaccess alle toegang verbieden tot de beveiligde bestanden en die laten lopen via een PHP script. In dat PHP script check je of de user ingelogged is en of hij de file mag bekijken, zoja open je die (fopen of file_get_contents of ...) en gooi je die naar de browser. Zoniet stuur je een Error 403 ;-)

edit:
De methode van ripexx dus

Een aardige variant hierop is de volgende:

- Markeer alle extensies op je 'bestanden' server als PHP met
ForceType application/x-httpd-php
- Gebruik de PHP optie auto_prepend_file om voor het ophalen van ieder bestand een scriptje te laten draaien

(de bovenstaande settings kun je natuurlijk alleen binnen een bepaalde directory laten gelden)

Dat scriptje controleert eerst of de betreffende gebruiker toegangsrechten heeft of niet, als dat zo is gooi je de juiste mime header eruit gevolgd door de data uit de file, iets als:

code:

        header("Content-type: $mime[mimetype]");
        header("Content-length: ".filesize($SCRIPT_FILENAME));
        ob_end_flush();
        readfile($SCRIPT_FILENAME);
        exit;

Klinkt misschien een beetje bizar, maar ik beheer twee flinke servers (duizenden unieke gebruikers per dag) die geheel zo zijn opgebouwd en al jaren zonder grote problemen draaien. Zowel opbouwen van de standaard layout als de authenticatie en authorisatie per directory werken zo. En *alle* files zijn dus als PHP bestand gedefinieerd ;-)

X.

[Verwijderd]

Kan je niet in een .htaccess zetten dat alleen de webserver -> gebruiker: httpd bestanden mag benaderen in een bepaalde map? Dan zou ik in een klap klaar zijn.

[Verwijderd]

Ik ben nu iets verder en ben met de setEnvIfNoCase van apache aan het stoeien.

Ik draai apache 1.3.20 en daarin zou ik eigenlijk setEnv in een .htaccess moeten kunnen gebruiken, aangezien op de site van apache staat dat het vanaf 1.3.13 is.

Compatibility: Apache 1.3 and above; the Request_Protocol keyword and environment-variable matching are only available with 1.3.7 and later; use in .htaccess files only supported with 1.3.13 and later

Toch krijg ik in mijn errorlog de volgende foutmelding:

.htaccess: SetEnvIfNoCase not allowed here

Moet ik dit ergens nog aanzetten voor deze virtualhost ofzo? Iemand een voorbeeldje of documentatie ergens over hoe dit moet?

[ Voor 64% gewijzigd door Verwijderd op 15-04-2004 15:19 ]

[MatHack]

Je moet bij AllowOverride in je httpd.conf even aangeven dat je dat mag aangeven in .htaccess. Dit kan middels AllowOverride All, maar netter is om de goede optie te noemen. Helaas heb ik de goede optie zo 1,2,3 niet even kunnen vinden.

[Verwijderd]

Vet koel!!! Het werkt. Alleen heb ik nu in mijn httpd.conf op een bepaalde map:

Allowoveride All

gezet en wil ik eigenlijk alleen die ene variabele allowen. Het gaat dus om setEnvIfNoCase variabele. Weet iemand welke dit is?