Tips voor het beveiligen van PHP
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.
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
als je php naar htm omdoopt heb je wel vol beeld
beetje vreemd, maar wel lekkerder
voor zorgen dat hun scripts veilig zijn.
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...
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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
