[PHP] php-bestand legt server "bloot"

[Verwijderd]

Ik heb het volgende probleem.
Ik host mijn website bij een bepaald bedrijf, dat uiteraard ook andere sites host.
Zaterdag heb ik een php-bestandje geupload naar de standaard map (waar index.php etc staat). Via dit bestand wilde ik gemakkelijk alle bestanden bekijken die op mijn site stonden.
Nu blijkt dus dat ik via dit bestand ALLE sites die gehost worden kan bekijken, inclusief php-bestanden.
Voorbeeldje van lijst:

CD> lost+found
CD> opt
CD> chiliasp
CD> spool
CD> log
CD> tmp
CD> packages
CD> cmu
CD> redhat
CD> sites
quota.user - save - 1841.44Kb
quota.group - save - 31.28Kb
CD> httpd
CD> .cobalt
CD> raqbackup
CD> chiliasp.pre-install

Vervolgens kan ik dus via de map sites bij alle websites komen.
Oa deze bestanden kan ik gewoon als php opslaan, inclusief wachtwoord + databasegegevens:
config.inc.php - save - 3.09Kb

Aangezien er ca. 200 sites gehost worden, heb ik mijn provider direct op de hoogte gesteld, afgelopen zaterdagmiddag.
Hieronder volgt de mailwisseling:

>
> ----- Original Message -----
> Sent: Monday, June 16, 2003 2:01 AM
> Subject: Re: mogelijke oplossing probleem?

Wat ik aan onderstaand verhaal kan herleiden is er op het moment geen oplossing voor? Ook niet wat ik mailde?
Ik heb .... offline gehaald, aangezien bijna alles op de
database werkt. Ik voel er weinig voor om de bestanden met wachtwoorden
etc. weer online te zetten, aangezien het een vrij standaard script is en
bijna iedereen er aan kan komen.
Script stond overigens ook gepost op www.phpfreakz.nl, maar ik zie dat
ze hem hebben verwijderd.
Met een kleine aanpassing in het script is het volgens mij wel mogelijk alle
bestanden van alles sites bij jullie te verwijderen. Dan is een ramp
natuurlijk niet te overzien.
Ben zeer benieuwd of er op korte termijn (paar dagen) acties worden
ondernomen.

mvg,
.....

=====================

----- Original Message -----
Sent: Monday, June 16, 2003 1:19 AM
Subject: Re: mogelijke oplossing probleem?

Beste

Bedankt voor je opmerking. Het is de opzet van de server geweest door
Cobalt (eigendom van Sun Microsystems) waarbij het mogelijk is door een
aantal directory's te bladeren. Het is niet toegestaan dit te doen en op het
moment dat wij merken dat er op deze manier misbruik wordt gemaakt van het systeem treden wij hier ook tegen op.
Ik zal je opmerking in de komende dagen eens bekijken, maar we hebben hier in het verleden vaker naar gekeken, op fora op dit onderwerp gezocht en bij Sun nagevraagd. Alles wijst erop dat deze mogelijkheid lastig te verbergen is.
We zijn overigens wel zelf een patch aan het schrijven die dit
probleem deels verhelpt. Tenminste dat is wat ik vorige maand van mijn collega denk gehoord te hebben.

Met vriendelijke groet,

=============

Sent: Sunday, June 15, 2003 6:55 PM
Subject: mogelijke oplossing probleem?

Goede kans dat dit de oplossing is:
; open_basedir, if set, limits all file operations to the defined directory
; and below. This directive makes most sense if used in a per-directory
; or per-virtualhost web server configuration file. This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.
;open_basedir =

punt-komma weghalen en open_basedir op 1 zetten

mvg,

===============

Sent: Sunday, June 15, 2003 3:40 PM
Subject: Re: Reactie via website

Beste

Wat u hieronder beweert lijkt heel ernstig. We zijn erg benieuwd om welk bestand het gaat. Wilt u ons aub laten weten wat u precies doet en welk bestand u publiceert. Stuur ons aub ook die gegevens die u opgeslagen heeft.
Als u dit beantwoord naar het adres waar ik nu vandaan mail, kijkt iemand er heel snel naar.
Alvast bedankt voor de moeite.

Met vriendelijke groet,

============


Sent: Saturday, June 14, 2003 4:08 PM
Subject: Reactie via website

Geachte heer, mevrouw,

ik ben er achter gekomen dat u een ernstige fout hebt gemaakt met de
beveiligings van de websites die bij u draaien.
Via 1 simpel bestandje kan ik van zeer veel sites alles server-side bekijken.
Ik kan bv dus de inloggegevens van databases bekijken.
Ik ben geen kwaad van plan, dus heb alleen wat gegevens ter bewijs opgeslagen en zal dit op verzoek u doormailen.
Uiteraard vind ik dit zorgwekkend. Ik heb ook geen andere mensen op
de hoogte gesteld, omdat dit het imago van u als bedrijf kan
beschadigen.

met vriendelijke groet,

Ik heb vervolgens tot heden geen reactie meer gehad.
Wat raden jullie mij aan te doen?
IK weet niet of ik het bestandje kan plaatsen hier? Op phpfreakz.nl is ie namelijk ook al weggehaald uit de script-library.

Verder zat ik te twijfelen in welk forum dit thuishoort, aangezien het over servers en php gaat. Ik hoop dat ik goed gekozen heb

[Sendy]

Volgens mij kan iedereen zo'n programmaatje maken; of een simpelere vorm, maar goed.

De instellingen zijn inderdaad niet echt optimaal. Zeker niet als je ervoor betaald. Als het op GNU (het is toch een cobalt?) dan is het wel mogelijk om de rechten beter in te stellen. Je hebt niet verteld wat de ingestelde rechten zijn (doe eens het command id, en ls -alF op een belangrijke directory) dan kan je zien wat je rechten precies zijn.

Ik kan me voorstellen dat die rechten zijn zoals ze zijn om de 'mooie' webinterface van de cobalt goed te krijgen. Het is lastig, maar zeker veel werk, om dat goed te krijgen.

Ik zou daar weggaan als ik jouw was, of in ieder geval niet meer op hun cobalts hosten. Dat iedereen jouw wachtwoorden voor je database kan lezen is echt onacceptabel. Misschien kan je met je handige scriptje zelf wel de rechten goed instellen? Als je dat wilt kan ik je er wel doorheen leiden.

[ Voor 2% gewijzigd door Sendy op 16-06-2003 18:43 . Reden: Verkeerde 'ei' in lijden :'( ]

[Verwijderd]

Wat raden jullie mij aan te doen?

Een andere host. Het lijkt me dat deze host niet echt van een wenselijk nivo is.

[Verwijderd]

Zelf heb ik dus weinig verstand van servers .
Ik kan ook alleen door hun mappen bladeren.
Over rechten enz weet ik verder niets.

Ik ben inderdaad op zoek naar een nieuwe hostingprovider, want dat zoiets kan gebeuren is slecht, maar ok, maar dan ook vooral de manier van het "reageren" staat mij erg tegen.

Het was ook een vrij goedkoop pakket, gelukkig heb ik er geen professionele site staan, maar eentje van een sportvereniging

Maar dat ze in principe zeggen:
tja, jammer, maar we kunnen er niets aan doen

[ Voor 29% gewijzigd door Verwijderd op 16-06-2003 18:46 ]

[we_are_borg]

Ik weet waar het over gaat en in de cobalt mailing list is toen een oplossing aangdragen, deze schijnt niet 100% te zijn maar afdoende om het bovenstaande tegen te gaan. Ik heb zelf nooit gekozen voor die oplossing aangezien m'n cobalt alleen intern te benaderen is.

[rollebol]

Ik raad je aan de manual-pagina van chmod er eens op na te slaan.

Dat de broncode van de andere hosts op de site leesbaar is, is niet ongebruikelijk. Het is zaak om te zorgen dat de wachtwoorden die jij gebruikt niet zichtbaar zijn voor de andere gebruikers van dezelfde computer. Dit kan je voorkomen door het bestand waar deze wachtwoorden in staan voor anderen onleesbaar te maken.

Overigens kan de hosting provider ook een zogenaamde 'sandbox' maken voor iedere gebruiker, om dit probleem tegen te gaan. Het kan nog steeds geen kwaad om zuinig met je wachtwoorden om te springen. De schuld afschuiven op de provider vind ik wat kort door de bocht. Dat de andere klanten van de provider ook hun wachtwoord leesbaar in de code opnemen, valt ook hen te verwijten.

[ Voor 33% gewijzigd door rollebol op 16-06-2003 18:49 . Reden: sandbox-verhaal ]

[Sendy]

Maar wat weet je wel van computers dan?
[helpdesk mode]
Hoe werkt dat scriptje? Krijg je een invulvakje waarin je cd en dir/ls kan tikken? Anders moet je daar eens naar een leuke directory gaan met cd, en daar dan het commando
ls -alF . geven.
[/helpdesk mode]

Het antwoord pasten graag

Pas ook op dat je scriptje (zeker niet als het heel powerful is) niet voor iedereen bereikbaar is!

[ Voor 4% gewijzigd door Sendy op 16-06-2003 18:51 ]

[Verwijderd]

Alleen het feit al dat er zo lax gereageerd wordt is een reden om te verkassen. Als klant hoef je toch niet te gaan vertellen hoe de vork in de steel zit aan je host.

[rollebol]

Ik zeg alleen maar dat je zelf je zaakjes ook op orde moet hebben. En dat veel andere hosts het ook zo doen als hierboven wordt geschetst. Dus als je verkast, verkas dan zorgvuldig. Want de kans is niet eens klein dat je verkast naar iemand die het net zo heeft geconfigureerd.

[Verwijderd]

Het is gewoon een php-bestand dat ik plaats. Via www.naam.nl/bekijk.php kan ik dan door een directories bladeren. Puur webbased dus.
Ik weet of ik hem hier mag plaatsen? Het is wel een vrij "standaard" script volgens mij.

@ Rollebol:
De wachtwoorden en database gegevens staan gewoon in php-bestanden, wat normaal dus toch gewoon door de server verwerkt moet worden?

[ Voor 28% gewijzigd door Verwijderd op 16-06-2003 18:55 ]

[Sendy]

Ik denk wel dat klanten kunnen helpen bij het vinden van problemen. Dit is echter zo sloom dat je daar weg moet gaan (of van de cobalt af, zoals eerder gezegd). Dit staat misschien wel in de voorwaarden? Hoe kom je anders te weten of het verboden is in bepaalde directories te kijken?

[Verwijderd]

rollebol schreef op 16 June 2003 @ 18:53:
Ik zeg alleen maar dat je zelf je zaakjes ook op orde moet hebben. En dat veel andere hosts het ook zo doen als hierboven wordt geschetst. Dus als je verkast, verkas dan zorgvuldig. Want de kans is niet eens klein dat je verkast naar iemand die het net zo heeft geconfigureerd.

Helemaal mee eens rollebol. Een goede hostingprovider is belangrijker dan de meeste mensen denken.

[Sendy]

Oke, dat is niet zo heel krachtig natuurlijk.

Wat Rollebol bedoeld is dat je misschien de rechten zo kan instellen dat de bestanden waar wachtwoorden in staan (die jij van iedereen kan lezen) niet door iemand anders te lezen zijn.

Het probleem is dat de webserver nog bij je pagina's moet kunnen komen

[ Voor 16% gewijzigd door Sendy op 16-06-2003 19:00 ]

[Verwijderd]

Thuissendy schreef op 16 juni 2003 @ 18:58:
Oke, dat is niet zo heel krachtig natuurlijk.

Wat Rollebol bedoeld is dat je misschien de rechten zo kan instellen dat de bestanden waar wachtwoorden in staan (die jij van iedereen kan lezen) niet door iemand anders te lezen zijn.

Het probleem is dat de webserver nog bij je pagina's moet kunnen komen

Thnx, dat werkt iig.
Ik heb de rechten op mijn config.php ingesteld op 711, nu kan ik iig niet meer via dat bestandje config.php bekijken.

[Sendy]

En je site doet het nog? Ik zou er trouwens toch weggaan. Als je niet snapt wat je doet dan worden de instellingen niet snel goed. (he! is dat een spreekwoord?) En het bedrijf gaat je vast niet helpen.

[frickY]

Je kan ze ook onder druk zetten door de webmasters van die 200 andere sites te mailen over hun lekke server. Als je hosting opeens klachten krijgt van alle klanten zullen ze wel n professionele oplossing moeten zoeken.

[Sendy]

Ik zou een beetje oppassen. Misschien kan je een klein beetje dreigen, maar zij hebben al gedreigd je van hun cobaltje te gooien! En je kan beter vervangende hosting hebben voordat je wordt verbannen.

[Sjaaky]

Ik heb de rechten op mijn config.php ingesteld op 711

En dat werkt?
Je kan ook de directory op 700 of 770 instellen.

[finnyhut]

Bestanden waar de webserver bij moet kunnen moeten world readable zijn, dus ook de bestanden waar wachtwoorden voor je database in staan. Chmodden werkt dus niet voor dit 'probleem'. Er zijn overigens maar weinig hosts die een goede chroot jail voor al hun klanten hebben (dwz dat je alleen bij je eigen bestanden kunt), het is geen makkelijke klus. En bovendien is het nooit 100% veilig. Bij zeer veel hosts (ook bij het goed aangeschreven nxs.nl) kan je vrolijk door ieders bestanden wandelen. Domweg dus omdat alle website bestanden voor iedereen leesbaar moeten zijn omdat de webserver (apache) als nobody draait.

[MikeN]

Ik lees hier toch wat vage dingen. Het verhaal zit als volgt. PHP draait normaal gesproken als module in apache (mod_php4 enzo). PHP wordt dus onder dezelfde user uitgevoerd als de webserver. Aangezien de webserver bij alle bestanden moet kunnen, kan PHP dit dus automatisch ook. Hiervoor is een oplossing bedacht in de vorm van de zogenaamde safe mode. Normaal gesproken heeft een hosting provider deze aan staan zodat mensen niet elkaars config kunnen bekijken en zo wachtwoorden kunnen stelen. Dit is blijkbaar in dit geval niet zo, wat misschien expres zo is gedaan, of gewoon een configuratiefout is.

Het is btw wel degelijk mogelijk om het dicht te krijgen. De userdirs chown je naar user.apache-group en chmod je op 710. PHP in safe mode en het staat aardig dicht

[Verwijderd]

CModden werkt idd niet, ik had verkeerd gekeken
Verder werken ze nog met PHP Version 4.1.2 en staat safe_mode off.
Verder had ik ook gehoord dat het volgende kon helpen:
open_basedir = 1 in php.ini

Dit heb ik ze doorgemaild, maar schijnbaar hebben ze dit niet geprobeerd.
Ik wacht morgen nog af, anders ga ik eens rondmailen.

[chem]

Zelfs met safe_mode is het wellicht mogelijk om andere files uit te lezen.
Dit is 1 van de redenen waarom source veelal met bv Zend wordt gecompiled.

[sebas]

Dit is ook een niet echt nieuw probleem, en imo nogal vaak inherent aan webhosts draaiende op Linux. Zodra meerdere users gebruik maken van dezelfde server moet deze server ook alle bestanden (incl. wachtwoorden) kunnen lezen, een chroot jail en wat aanpassingen in de php.ini bieden misschien wel wat mogelijkheden om het dicht te timmeren, maar echt veilig krijg je het denk ik niet.

Dit soort dingen zijn dan ook een belangrijke reden waarom een dedicated server vaak wel zinvol is. Een multiuser omgeving zal altijd compromissen moeten maken tussen veiligheid en gebruiksvriendelijkheid / bruikbaarheid.

Ik vind eigenlijk ook dat de topicstarter hier iets te fel reageert ten opzichte van het hostingbedrijf. Ok, het is allesbehalve veilig, maar als dat dermate belangrijk voor je is dan kun je misschien beter aan een dedi servertje denken met een openBSD install of iets dergelijks. Zou je iets meer weten over de problematiek dan had je misschien betere voorstellen dan "Ik heb ook gehoord dat dit en dat aan moet staan" of iets in die trant.

Ik vind het trouwens ook nogal lomp dat je met dermate weinig ervaring op hun servers gaat prutsen, dat zou je zelf ook niet willen. Je huurt de webspace niet in voor een security audit, maar om een site te hosten. Zorg er gewoon voor dat je applicatie goed dicht is, dat er zo weinig mogelijk wachtwoorden in je scripts staan, en vooral dat deze qua permissies goed dichtgetimmerd zijn. dat je geen world-writable bestanden moet plaatsen is denk ik vanzelfsprekend.

[ Voor 43% gewijzigd door sebas op 17-06-2003 00:43 ]

[Verwijderd]

Via het bestandje kon ik alleen alles lezen en opslaan, niet wijzigen of verwijderen, wat ook niet mijn bedoeling is.
Maar goed, dan misschien een tip voor mij?
Ik gebruik 1 config.php met dus de gegevens voor de database-connectie. Hoe kan ik dat bestandje dan dermate beveiligen dat anderen, die bv via zo'n soort file als mij mijn site bekijken, dus niet mijn wachtwoord kunnen achterhalen en zo mijn database kunnen gaan benaderen?

Op zich vind ik het een vrij logische reactie dat ik mij verwonder over het feit dat het kan en dat ze zo traag reageren.

Ik krijg wel een email van ze dat het niet te veranderen is, maar ik verbaas me dus dat ze mij niet instrueren hoe ik mijn wachtwoorden kan beschermen?

[Gerco]

Verwijderd schreef op 17 juni 2003 @ 01:25:
Ik krijg wel een email van ze dat het niet te veranderen is, maar ik verbaas me dus dat ze mij niet instrueren hoe ik mijn wachtwoorden kan beschermen?

Als de webserver het kan lezen, kan iedereen het lezen via een PHP script. Het is dus niet mogelijk om te rechten zo in te stellen dat ze het niet kunnen lezen.

Het enige wat je kunt doen is je wachtwoord encrypted neerzetten en decrypten als je het gebruikt, hier heb je echter weinig aan, want ook het decryptie algoritme en de decryptie key kunnen ze lezen.

Wat ze kunnen doen is voor elke user op die bak een <Directory> directive in de apache configfile zetten, op deze manier:

code:

<Directory /home/dir/van/de/user>
  php_admin_value open_basedir /home/dir/van/user
</Directory>

Ja, dit is veel werk, nee dit is niet perfect (als je bijvoorbeeld programmas kan executen kun je gewoon exec("cat /etc/passwd") doen), maar het werkt best aardig op mijn server.

Zo lang je geen duizenden sites op 1 bak zet blijft dit best beheersbaar, maar als er iemand een betere oplossing heeft, naast safe-mode, wil ik die graag horen.

[Stewie!]

Thuissendy schreef op 16 June 2003 @ 18:50:
Pas ook op dat je scriptje (zeker niet als het heel powerful is) niet voor iedereen bereikbaar is!

kijk eens rond op www.php.net, dan zie je zo hoe je dit scriptje maakt. Die mensen die de cobalt hebben geconfiged hebben zeker nooit van users gehoord he

[Icheb]

Ik heb dit probleem ook een tijd gehad bij 8 (!) domeinen die dmv een cobalt server werden gehost.
Inmiddels heb ik het opgelost door naar een andere hostingprovider te gaan nadat iemand mij de wachtwoorden uit mijn config.php stuurde per e-mail.
Ik heb het script zelf even geprobeert op de nieuwe hoster, hier lukt het gelukkig niet meer. (De server is een rh7.2 met PLesk om alles te regelen als ik me niet vergis)

Dit is dus inderdaad een van de redenen waarom open_basedir en safemode wel makkelijk zijn...

[koli-man]

Verwijderd schreef op 17 June 2003 @ 01:25:

Ik gebruik 1 config.php met dus de gegevens voor de database-connectie. Hoe kan ik dat bestandje dan dermate beveiligen dat anderen, die bv via zo'n soort file als mij mijn site bekijken, dus niet mijn wachtwoord kunnen achterhalen en zo mijn database kunnen gaan benaderen?

Een hele simpele, natuurlijk nooit genoeg, maar je kunt je config.php een andere niet standaardnaam geven bv blaatmin.php . Je wachtwoorden e.d. moet je natuurlijk encrypted erin zetten.

[Gerco]

koli-man schreef op 17 June 2003 @ 08:54:
Je wachtwoorden e.d. moet je natuurlijk encrypted erin zetten.

Zoals ik al zei, encryptie is volkomen nutteloos. Aangezien een kwaadwillende gewoon je hele site kan downloaden, kan hij ook je wachtwoord decrypten, want als je site het kan, kan hij het ook.

[SchizoDuckie]

Dit is gewoon een erg lompe setup zo met zo'n standaard kobalt bak.

Ik heb eens van www.a4u.nl (ook een webhoster) waar ik een siteje heb draaien het volledige klantenbestand (gebruikersnamen, wachtwoorden, NAW, etc) van de webhoster + financiele vooruitzichten tot aan z'n visitekaartje aan toe gedownloadt doordat ik iedereen z'n homedirs kon browsen.

Die kneus had gewoon een zipje in z'n wwwroot staan met al deze gegevens erin.

Maja, dat kan je verw88 van een goedkope host

[ Voor 8% gewijzigd door SchizoDuckie op 17-06-2003 09:15 ]

[GiLuX]

gewoon in elke virtual host directive van de webserver even restricties aan zetten en dit soort scriptjes maken geen kans meer

php_admin_value safe_mode 1
php_admin_value open_basedir /home/users/auser

[esf]

Kan je config.php niet in een directory zetten die je met .htaccess beveiligt zodat niemand er van kan lezen via de webserver, en dan config.php vanuit een ander bestandn includen? Als dat kan dan krijgen ze alleen het bestand met <? include("dir/config.php"); ?> te zien.

[Gerco]

esf schreef op 17 June 2003 @ 09:52:
Kan je config.php niet in een directory zetten die je met .htaccess beveiligt zodat niemand er van kan lezen via de webserver, en dan config.php vanuit een ander bestandn includen? Als dat kan dan krijgen ze alleen het bestand met <? include("dir/config.php"); ?> te zien.

.htaccess werkt als je via een URL die dir opvraagt, dit gebeurt niet. De URL van het PHP script wordt opgevraagd en het PHP script leest gewoon het filesystem, komt geen webserver aan te pas.

[ Voor 3% gewijzigd door Gerco op 17-06-2003 09:55 ]

[Goof2000]

[leek modus]
Moet je hier nou erg voor oppassen, gebeurt dit bij veel hosting of is het alleen een bepaalde combinatie?
[/leek modus]
Ik zoek rond voor een hosting en hoe kan ik dit dan zoveel mogelijk uitsluiten?

[Coolhva]

kan de hosting provider geen php module schrijven met encryptie o.i.d. zodat je het wachtwoord wel gecodeerd kan opslaan en dan met een functie decrypten.

Dan houdt die module rekening met je home dir o.i.d. zodat iemand anders op die server niet kan decrypten???

edit:

En je config file .config.php noemen (zodat hij verborgen is)? Is niet oplossing maar maakt wel moeilijker.

[ Voor 20% gewijzigd door Coolhva op 17-06-2003 10:29 ]

[SchizoDuckie]

de hosting moet gewoon de feature van linux uitzetten waardoor iedereen elkaar's homedir kan bekijken, of gewoon debian installen daar wordt 't je automagisch gevraagd

[Stewie!]

Gerco schreef op 17 juni 2003 @ 09:55:
[...]

.htaccess werkt als je via een URL die dir opvraagt, dit gebeurt niet. De URL van het PHP script wordt opgevraagd en het PHP script leest gewoon het filesystem, komt geen webserver aan te pas.

en dan schrijft hij een bestandje waarin die include wordt geoutput

[Icheb]

Papa Eend schreef op 17 June 2003 @ 10:30:
de hosting moet gewoon de feature van linux uitzetten waardoor iedereen elkaar's homedir kan bekijken, of gewoon debian installen daar wordt 't je automagisch gevraagd

Maar het lijkt me dat als je gewone standaard homedirs gebruikt dat niemand behalve root ze allemaal kan lezen, ok, als je dan apache als root gaat draaien...
Maar anders zit je toch gewoon in een chroot omgeving (als het goed is) ?
(of loop ik nou gek te doen ? )

[Neman]

Gerco schreef op 17 June 2003 @ 09:05:
[...]

Zoals ik al zei, encryptie is volkomen nutteloos. Aangezien een kwaadwillende gewoon je hele site kan downloaden, kan hij ook je wachtwoord decrypten, want als je site het kan, kan hij het ook.

Wie zegt dat de site het decrypt? Een goed systeem encrypt alleen het ingevulde wachtwoord en vergelijkt dat met het opgeslagen wachtwoord, dat dus ook encrypted is. Wil je dan het wachtwoord achterhalen, dan zul je dat met brute force moeten doen, een tijdrovende klus.

Verder is in het algemeen het een en ander best op te lossen met CHMOD. Zelf zet ik alle gebruikers en PHP/Apache in een aparte group. Vervolgens op de gebruikersdirectories CHMOD 705 en op de files in die directories CHMOD 604. Op die manier zal de group van de gebruikers totaal geen rechten hebben (men kan dus niet bij elkaars dirs/files), maar de gebruiker zelf kan er wel in, doordat de owner de juiste rechten heeft. Op deze manier heb je je shell in ieder geval veilig.

[ Voor 17% gewijzigd door Neman op 17-06-2003 14:51 ]

[Soultaker]

Neman schreef op 17 June 2003 @ 14:47:
Verder is in het algemeen het een en ander best op te lossen met CHMOD. Zelf zet ik alle gebruikers en PHP/Apache in een aparte group. Vervolgens op de gebruikersdirectories CHMOD 705 en op de files in die directories CHMOD 604. Op die manier zal de group van de gebruikers totaal geen rechten hebben (men kan dus niet bij elkaars dirs/files), maar de gebruiker zelf kan er wel in, doordat de owner de juiste rechten heeft.

Dat klopt niet; alle gebruikers kunnen dan gewoon elkaars bestanden lezen (met daarin dus eventueel gevoelige gegevens als databasewachtwoorden en dergelijke). Een betere oplossing lijkt me om juist alle bestanden op 750/640 in te stellen, en Apache vervolgens alle scripts uit te voeren onder de gebruiker die er de eigenaar van is. Dat lijkt me de enige goede oplossing, maar het is wat lastig met FTP clients en dergelijk die by default andere permissies gebruiken.

Hiervoor is het noodzakelijk dat Apache als root draait. Dat hoeft niet echt een probleem te zijn (zeker niet in combinatie met een jail-constructie), mits je er zeker van bent dat alle scripts altijd onder de juiste gebruiker (en dus niet per ongeluk onder de root user) draaien!

[ Voor 15% gewijzigd door Soultaker op 17-06-2003 14:53 ]

[Neman]

Soultaker schreef op 17 juni 2003 @ 14:51:
[...]

Dat klopt niet; alle gebruikers kunnen dan gewoon elkaars bestanden lezen (met daarin dus eventueel gevoelige gegevens als databasewachtwoorden en dergelijke).

Zelf gebruik ik deze methode en het is in de shell dan echt niet mogelijk om bij elkaars files te komen. PHP kan dit wel, maar dat is op te lossen met php_safe_mode (toch?).

[curry684]

Verder zat ik te twijfelen in welk forum dit thuishoort, aangezien het over servers en php gaat. Ik hoop dat ik goed gekozen heb

Goed genoeg, je hebt nu een discussie los over de beveiligingsaspecten van PHP als taal Mocht je meer interesse hebben in de securityaspecten wat betreft de hostingprovider/ISP, Cobalt-Raqs als host machines en hackability had je beter in Internet & Telefonie kunnen zijn. Laat maar weten als je een kick die kant op wilt.

[Verwijderd]

Laatste mailtje dat ik ontving van mijn hostingprovider

Beste ....,

Het probleem is al jaren bekend (volgens mij sinds 1998). Het opzetten van
het systeem op deze wijze heeft nadelen, maar ook veel voordelen. Om achter
de exacte reden van deze configuratie te komen, kun je terecht bij Sun
Microsystems.

Het is niet mogelijk bestanden van de server te verwijderen met dit script.
Daar heeft het script onvoldoende rechten voor.

Je kunt je vervolgvragen naar mijn collega's van de Helpdesk sturen op
..... Ik kan hier helaas verder geen tijd meer
aan besteden. Ik heb je namelijk alle nodige informatie gegeven.

Met vriendelijke groet,

Ik ga dus op zoek naar een andere hostingprovider

Verder worden er voor mij wel interessante zaken genoemd. Misschien kan ik de hostingprovider eens op de hoogte stellen van deze topic, misschien hebben ze er wat aan.

[drm]

tussen de regels door lezen zegt ook genoeg

Ik kan hier helaas verder geen tijd meer
aan besteden. Ik heb je namelijk alle nodige informatie gegeven.

Iemand met zo'n attitude zou ik niet eens een product bij af willen nemen...

---

Maar goed, daarmee is het iig geen P&W vraag meer Ik zou zeggen, als je cobalt ter discussie wilt stellen kun je in Software Algemeen terecht, voor hosting vragen Internet & Telefonie

vergeet niet om de FAQs van betreffende fora door te nemen alvorens je daar post