[php] Files beveiligen tegen uitlezen

Pagina: 1
Acties:
  • 135 views sinds 30-01-2008
  • Reageer

Onderwerpen


Acties:
  • 0 Henk 'm!

  • plakbandrol
  • Registratie: Juni 2002
  • Laatst online: 16-09 09:35
Ik zit met de volgende situatie. Ik ben bezig met een soort foto-album waarin afbeeldingen, filmpjes, en allerlei andere media kunnen worden geupload en worden weergegeven. Ik wil dat het mogelijk is om een bepaald album of afbeelding te kunnen 'disablen', dus dat deze voor het publiek (tijdelijk) niet bereikbaar is.

Het is niet moeilijk om de pagina die het plaatje of filmpje moet weergeven een melding te laten geven dat de file niet toegankelijk is. Maar wanneer de gebruiker eenmaal de directe URL naar het plaatje of filmpje krijgt/raad, is het alsnog toegankelijk.

Aanvankelijk was ik van plan de directory waar alle media-files instaan te beveiligen met .htaccess, en dan een php file te maken die checked of de gebruiker het betreffende bestand mag zien, en zo ja, een soort passthrough maakt zodat het bestand via dat script alsnog bij de bezoeker terecht komt.

Het probleem hierbij was dat je gebruik moet maken van mime-types, en de functie mime_content_type() wordt niet ondersteund op mijn webserver, en zelfs al zou ik zorgen dat die wel werkt, dan zal het script dus niet draaien op een andere server waar deze functie uit staat, dat is dus niet waar ik heen wil. De tweede mogelijkheid was om alle mime-types te hardcoden, alleen mijn script moet alle mogelijke media kunnen verwerken, en ik kan op voorhand nooit alle mogelijke extensies verzinnen, dat zou het script een stuk minder dynamisch maken.

Een andere optie die ik had bedacht was alle media die niet getoond mogen worden, verplaatsen naar een niet-publieke map, en op het moment dat een gebruiker deze media wil bekijken, en daar de rechten voor heeft, de file laten kopieeren naar een tijdelijke wel-publieke map en na het bekijken verwijderen. Alleen dit zou waarschijnlijk te veel cpu-kracht en bestandsruimte vragen, en is zowiezo niet erg elegant.
Een derde mogelijkheid was om alle files op te slaan met een hashcode in de bestandsnaam, deze hashcode moet ook in de SQL tabel komen te staan bij de betreffende file, op deze manier is het onwaarschijnlijk dat iemand de file weet te raden, maar opnieuw blijft het probleem dat wanneer de naam eenmaal bekend is, deze ook door anderen kan worden bekeken.

Zouden er nog andere mogelijkheden zijn om dit op een nette manier op te lossen?

[ Voor 12% gewijzigd door plakbandrol op 20-02-2006 02:37 ]


Acties:
  • 0 Henk 'm!

  • Nijn
  • Registratie: Januari 2005
  • Laatst online: 10:12
Hou me er niet aan, ik ben ook maar een noob hierin. Maar, als je nou de bekende mime types erin gooit. En de overige gewoon als binairy aanduid. (exacte mime weet ik ff nie), dan zoekt het besturingssysteem van de gebruiker precies uit waarmee het afgespeeld kan worden.

Tenminste, zeker onder windows, met de extenties. Linux moet zoiets ook wel kunnen denk ik. Overigens zijn er flinke databases waar vrijwel elke mime type in staat.

Verder is het ook gewoon mogelijk om de htaccess door je script aan te passen. Zo kan je de toegang weigeren tot bepaalde bestanden in de map. Dit is niet beperkt tot mappen!

Ook kan je met .htaccess een hotlink prevention inbouwen, die er voor zorgt dat het bestand alleen geladen kan worden waneer het geladen wordt van jouw site.

[ Voor 28% gewijzigd door Nijn op 20-02-2006 02:37 ]


Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Gewoon alle media in een niet-openbare map gooien. Dan kan je met php je files streamen naar de gebruikers ( zie fopen etc. ) Niks copieren, gewoon direct streamen. Dan kan je in je php-stream bestandje je rechten controleren etc.Voor het bepalen van de mime-content, gewoon deze bepalen bij uploaden en dan opslaan bij de rest van de media-gegevens.

Eventjes jouw mogelijkheden nog beantwoorden :
1 : Is precies de mogelijkheid die ik hier toon. Mime-content is te bepalen bij uploaden, browser stuurt het mee enz. Tevens is een lijstje met mime-contents zo te maken en nooit weg. Maar als je het goed wilt doen dan ga je op zoek naar een manier om echt de mime_contents te achterhalen ( file onder linux dacht ik ).
2 : Veels te bewerkelijk, want jij weet nooit wanneer een gebruiker klaar is met het bestand.
3 : Als 1 persoon een leuke file heeft dan leest hij 1 regeltje bij het downloaden ( waar komt het bestand vandaan ) en post deze regel op een forum.

Acties:
  • 0 Henk 'm!

  • Nijn
  • Registratie: Januari 2005
  • Laatst online: 10:12
Gomez12 schreef op maandag 20 februari 2006 @ 02:37:
Is precies de mogelijkheid die ik hier toon. Mime-content is te bepalen bij uploaden, browser stuurt het mee enz. Tevens is een lijstje met mime-contents zo te maken en nooit weg. Maar als je het goed wilt doen dan ga je op zoek naar een manier om echt de mime_contents te achterhalen ( file onder linux dacht ik ).
Hou d`r idd iig zo`n lijstje zelf ook bij. De mime codes van de ene OS hoeven niet perse overeen te komen met de andere volgens mij. In ieder geval kan je mooie screwups verwachten als iemand een quicktime filmpje upload zonder zelf de player te hebben (dus, Windows weet nie wat de mime code is, als ie die al mee geeft). Klinkt misschien raar, maar er zijn genoeg situaties waarin dit denkbaar is. Inderdaad, de beste manier is altijd nog gewoon linux zo gek krijgen om te vertellen wat het is. Hou er rekening mee dat bij de meeste php instalaties je gewoon (beperkt) bestanden op de server kan uitvoeren. Dus ook een commando dat je verteld welk type bestand het is.

Acties:
  • 0 Henk 'm!

  • plakbandrol
  • Registratie: Juni 2002
  • Laatst online: 16-09 09:35
nijn-01 schreef op maandag 20 februari 2006 @ 02:35:
Hou me er niet aan, ik ben ook maar een noob hierin. Maar, als je nou de bekende mime types erin gooit. En de overige gewoon als binairy aanduid. (exacte mime weet ik ff nie), dan zoekt het besturingssysteem van de gebruiker precies uit waarmee het afgespeeld kan worden.
Heb je daar een code van?
Tenminste, zeker onder windows, met de extenties. Linux moet zoiets ook wel kunnen denk ik. Overigens zijn er flinke databases waar vrijwel elke mime type in staat.
Maar dan moet je die database steeds bijhouden als er nieuw files bijkomen, das een beetje onhandig
Verder is het ook gewoon mogelijk om de htaccess door je script aan te passen. Zo kan je de toegang weigeren tot bepaalde bestanden in de map. Dit is niet beperkt tot mappen!
Dat is een optie, alleen ik was ook van plan bepaalde files af te schermen met een password, dit wordt denk ik een beetje moeilijk om te combineren met htaccess, ik wil bijvoorbeeld geen browser-inlog vensters gebruiken, maar gewoon een formulier waar de gebruiker een wachtwoord invult.
Ook kan je met .htaccess een hotlink prevention inbouwen, die er voor zorgt dat het bestand alleen geladen kan worden waneer het geladen wordt van jouw site.
Maar die is ook nogal zwak omdat de referrer makkelijk vervalst kan worden.

Acties:
  • 0 Henk 'm!

  • plakbandrol
  • Registratie: Juni 2002
  • Laatst online: 16-09 09:35
Gomez12 schreef op maandag 20 februari 2006 @ 02:37:
Gewoon alle media in een niet-openbare map gooien. Dan kan je met php je files streamen naar de gebruikers ( zie fopen etc. ) Niks copieren, gewoon direct streamen. Dan kan je in je php-stream bestandje je rechten controleren etc.Voor het bepalen van de mime-content, gewoon deze bepalen bij uploaden en dan opslaan bij de rest van de media-gegevens.
Maar dan stuit je toch weer op hetzelfde probleem? mime_content_type werkt hier niet goed, of is er nog een andere methode om bij het uploaden het mime-type te bepalen?
Eventjes jouw mogelijkheden nog beantwoorden :
1 : Is precies de mogelijkheid die ik hier toon. Mime-content is te bepalen bij uploaden, browser stuurt het mee enz. Tevens is een lijstje met mime-contents zo te maken en nooit weg. Maar als je het goed wilt doen dan ga je op zoek naar een manier om echt de mime_contents te achterhalen ( file onder linux dacht ik ).
Het probleem is dat het script indien mogelijk ook op windows moet kunnen draaien. Je hebt toch altijd een soort functie nodig die op basis van een bepaalde database aan patronen moet raden om welk mime-type het gaat, of kan het in dit geval anders?

Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
plakbandrol schreef op maandag 20 februari 2006 @ 02:58:
[...]

Maar dan stuit je toch weer op hetzelfde probleem? mime_content_type werkt hier niet goed, of is er nog een andere methode om bij het uploaden het mime-type te bepalen?
Je kan toch gewoon de files-array uitlezen??? Ik dacht dat hij hier ergens in stond.
[...]

Het probleem is dat het script indien mogelijk ook op windows moet kunnen draaien. Je hebt toch altijd een soort functie nodig die op basis van een bepaalde database aan patronen moet raden om welk mime-type het gaat, of kan het in dit geval anders?
Tja, ik geloof dat alle mime-types te achterhalen zijn door de eerste 50-bytes van een bestand uit te lezen. Maar waar je de totale dbase vind met wat wat is, dat weet ik zo snel even niet. Maar als je hem vind dan kun je alles in php afhandelen. Dus even googlen

Acties:
  • 0 Henk 'm!

  • plakbandrol
  • Registratie: Juni 2002
  • Laatst online: 16-09 09:35
Gomez12 schreef op maandag 20 februari 2006 @ 03:14:
Je kan toch gewoon de files-array uitlezen??? Ik dacht dat hij hier ergens in stond.
fuck je hebt gelijk :P

$_FILES['userfile']['type']

die lijkt inderdaad goed te werken

Acties:
  • 0 Henk 'm!

  • r0b
  • Registratie: December 2002
  • Laatst online: 14:54

r0b

Kan je niet met referers gaan werken? Wel fool-proof, niet 100% secure. Daarnaast kan je - correct me if I'm wrong - de dir nog voor de buitenwereld afschermen mbv htpasswd, en local een user/password meegeven bij het opvragen van het plaatje. Dit ziet de gebruiker vervolgens niet, en mocht hij iets opvragen, dan heeft hij/zij nog de user/password nodig.

Zo even iets dat in me opkwam om 03:43 .. :)

Acties:
  • 0 Henk 'm!

  • plakbandrol
  • Registratie: Juni 2002
  • Laatst online: 16-09 09:35
r0b schreef op maandag 20 februari 2006 @ 03:43:
Kan je niet met referers gaan werken? Wel fool-proof, niet 100% secure. Daarnaast kan je - correct me if I'm wrong - de dir nog voor de buitenwereld afschermen mbv htpasswd, en local een user/password meegeven bij het opvragen van het plaatje. Dit ziet de gebruiker vervolgens niet, en mocht hij iets opvragen, dan heeft hij/zij nog de user/password nodig.

Zo even iets dat in me opkwam om 03:43 .. :)
referers zou kunnen, maar is inderdaad erg makkelijk te faken, en dan heeft gelijk z'n beveiligings-feature geen nu meer...

Acties:
  • 0 Henk 'm!

  • StevenK
  • Registratie: Februari 2001
  • Laatst online: 20:05
r0b schreef op maandag 20 februari 2006 @ 03:43:
Kan je niet met referers gaan werken? Wel fool-proof, niet 100% secure. Daarnaast kan je - correct me if I'm wrong - de dir nog voor de buitenwereld afschermen mbv htpasswd, en local een user/password meegeven bij het opvragen van het plaatje. Dit ziet de gebruiker vervolgens niet, en mocht hij iets opvragen, dan heeft hij/zij nog de user/password nodig.

Zo even iets dat in me opkwam om 03:43 .. :)
Doe ik nu ook, maar er zijn firewalls en browsers die de referrer uit zetten en ik zie dus in m'n logs dat er het regelmatig ( 1 x per 2000 views) gebeurt dat iemand probeert een foto zonder de juiste referrer te bekijken.

Was advocaat maar vindt het juridische nog steeds leuk


Acties:
  • 0 Henk 'm!

  • plakbandrol
  • Registratie: Juni 2002
  • Laatst online: 16-09 09:35
hmm nog één probleem..

ik gebruik nu de $FILES var om het Mime type te achterhalen bij het uploaden, dit werkt tot nu toe goed, alleen ik wil ook een optie bouwen om files te importeren uit een andere directory, hierbij heb je geen $FILES var, is er nog een andere simpele manier om dan het mime type te achterhalen?

Acties:
  • 0 Henk 'm!

  • MTWZZ
  • Registratie: Mei 2000
  • Laatst online: 13-08-2021

MTWZZ

One life, live it!

Misschien een beetje spam maar zie ook http://www.barad-dur.nl/nx/tutorials/securedownload/

Nu met Land Rover Series 3 en Defender 90

Pagina: 1