image

Tips voor het beveiligen van PHP

vrijdag 13 augustus 2004, 12:15 door Redactie, 5 reacties

PHP is een populaire scripting taal die op miljoenen servers gebruikt wordt om dynamische websites te maken. Door deze dynamische pagina's hebben gebruikers toegang tot commando's. bestanden en netwerkverbindingen met de server, waardoor er potentiele security risico's kunnen ontstaan. Die risico's kunnen door het correct configureren van de server behoorlijk verminderd worden, maar ook programmeurs zijn verantwoordelijk, zij moeten er namelijk voor zorgen dat hun scripts veilig zijn. Dit artikel gaat dieper in het op het beveiligen van PHP.

Reacties (5)
13-08-2004, 13:03 door Anoniem
opzich zou je alles wel kunnen chrooten.
is veiliger maar leverd een boel extra werk op.

als je proggies moet updaten moet je rekening houden dat je
dan ook weer de upgedate binaries in je chroot omgevingen
ook handmatig allemaal moet gaan updaten.

is dus een beetje afweging of het altijd de moeite waard is.

hou er ook rekening mee dat als je wel op je regular
filesystem terecht wil dat dat niet gaat werken.

dus als je bv een leuk php scriptje hebt dat bv waardes uit
/proc inleest dat dat niet meer werkt
15-08-2004, 09:19 door Anoniem
waarom opend php altijd in een klein schermpje ?

als je php naar htm omdoopt heb je wel vol beeld

beetje vreemd, maar wel lekkerder
16-08-2004, 11:26 door SirDice
maar ook programmeurs zijn verantwoordelijk, zij moeten er namelijk
voor zorgen dat hun scripts veilig zijn.
Dit is het grootste probleem en niet alleen met PHP maar ook met ASP.
16-08-2004, 16:21 door Anoniem
Door Anoniem
waarom opend php altijd in een klein schermpje ?
als je php naar htm omdoopt heb je wel vol beeld
beetje vreemd, maar wel lekkerder

*Zucht* ... Windows gebruikers...
16-08-2004, 16:37 door Anoniem
Dit is een niet al te doordacht atikel.. als de autheur enige kennis van zaken
had, dan zou hij een andere setup aanbevelen, een die veilig is EN goed
performed.. namelijk : Apache + FastCGI + PHP

Je kan de PHP dan zeer makkelijk draaien in een chroot(), en/of op een
andere server en/of onder een andere user als de webserver.

Je kan ook mod_fcgi configureren om een suexec wrapper te gebruiken,
zodat elke user zijn eigen php-processen heeft, die onder zijn eigen uid
draaien.

Bovendien HOEF je niet Apache te draaien.. lighttpd
(http://jan.kneschke.de/projects/lighttpd/ ) of een willekeurige andere
webserver die FCGI kan is ook prima.. is ook meteen een stukje sneller
met content.

Je zou PHP zelfs onder Tux (kernelwebserver van Linux) kunnen draaien
met de cgi : cgi-fcgi bridge.. waarbij desnoods de fcgi op een andere
dedicated server / servers kan draaien .. dit is waarschijnlijk de snelste
oplossing mogelijk met PC-hardware.

Extra mooi is dat je statische content/andere systemen niet plat gaan als je
PHP zichzelf weer eens om zeep geholpen heeft..

Zie: http://wiki.openisis.org/i/view/Php/HowtoFastCgi

(site is plat.. pak Google cache)

http://66.102.9.104/search?q=cache:7VOntzKLME0J:wiki.openisis.org/i/view/
Php/HowtoFastCgi+HowtoFastCgi&hl=en


Het is verbazingwekkend dat iedereen zo bezig is met totale interpreters te
rammen in Apache, terwijl dit in het algemeen een bloated insecure systeem
opleverd (tenzij je iets als Lua gebruikt).

Het enige nadeel is dat je geen rechtsreekse toegang meer hebt tot de interne
API's van Apache.. maar voor een shared platform is dat een voordeel.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.