Toon posts:

[PHP] htaccess gebruiken

Pagina: 1
Acties:
  • 3.555 views sinds 30-01-2008

Onderwerpen


  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
Ik heb een site gemaakt waarbij ingelogde gebruikers scans kunnen uploaden en nadien bekijken. Die scans komen in een met htaccess beveiligde map te staan. De gebruikersnaam + het wachtwoord van de map wil ik intern gebruiken in de php code, zodat gebruikers deze niet zelf moeten invoeren.

Zulke URL's komen er dan zo uit te zien: username:pswd@http://www.blabla.nl/scans/bla.jpg

Het probleem is dat de gebruikersnaam en het wachtwoord zichtbaar zijn zodra je de cursor op de link plaatst. Hetzelfde geldt voor rechter muistoets en view source. Nu zou ik de statusbalk kunnen wissen en rechter muistoets + view source kunnen blokkeren, maar bestaat er niet een betere mogelijkheid?

  • DizzyWeb
  • Registratie: februari 2001
  • Laatst online: 07:11

DizzyWeb

Ondertiteld

Waarom zou je dit uberhaupt willen? Zet dan de beveiliging gewoon uit, want iets beveiligen en dan bewust je beveiliging omzeilen lijkt me vrij zinloos.

Overigens, dergelijke URL's werken niet in alle browsers, juist omdat het zo'n beveiligingsrisico is.

[Voor 26% gewijzigd door DizzyWeb op 05-07-2006 14:52]


  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
De map moet beveiligd zijn omdat deze gevoelige informatie gaat bevatten. Hoe zou je het anders kunnen oplossen dan?

  • Angelolel
  • Registratie: maart 2006
  • Laatst online: 10-07-2009
DizzyWeb schreef op woensdag 05 juli 2006 @ 14:51:
Waarom zou je dit uberhaupt willen? Zet dan de beveiliging gewoon uit, want iets beveiligen en dan bewust je beveiliging omzeilen lijkt me vrij zinloos.

Overigens, dergelijke URL's werken niet in alle browsers, juist omdat het zo'n beveiligingsrisico is.
De gebruiker moet denk eerst inloggen op de website :)

Toch?

  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
Angelolel schreef op woensdag 05 juli 2006 @ 15:03:
[...]


De gebruiker moet denk eerst inloggen op de website :)

Toch?
Yep.

  • AtleX
  • Registratie: maart 2003
  • Niet online

AtleX

Tyrannosaurus Lex 🦖

Nou dan, je zet die map dicht zodat bezoekers er niet bij kunnen (buiten de webroot bij voorkeur), en vervolgens ga je met PHP die afbeeldingen serveren (fpassthru()).

12x360Wp = 4320 Wp @ Growatt 4200TL-XL. Zuid met helling 13° op plat dak.


  • ReverendBizarre
  • Registratie: december 2001
  • Laatst online: 24-03 18:37
Je zou gewoon de map met fotos via .htaccess helemaal dicht kunnen gooien en een scriptje schrijven die de fotos uit deze map serveert. Dan zou je dus iets krijgen als http://jouwurl/image.php?img=picture1.jpg. Er zijn genoeg voorbeelden op Google oid te vinden over hoe je dat precies moet doen (je laadt dan de file via het lokale filesysteem in in PHP en stuurt dit vervolgens met de juiste headers door naar de client). Dit is wel wat server intensiever dus als je een site maakt met hele grote bezoekersaantallen is dat iets om rekening mee te houden. Maar het is een mogelijke oplossing.

  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
Dat zou idd een optie zijn. Bedankt.

Probleem is dat ik nu nog niet weet hoeveel gebruikers de site gaat trekken. Dat zouden er best eens heel veel kunnen worden.

Ik zat er ook aan te denken om de bestandsnamen te versleutelen zodat ze niet te gokken zijn. Op die manier zou je de map niet eens hoeven beveiligen. Zou dat ook een goede optie zijn?

  • AtleX
  • Registratie: maart 2003
  • Niet online

AtleX

Tyrannosaurus Lex 🦖

Ik zou het toch maar wel beveiligen, dat is een kleine moeite voor extra beveiliging.

12x360Wp = 4320 Wp @ Growatt 4200TL-XL. Zuid met helling 13° op plat dak.


  • Angelolel
  • Registratie: maart 2006
  • Laatst online: 10-07-2009
SKiLZ schreef op woensdag 05 juli 2006 @ 15:16:
Dat zou idd een optie zijn. Bedankt.

Probleem is dat ik nu nog niet weet hoeveel gebruikers de site gaat trekken. Dat zouden er best eens heel veel kunnen worden.

Ik zat er ook aan te denken om de bestandsnamen te versleutelen zodat ze niet te gokken zijn. Op die manier zou je de map niet eens hoeven beveiligen. Zou dat ook een goede optie zijn?
Waarom zou je het dan niet beveiligen? Als de map niet wordt beveiligd kan je met een tooltje wel weer kijken wat er allemaal in die map staat, dus kan je ook de afbeeldingen opvragen

Ik zou het gewoon beveiligen, versleuten zou eventueel ook nog een goed idee zijn :)

[Voor 6% gewijzigd door Angelolel op 05-07-2006 15:22]


  • sjhgvr
  • Registratie: januari 2004
  • Laatst online: 17-10 18:58

sjhgvr

blocklist maintainer

Nu zou ik de statusbalk kunnen wissen en rechter muistoets + view source kunnen blokkeren
Broncode is altijd uit te lezen, is niet te blokeren. Statusbalk wissen is ook een onzinnig iets. Zeker aangezien dat word gezien als een beveiligingslek (URL Spoofing)

Edit: Ben overigens zelf ook bezig met zo'n script. En wat ik ga doen is gewoon met de .htaccess all referers blocken op alle fileextencies behalve php. Dan als iemand een bestand wil downloaden, gewoon het door php aan laten bieden ;)

[Voor 31% gewijzigd door sjhgvr op 05-07-2006 15:24]

oisd.nl | domain blocklist


  • ReverendBizarre
  • Registratie: december 2001
  • Laatst online: 24-03 18:37
DapinododiadeaL schreef op woensdag 05 juli 2006 @ 15:22:
[...]Edit: Ben overigens zelf ook bezig met zo'n script. En wat ik ga doen is gewoon met de .htaccess all referers blocken op alle fileextencies behalve php. Dan als iemand een bestand wil downloaden, gewoon het door php aan laten bieden ;)
Als je een bestand via PHP laat aanbieden met bijvoorbeeld fpassthru() dan gaat dat gewoon via het lokale filesysteem en heeft .htaccess daar dus geen enkele invloed op. Het is dan ook niet nodig om PHP bestanden toegang te verlenen tot de directory via .htaccess. Het is zelfs een beveiligingsprobleem als je dat doet, want dan kan ik dus ook een PHP scriptje op mijn site zetten die gewoon de images van jouw website kan plukken.

Bovendien is referrer gebruiken als basis voor een beveiliging sowieso geen goed idee omdat de referrer string door de user agent gespecifieerd wordt en dus per definitie niet betrouwbaar is (en bijvoorbeeld ook gewoon helemaal niet aanwezig kan zijn).

  • Rowdy.nl
  • Registratie: juni 2003
  • Laatst online: 10:25

Rowdy.nl

Koekje d'r bij?

Ik snap het hele verhaal niet echt. Je wilt mensen scnas laten uploaden, en ook weer laten bekijken? Maar dit mogen enkel een aantal geregistreerde gebruikers doen.

Want het nut om iets te maken zoals een beveiligde map met scans, en dan vanuit een onbeveiligd bestand te gaan linken naar die scans heeft geen nut.

Als je nu je alles in een map gooit en beveiligd, en dus ook je index pagina daarin gooit ben je toch klaar?

Jantje wilt wat foto's bekijken, gaat naar http://jouwdomijn.nl/beveiligde_map/, tiept daar netjes zijn username en wachtwoord in en kan lekker browsen, uploaden en foto's bekijken... Of denk ik nu gewoon vel te simpel? ;)

En als het gewoon om hotlinking preventie gaat, dit is eenvoudig op te lossen dmv je .htaccess bestand... ;)

Rowdy.nl - X++ by day. C# by night. I drink coffee in the morning and beer in the evening.


  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
[b][message=26081201,noline]
Als je nu je alles in een map gooit en beveiligd, en dus ook je index pagina daarin gooit ben je toch klaar?

Jantje wilt wat foto's bekijken, gaat naar http://jouwdomijn.nl/beveiligde_map/, tiept daar netjes zijn username en wachtwoord in en kan lekker browsen, uploaden en foto's bekijken... Of denk ik nu gewoon vel te simpel? ;)
In dat geval zouden geregistreerde gebruikers scans van elkaar kunnen bekijken.

  • Rowdy.nl
  • Registratie: juni 2003
  • Laatst online: 10:25

Rowdy.nl

Koekje d'r bij?

Juist, maar dat kunnen ze anders ook... :)

Dan zou ik als ik jou was via je .htaccess access tot die map verbieden, zie onderstaand voorbeeld. (/error/403 is een custom forbidden message bij mij)
code:
1
2
3
4
5
6
7
8
9
# Switch SymLinks on... :)
Options +FollowSymlinks

# Rewrite engine on
RewriteEngine On
RewriteBase /

# Deny access to some folders
RedirectMatch ^/scans /error/403

En dan vervolgens een script maken wat je in de root zet en wat je scans kan laten zien.
PHP:
1
2
3
4
5
6
7
8
<?php
$bestand = $_GET['bestand'];

// TODO: Beetje security inbouwen waarmee je controleerd of gebruiker x toegang heeft tot $bestand
if($access)
  file("./scans/.".$bestand);
else
  print "You don't have access";

Rowdy.nl - X++ by day. C# by night. I drink coffee in the morning and beer in the evening.


  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
Bedankt allemaal, ik ga eens kijken wat ik het beste kan gebruiken.

  • sjhgvr
  • Registratie: januari 2004
  • Laatst online: 17-10 18:58

sjhgvr

blocklist maintainer

IrishMaiden schreef op woensdag 05 juli 2006 @ 15:36:
[...]
Als je een bestand via PHP laat aanbieden met bijvoorbeeld fpassthru() dan gaat dat gewoon via het lokale filesysteem en heeft .htaccess daar dus geen enkele invloed op. Het is dan ook niet nodig om PHP bestanden toegang te verlenen tot de directory via .htaccess. Het is zelfs een beveiligingsprobleem als je dat doet, want dan kan ik dus ook een PHP scriptje op mijn site zetten die gewoon de images van jouw website kan plukken.

Bovendien is referrer gebruiken als basis voor een beveiliging sowieso geen goed idee omdat de referrer string door de user agent gespecifieerd wordt en dus per definitie niet betrouwbaar is (en bijvoorbeeld ook gewoon helemaal niet aanwezig kan zijn).
Je snapt m niet helemaal, ik zal t ff beter proberen uit te leggen;
wat ik dus doe is met de htaccess block ik ALLE referers, dus OOK LEGE... kun jij spoofen wat je wilt. Het omzeilen van dat door bestanden op te vragen met mijn php script is juist mijn bedoeling!
Zodat alleen via mijn script de bestanden downloadbaar zijn.

oisd.nl | domain blocklist


  • ReverendBizarre
  • Registratie: december 2001
  • Laatst online: 24-03 18:37
Ik begrijp het volgens mij nogsteeds niet. Je zegt dat je referrers blockt op alle extensies behalve .php. Dat betekent dus dat als ik even een plugin download voor Firefox waar ik mijn refererrer kan beinvloeden (en die bestaan) en ik zet daar http://jouwdomain.com/hoi.php in dat ik gewoon vrolijk bestanden uit die directory mag downloaden. Hetzelfde geldt als ik een PHP script op mijn eigen site zet die gewoon van jouw site files gaat zitten downloaden (ik weet niet of de filesystem http wrappers in PHP automatisch de referrer goed zetten maar zo niet kan je het altijd met sockets handmatig oplossen).

Wat ik dus probeerde te zeggen:

1. Je systeem is verre van waterdicht (wat misschien niet zo'n big deal is, ik weet niet waar jij het voor gebruikt, maar voor de TS zou dit zeker geen oplossing zijn)

2. Het is onnodig, want als je PHP script op dezelfde machine draait als waar je bestanden vandaan komen dan kan je er gewoon via het lokale bestandsysteem bij en heeft een .htaccess file dus gewoon helemaal geen effect. .htaccess is een Apache configuratie bestand en is dus alleen van toepassing wanneer je via HTTP requests je bestanden probeert te benaderen. Als je gewoon fopen() of fpassthru() of wat dan ook via PHP aanroept op die bestanden dan gaat dat via het lokale bestandssysteem en doet die .htaccess file dus gewoon *niks*. En in dat geval moet je dus gewoon met .htaccess die directory helemaal dicht gooien. Ook voor referrers met een .php extensie.

Maar misschien begrijp ik je nogsteeds verkeerd.

  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
Ik heb het geprobeerd met fpassthru(), maar ik krijg een warning m.b.t. de headers: "Cannot modify header information - headers already sent by blabla".

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
$bestand = "/opt/guide/www.xxx.nl/HTML/admin/export/scan123.jpg";

// Open het bestand in binaire modus
if($fp = fopen($bestand, 'rb'))
{
  // stuur de juiste headers
  header("Content-Type: image/jpeg");
  header("Content-Length: ".filesize($bestand));
    
  // stuur het plaatje door 
  fpassthru($fp);
}
else echo "niet gelukt";


Onder die warnings verschijnt een hele rits ASCII codes, de inhoud van het bestand neem ik aan.
Kan iemand mij zeggen wat ik fout doe?

[Voor 15% gewijzigd door SKiLZ op 06-07-2006 13:07]


  • R4NCOR
  • Registratie: december 2000
  • Laatst online: 09:46

R4NCOR

eigenlijk gewoon Niels

De foutmelding is vrij duidelijk toch? Je hebt waarschijnlijk ergens in je PHP file al output in de vorm van een echo, of een whitespace voor je php-tag. De error geeft ook een linenumber volgens mij?

  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
R4NCOR schreef op donderdag 06 juli 2006 @ 13:10:
De foutmelding is vrij duidelijk toch? Je hebt waarschijnlijk ergens in je PHP file al output in de vorm van een echo, of een whitespace voor je php-tag. De error geeft ook een linenumber volgens mij?
De linenumbers verwijzen naar de regels met de headers erin (zie mijn code).

  • R4NCOR
  • Registratie: december 2000
  • Laatst online: 09:46

R4NCOR

eigenlijk gewoon Niels

SKiLZ schreef op donderdag 06 juli 2006 @ 13:12:
[...]


De linenumbers verwijzen naar de regels met de headers erin (zie mijn code).
Ah ja, had ik kunnen bedenken. Maar dan nog, je hebt waarschijnlijk eerder in je bestand al output (echo's of whitespace of ...). Dat magniet. :P

  • elguapo
  • Registratie: februari 2000
  • Laatst online: 18-11-2009
Ik heb een soortgelijk iets gemaakt voor een file-upload systeempje. In m'n .htaccess 'deny from all', en vervolgens dit in php:

PHP:
1
2
3
4
5
6
7
8
// code om variabelen in te laden (in mijn geval via mysql en php-sessie)

header('Content-type: application/octet-stream');
header('content-length: '.$lenght.'');
header('content-disposition: attachment; filename='.$filename.'');

$fp=fopen($file, 'r');
fpassthru($fp)

  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
R4NCOR schreef op donderdag 06 juli 2006 @ 13:18:
[...]

Ah ja, had ik kunnen bedenken. Maar dan nog, je hebt waarschijnlijk eerder in je bestand al output (echo's of whitespace of ...). Dat magniet. :P
Het werkt al. :)

Hij raakte van slag door alle includes. Probleem is dat de code wel ná alle includes moet komen, dus ik moet nog even kijken of het uberhaupt wel te realiseren is.

  • ReverendBizarre
  • Registratie: december 2001
  • Laatst online: 24-03 18:37
Wat je dus moet doen is zorgen dat de files die je include geen output genereren. Zelfs een lege witregel buiten een <?php ?> blok is genoeg om ervoor te zorgen dat de HTTP headers al verstuurd worden. Een makkelijke manier om dit op te lossen, zet een output buffer om je include files heen en gooi deze gewoon leeg op de volgende manier:

PHP:
1
2
3
4
5
6
7
ob_start();

require_once('bestand1.php')
require_once('bestand2.php')
require_once('bestand3.php')

ob_end_clean();


Dit zorgt ervoor dat alle output die je includes mogelijk genereren opgevangen worden in een output buffer in plaats van dat ze gelijk verzonden worden, en vervolgens gooi je deze buffer gewoon leeg en zet je output buffering uit.

[Edit: tenzij de include files natuurlijk output genereren die je wel wilt outputten, in dat geval moet je gewoon de buffer niet leeggooien maar gewoon flushen nadat je al je calls naar header() hebt gemaakt.]

[Voor 16% gewijzigd door ReverendBizarre op 06-07-2006 13:44]


  • SKiLZ
  • Registratie: april 2003
  • Laatst online: 23-08-2011
Bedankt, de plaatjes worden nu correct doorgestuurd. :)

Je krijgt nu een lege witte pagina te zien waar het plaatje in verschijnt, maar het is eigenlijk de bedoeling om een thumbnail onderaan de pagina weer te geven. Is er een mogelijkheid om het plaatje op te vangen en d.m.v. een URL weer te geven?

  • sjhgvr
  • Registratie: januari 2004
  • Laatst online: 17-10 18:58

sjhgvr

blocklist maintainer

IrishMaiden schreef op donderdag 06 juli 2006 @ 12:43:
Ik begrijp het volgens mij nogsteeds niet.
...
Maar misschien begrijp ik je nogsteeds verkeerd.
Ok.. heb ff een voorbeeld voor je online gezet;
- http://jessicaalba.nl/leechtest/
- http://jessicaalba.nl/leechtest/ScarlettJohansson.jpg
- http://jessicaalba.nl/leechtest/test.php

Bron test.php:
PHP:
1
2
3
4
5
6
7
8
9
10
11
<?php
$file='ScarlettJohansson.jpg';
if(file_exists($file)):
$fsize=filesize($file);
header("Content-Type: image/jpeg");
header("Content-Disposition: attachment; filename=$file");
header("Content-Transfer-Encoding: binary");
header("Content-Length: $fsize");
readfile($file);
endif;
?>
Bron .htaccess:
code:
1
2
RewriteEngine On
RewriteRule jpg - [F]
Kun jij mij dan vertellen hoe jij ScarlettJohansson.jpg anders dan met test.php kan downloaden?
Waarschijnlijk bestaan er 101 manieren.. :X

[Voor 10% gewijzigd door sjhgvr op 06-07-2006 16:53. Reden: 5% voor het veranderen van een . in een ? .... huh?]

oisd.nl | domain blocklist


  • ReverendBizarre
  • Registratie: december 2001
  • Laatst online: 24-03 18:37
Nee als je alle requests voor een .jpg bestand gewoon rewrite zodat ze niet toegankelijk zijn dan moet dat gewoon veilig zijn. Ik interperteerde dit...
DapinododiadeaL schreef op woensdag 05 juli 2006 @ 15:22:
[...]Edit: Ben overigens zelf ook bezig met zo'n script. En wat ik ga doen is gewoon met de .htaccess all referers blocken op alle fileextencies behalve php. Dan als iemand een bestand wil downloaden, gewoon het door php aan laten bieden ;)
...echter als:

code:
1
2
3
RewriteEngine on
RewriteCond %{HTTP_REFERER} ! ^.\.php$ [NC]
RewriteRule \.jpg$ - [F,NC]


Of iets in die zin (syntax zal wel niet helemaal correct zijn).

  • killercow
  • Registratie: maart 2000
  • Laatst online: 20-10 13:16
Tjonge, dat was een paar jaar terug.

[Voor 91% gewijzigd door killercow op 07-12-2015 16:38. Reden: datum van de post verkeerd gezien.]

Ook zin in een outdoor geek-fest? eth0.nl


  • RobIII
  • Registratie: december 2001
  • Laatst online: 10:45

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

En dan schop jij 't maar weer omhoog? 8)7
Ah, dat had je inmiddels zelf ook al gezien :P

[Voor 20% gewijzigd door RobIII op 07-12-2015 16:40]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij

Pagina: 1

Dit topic is gesloten.



Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee