een bestand buiten de root folder zetten

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Marlies Maalderink

Marlies Maalderink

27/01/2017 15:19:16
Quote Anchor link
Ik probeer via een php script een bestand met gevoelige informatie buiten de root folder van een website te zetten. Van te voren weet ik echter niet precies of het script dat dit doet zelf in de root folder staat, of in een submap, of in een submap van een submap, enzovoort.

Ik moet dus een manier vinden om te bepalen wat de rootfolder van de website is, en daar één directory boven gaan zitten.

Als ik $_SERVER[ 'DOCUMENT_ROOT' ] gebruik krijg ik zoiets:

/home000/sub000/sc00000-AAAA/domeinnaam.nl

domeinnaam.nl is de naam van de map waar de website instaat. In dit geval is de naam van de map daarboven dus sc00000-AAAA, de map die ik moet hebben. Maar hoe specificeer ik dat in php?
Gewijzigd op 27/01/2017 15:19:59 door Marlies Maalderink
 
PHP hulp

PHP hulp

22/12/2024 22:27:44
 
Ward van der Put
Moderator

Ward van der Put

27/01/2017 15:26:57
Quote Anchor link
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
$huidige_directory
= __DIR__;
$hogere_directory  = realpath(__DIR__ . '/..');
?>
 
Marlies Maalderink

Marlies Maalderink

27/01/2017 15:34:35
Quote Anchor link
Dan moet ik het zeg maar zo doen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
$buitenroot
= realpath($_SERVER[ 'DOCUMENT_ROOT' ] . '/..');
?>


maar dan pakt hij inderdaad precies de directory die ik nodig heb! Super, dank je wel!!
 
Thomas van den Heuvel

Thomas van den Heuvel

27/01/2017 15:52:54
Quote Anchor link
Mits je daar schrijfrechten hebt :).
 
Marlies Maalderink

Marlies Maalderink

27/01/2017 16:03:01
Quote Anchor link
Hmmm. Bij mijn eigen host heb ik die dus doorgaans zal het niet uitmaken. Maar zo niet, kun je dat dan niet gewoon in het script zelf instellen? chmod naar 777 en na het opslaan van het bestand weer terug naar waar het eerst op stond?
Gewijzigd op 27/01/2017 16:03:22 door Marlies Maalderink
 
Ivo P

Ivo P

27/01/2017 16:19:19
Quote Anchor link
als je een stukje wilt fietsen, pak je een willekeurige fiets.
als de fiets op slot staat, haal je het slot eraf.
Na het fietsen zet je hem weer vast.

Is analoog aan "doe maar chmod 777 als je geen rechten hebt."
Geen rechten = geen sleutel, dus dan kun je hem ook niet even opengooeien

Toevoeging op 27/01/2017 16:20:50:

is trouwens dirname() niet een kortere versie voor realpath en dan /..

Toevoeging op 27/01/2017 16:23:35:

zorg voor de schrijfrechten dat de user waaronder het proces draait dat moet schrijven, de schrijfrechten heeft.

Bijvoorkeur door te zorgen dat dat op basis van "owner" of "group" is. Dus dat de rechten 770 genoeg zijn.

zet je de 3e waarde ook op 7, dan zou het zo maar kunnen dat iedere user op de server in die map kan lezen en schrijven.
Gewijzigd op 27/01/2017 16:24:20 door Ivo P
 
Thomas van den Heuvel

Thomas van den Heuvel

27/01/2017 16:24:15
Quote Anchor link
Wanneer je niets kan/mag in de directory boven de webroot dan kun je daar ook geen bestanden neerzetten. De directory zal in eerste instantie bepalen wat mogelijk is.
 
Marlies Maalderink

Marlies Maalderink

27/01/2017 16:31:28
Quote Anchor link
Ok, dat is dan wel een dingetje om rekening mee te houden. Bij mijn host heb ik toegang tot die directory en is het geen probleem. Maar mocht ik het script eens elders moeten gebruiken dan moet ik dat dus wel eerst testen voor ik het bestand buiten de root folder probeer neer te kwakken, en het anders ergens anders neerzetten.

Quote:
als je een stukje wilt fietsen, pak je een willekeurige fiets.
als de fiets op slot staat, haal je het slot eraf.
Na het fietsen zet je hem weer vast.


Tja... maar, als die fiets in je eigen achtertuin staat en je ervoor betaald hebt, dan is dat toch niet zo'n raar idee? Hoe moet je anders ooit een fietstochtje maken?
 
Ivo P

Ivo P

27/01/2017 16:57:26
Quote Anchor link
Als in je achtertuin de fiets van een vriend staat, heb je de sleutel niet.

Als de map niet van het proces is, dan kun je er nog niet in.

Vaak is de map van de gebruiker "website_nl"

Het php process kan draaien onder de user "apache", "www" of iets dergelijks. In de map "public_html" (als dat de documentroot is) kan het process dan lezen. (meeste hosting partijen richten dat zo in :-) )

maar de map die naast public_html staat, laten we die "bestanden" noemen:
wie maakt die aan.
Grote kans dat jij dat doet met je ftp programma. Dan wordt die map dus van de user "website_nl". Je kunt er niet zondermeer vanuit gaan dat "apache" dan ook daar mag kijken.

De simpele benadering zou zijn om de map met chmod 777 door de ftp user open te zetten.

Beter is het om dan in elk geval nog te zorgen dat de groupsrechten (de 2e 7) voldoende zijn.
Vraag is alleen of jij dat zelf kunt inregelen, of dat de site beheerder dat moet doen. Niet elke user kan namelijk zomaar bepalen van welke user/group een bestand of map is.

Draait het process onder de user website_nl, dan is het probleem een stuk kleiner.
 
Marlies Maalderink

Marlies Maalderink

27/01/2017 17:16:34
Quote Anchor link
Hmm, ik snap wat je bedoelt. Als ik het script dus ooit op een andere server wil installeren moet ik er rekening mee houden dat ik via de ftp de rechten moet aanpassen (wat op zich ook niet uitmaakt) of het bestand in een andere map zetten waar het script wel rechten heeft.

Het gaat overigens om een bestand met alle inloggegevens van zowel de database als smtp. Misschien maakt het ook wel helemaal niet zoveel uit als het gewoon in een map binnen de rootfolder zet. Wordpress en Drupal doen dat ook niet. Hoe veilig is het om dat soort bestanden op de server te bewaren?
 
Ivo P

Ivo P

27/01/2017 17:25:23
Quote Anchor link
zelf zet ik alles wat niet aangeroepen hoeft te worden door een browser buiten de document root.

in de document root staan bij mij alleen
index.php
map css/ met de css bestanden
map js/
map img/ met afbeeldingen tbv de layout. (dus niet geuploade door applicaties, bijvoorbeeld van te verhuren objecten)


Buiten de document root staan bij mij mappen met inderdaad de config files,
maar ook mappen met models, controllers en views
algemene classes etc.

vanuit index.php wordt iets aangeroepen buiten de document root en de betreffende controller zorgt voor de rest.

Het voorkomt in elk geval dat scripts vanuit een browser aangeroepen worden. Hoewel de meeste scripts weinig doen als rechtstreeks aangesproken (als er alleen een class in staat, dan wordt er niets zo maar uitgevoerd), maar als het niet hoeft, dan mag het wat mij betreft ook niet.

Terug naar jouw config:
moet er geschreven worden, of is lezen genoeg. Dat scheelt wel wat.

In elk geval zou ik gaan voor een script.
dus niet een tekst bestand met een leesbare tekst (zo iets als een php.ini file bedoel ik)
Dat is namelijk leesbaar als iemand de file aanroept in de browser.

een config.php levert hopelijk gewoon een blanco response.

Verder kan een .htaccess bestand met Deny From All erin helpen. (dat dus alleen voor de browser geldt en niet voor php zelf)
 
Marlies Maalderink

Marlies Maalderink

27/01/2017 17:35:57
Quote Anchor link
Er moet inderdaad geschreven worden, de database gegevens worden via een form ingevoerd, gecontroleerd en als er verbinding gemaakt kan worden, worden ze opgeslagen in settings.php

Dat iemand het bestand in de browser aanroept lijkt me idd niet zo erg, want dat levert gewoon een wit scherm op. Maar ik weet niet of er andere manieren zijn om toch bij de code te komen.
Op zich maakt het niet zoveel uit, wat ik al zei, als ik het script wil installeren moet ik sowieso FTP toegang hebben om de bestanden te kunnen uploaden dus kan ik ook de rechten van de benodigde map veranderen... Maar het is dan idd wel prettig om het toch buiten de root folder te zetten, dus hou ik het maar zo.
 
Ward van der Put
Moderator

Ward van der Put

28/01/2017 07:59:28
Quote Anchor link
Marlies Maalderink op 27/01/2017 17:35:57:
Dat iemand het bestand in de browser aanroept lijkt me idd niet zo erg, want dat levert gewoon een wit scherm op.

Je kunt daarvoor in settings.php een controle opnemen op een constante die ergens anders wordt gedefinieerd, bijvoorbeeld in het PHP-bestand dat settings.php met include of require insluit:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
<?php
if (!defined('CONSTANTE_UIT_ANDER_PHP_BESTAND')) {
    header('HTTP/1.1 404 Not Found');
    exit;
}

?>

Inclusief een 404-fout, zodat het voor buitenstaanders lijkt dat het bestand niet eens bestaat.

Een techniek die ik wel eens gebruik als ik niet kan schrijven buiten de webroot, is in .htaccess de toegang tot alle config.* weigeren — dus tot config.ini, config.php, config.inc, config.yml, enzovoort:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<Files "config.*">
  Deny from all
</Files>
 
Marlies Maalderink

Marlies Maalderink

28/01/2017 09:41:37
Quote Anchor link
Dank je Ward, dat is handige informatie.
Misschien een domme vraag, maar als je via .htaccess alle toegang weigert tot config.*, kun je het bestand dan nog wel includen in een ander bestand?
 
Frank Nietbelangrijk

Frank Nietbelangrijk

28/01/2017 10:40:23
Quote Anchor link
Marlies Maalderink op 28/01/2017 09:41:37:
Misschien een domme vraag, maar als je via .htaccess alle toegang weigert tot config.*, kun je het bestand dan nog wel includen in een ander bestand?


Ja want includen gaat intern via de filesystem en niet via het http protocol.

Als een gebruiker een pagina (is gelijk aan een bestand) opvraagt via de webbrowser dan zal de webserver (bijv, apache) onder andere kijken naar de .htaccess bestanden en bepalen of de gebruiker deze pagina wel mag zien.
Maar als een php script gestart wordt door apache dan is dit een proces dat draait op de achtergrond van de webserver. Dit proces heeft vervolgens toegang tot alle bestanden waarvoor het gemachtigd is. Ik praat dan over de toegangsrechten van het filesystem. ,htaccess bestanden hebben daar niets mee te maken.
 
Marlies Maalderink

Marlies Maalderink

28/01/2017 10:42:41
Quote Anchor link
Duidelijk, dank voor de uitleg, ik kan weer verder :)
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.