php, constants & security

[xces]

Ik zit met hetzelfde probleem waar minimaal 1024 anderen ook al mee gezeten hebben, maar weet niet zo goed hoe ik het moet googlen...

Ik heb op 1 domein ook een subdomein waar het cms op draait. Nu wil ik op het hoofddomein de database instellingen opslaan, zodat ze vanaf het subdomein te includen zijn.

Dit kan natuurlijk op 2 manieren:
a) In een bepaalde PHP file op het hoofddomein een aantal constants definen, om deze vervolgens te includen vanaf het subdomein.
b) In een bepaalde PHP file op het hoofddomein een functie zetten die de db connectie maakt, om deze vervolgens te includen vanaf het subdomein.

Beide methodes gaan lukken, maar ik heb mijn vraagtekens bij methode "a" en security. Ik definieer de constants namelijk, dus via get_defined_constants() zouden deze defines zichbaar moeten zijn. Het risico zit hem erin, dat mensen de naam van de file achterhalen, en deze remote includen.

Nu staat mijn server niet toe dat ik remote urls include, maar ik weet dus niet of dit ook betekend dat mensen van buitenaf geen include van mijn server kunnen laden... Dus dit laatste is eigenlijk mijn vraag, weet iemand dit?

[Verwijderd]

volgens mij als iemand (een externe host) NOOIT een include bestand laden van je server. Indien die andere server het bestand opvraagt dan wordt het namelijk geparsed door jouw server en krijgt de andere server gewoon een leeg bestandje (de gegevens zitten in het geheugen van JOUW webserver).

zo dacht ik tenminste als dit is wat je bedoelt. Hopelijk krijg ik hier nog wat backup van iemand die zekerder is.

[GX]

Of je zet gewoon je settings in een bestand buiten de webroot en include die vanaf elke website die deze data nodig heeft. Veilig is nog steeds iets anders (denk shared hosting etc), maar al beter dan op je website een php-achtig bestand uitspugen.

[ReverendBizarre]

xces schreef op maandag 04 december 2006 @ 12:28:
Beide methodes gaan lukken, maar ik heb mijn vraagtekens bij methode "a" en security. Ik definieer de constants namelijk, dus via get_defined_constants() zouden deze defines zichbaar moeten zijn. Het risico zit hem erin, dat mensen de naam van de file achterhalen, en deze remote includen.

Als iemand de file remote (via HTTP in plaats van het lokale filesystem) include dan wordt de file gewoon geparsed als een PHP script en zal een bestand met alleen een stel defines erin gewoon als leeg bestand ontvangen worden (mits je die defines natuurlijk in een bestand met een bestandsextentie zet die als PHP geparsed wordt, dus niet "constants.inc" oid). Dat laatste is wel belangrijk.

Verder is het enige mogelijke risico aan deze opzet dat op het moment dat PHP zou wegvallen op de webserver dat iemand het bestand wel zou kunnen inlezen (dan wordt het immers gewoon door Apache geserveerd zonder dat het door PHP ge-processed wordt). De kans dat dat echter gebeurt lijkt me over het algemeen redelijk verwaarloosbaar.

[BCC]

CAIRATH schreef op maandag 04 december 2006 @ 12:49:
[...]
De kans dat dat echter gebeurt lijkt me over het algemeen redelijk verwaarloosbaar.

Security by obscurity dus?! Dat lijkt me niet echt netjes. Je kan natuurlijk ook gewoon even een IP check doen voordat je die Database settings oplepelt. Dan ben je al redelijk safe.

Als je op dezelfde server staan -> Zie hieronder

[ Voor 6% gewijzigd door BCC op 04-12-2006 13:04 ]

[Janoz]

Draaien ze allemaal op dezeflde server? Dan kun je de settings toch gewoon via het filesystem importeren. ZOlang je dat in een php bestand hebt staan (als code dus) dan is het door de client niet op te vragen. Daarnaast kun je het ook, zoals ook eerder gezegd, buiten de webroot opslaan.

[ReverendBizarre]

BCC schreef op maandag 04 december 2006 @ 13:00:
[...]

Security by obscurity dus?! Dat lijkt me niet echt netjes. Je kan natuurlijk ook gewoon even een IP check doen voordat je die Database settings oplepelt. Dan ben je al redelijk safe.

Als je op dezelfde server staan -> Zie hieronder

Ik zeg toch niet dat je het zo moet doen? Ik zeg alleen dat de kans dat hierdoor iets uitlekt niet groot is en dat is ook gewoon zo (dan moet de server config kapot zijn, er iemand zijn die weet waar jouw include bestand staat en hoe het heet, en ook nog een database configuratie hebben die connecties van remote locaties toestaat). Als ik in een situatie zou zijn waar dit de enige makkelijk oplossing zou zijn dan zou ik er echt geen moment van wakker liggen.

Zelf zet ik altijd mijn database includes in een bestand dat buiten de webroot bestaat, maar dat is niet altijd een optie.

[MarkvE]

Ik zet altijd mijn instellingen in een PHP-file waarin constants staan die de instellingen bevatten. Vervolgens zet ik deze in een directory met een .htacces-file waarin staat:

code:

deny from all

Daardoor kan het bestand alleen geinclude worden vanuit het systeem zelf. Een beetje hetzelfde effect als je het buiten de webroot plaatst maar geen gezeur wilt met "open_basedir effect" die je vaak krijgt bij iedere willekeurige host.

[BikkelZ]

Als het om read-only info gaat is XML ook geen slecht idee. Het werkt nog redelijk vlot ook, als het om niet te veel data gaat. Daar is tenslotte XML in de eerste plaats voor bedoeld.

[ Voor 18% gewijzigd door BikkelZ op 27-12-2006 10:47 ]

[Infinitive]

BikkelZ schreef op woensdag 27 december 2006 @ 10:47:
Als het om read-only info gaat is XML ook geen slecht idee. Het werkt nog redelijk vlot ook, als het om niet te veel data gaat. Daar is tenslotte XML in de eerste plaats voor bedoeld.

Sorry hoor, maar wat heeft XML hiermee te maken

De TS vraagt zich af of database gegevens in een php bestand problemen kunnen geven met security, want hij vraagt zich af wat er gebeurd als iemand dat bestand met zijn webbrowser opent (of als remote include opent). Dat kan in principe geen kwaad want dit bestand wordt als php-script uitgevoerd en zal een lege pagina opleveren, maar veiliger is het om dat bestand niet toegankelijk te maken vanaf het web (daarvoor zijn al wat oplossingen in dit topic aangedragen).

XML verteld alleen iets over de inhoud van het bestand. Dat gaat dus geen extra beveiliging bieden. Erger nog, als je het XML bestand remote opent, dan krijg je de letterlijke inhoud terug, dus kan je dat databasewachtwoord zo uitlezen!

[ Voor 50% gewijzigd door Infinitive op 27-12-2006 12:01 ]

[Verwijderd]

@infinitive:
Met .htaccess kun je heel veel, dus ook zorgen dat die XML-bestanden geweigerd zijn voor cliënts (met filematch bijv.)

"maar veiliger is het om dat bestand niet toegankelijk te maken vanaf het web"
Zie daar als het gaat om PHP-bestanden het nut niet van in... Er gebeurt toch niets als je als cliënt een include-file opent waarin alleen functioniteit e.d. opgenomen is.

Mijn voorkeur gaat uit naar een centrale map, die bereikbaar is voor alle subdomeinen. Evt. zou deze map buiten de webroot mogen liggen, wat op zich niets uitmaakt.

@XCES:
Ik heb voor jou nog een oplossing:

XML:

<IfModule mod_php5.c>
php_value include_path ".:/path/to/incdir/"
</IfModule>
<IfModule mod_php4.c> 
php_value include_path ".:/path/to/incdir/"
</IfModule>
<IfModule mod_php3.c>
php3_include_path ".:/path/to/incdir/" 
</IfModule>

Het voordeel van deze manier van aanpakken is dat je in je bestanden gewoon include[_once]($bestand) kunt doen. Je moet dan wel zorgen dat in alle bestanden die '/path/to/incdir/ wel voor alle bestanden via de eigen server-bestandsysteem te bereiken en toegankelijk is!