Beveiligingsexpert: "PHP zal nooit veilig worden"
Beveiligingsexpert Stefan Esser heeft het PHP Security Response Team verlaten omdat het toch geen zin heeft PHP veiliger te maken. Esser beschuldigt de PHP Group ervan dat ze alle pogingen om de populaire scripttaal veiliger te maken saboteren. "Zodra je zegt dat PHP's beveiligingsproblemen door de gebruiker veroorzaakt worden zijn ze je vriend, heb je het over de beveiliging van PHP, dan word je tot persona non grata verklaard. Ik ben gestopt te tellen hoe vaak ik voor een immorele verrader ben uitgescholden".
Voor de doorsnee PHP gebruiker betekent dit dat Esser de trage reactietijd voor het dichten van beveiligingslekken niet meer zal verbergen. Ook zal Esser lekken bekend maken als er geen patches beschikbaar zijn, omdat het PHP Security Response Team er soms maanden over doet om ze te dichten. Verder zullen er ook meer advisories verschijnen, aldus Esser.
moet maar voelen.".
Ik denk dat het wel ten goede komt voor de code, als er
alsnog geluisterd wordt naar de advisories.
Regelmatig 0day exploits voor bekende stukken PHP-code
tegenkomen enz.....
- Unomi -
aan de coders. Veel php coders kunnen voor geen reet coden, en al
helemaal niet security bewust. Als je alle userinput goed filterd, dan is er
qua beveiliging niet veel aan de hand, je kan immers geen bufferoverflow
bij PHP exploiten.
Oftwel Beland, visie standpunt. Want je zou je kunnen
afvragen wat het belang is van Esser om dit op straat te
gooien. Misschien als je dat belang weet veranderd de visie
die Esser doet voorkomen. En dan veranderd het standpunt.
Zal de waarheid niet meer in het midden liggen
Overigens zegt het meer over Esser dan over PHP immers wat heb je aan
iemand die achteraf uit rancune de flapuit gaat uithangen.
Want je zou je kunnen afvragen wat het belang is van Esser
om dit op straat te gooien. Misschien als je dat belang weet
veranderd de visie die Esser doet voorkomen. En dan
veranderd het standpunt. Zal de waarheid niet meer in het
midden liggen
grootste belang voor de PHP gemeenschap niet te missen: als
PHP niet veilig in elkaar steekt en beveiliging gerelateerde
bugs niet tijdig verholpen dan valt te raden wat de
mogelijke gevolgen zijn: hogere graad van kwetsbaarheid
buiten de systeemeigenaar om. Of dit nu in de openheid ligt
of niet doet er niet toe voor het PHP security team als hun
belangen zijn zoals aangegeven. De waarheid is niet te
vinden in de reactie van PHP of Esser maar in het accepteren
van bewijs. Tot nu toe leveren geen van twee de partijen die
en kan voorlopig maar beter zelf gezocht worden naar
acceptabele aanname.
De eerste hit van google op "php vuln"
http://www.theregister.co.uk/2002/07/22/serious_php_vuln_reported/
Ik citeer: The PHP form-data POST handler is susceptible
to a malicious POST request that can trigger an error
condition which, depending on your hardware, can crash the
machine or provide for remote exploitation.
Zoals Hugo al zegt, de PHP binary kan je exploiten,
onafhankelijk van de code van de PHP programmeur. Er worden
constant (security) issues ontdekt in de (C) code van PHP
die wel degelijk te exploiten zijn.
Zelfs PHP geeft deze bugs weer op in haar release notes:
http://www.php.net/ChangeLog-5.php#5.2.0 kijk daar maar bij
"Fixed"
Als ik jou was zou ik gewoon bij php blijven.De java binaire code is nog
erger na mijn mening.
Dus mannen wat raden jullie mij aan? Java en Perl?
Wat is er mis met c en je cgi-bin ?
Voor php bestaan afaik geen formals of uberhaupt een
recommended style, java is bloat en vereist een runtime op
de client en met perl ben je afhankelijk van allerlei
niet-zelf geschreven modules. Met C moet je zelf over al
deze 2/3 de nadelen nadenken. Als het echt secuur moet, dan
heb je toch het liefst ook alles in eigen hand ? Toch ??
Dus mannen wat raden jullie mij aan? Java en Perl?
CGI in C ;-)
Wat is er mis met c en je cgi-bin ?
Dat je ongelofelijk moet oppassen voor buffer overflows? Ik
zou eerder voor Python gaan i.c.m. Django bijvoorbeeld.
java is bloat en vereist een runtime op de client
Dit is ook lekker gezwets. We hebben het over server-side
spullen, waar de client helemaal niets mee te maken heeft.
en met perl ben je afhankelijk van allerlei niet-zelf
geschreven modules.
En met C niet? Laat me niet lachen.
patch + apache module), dat is door hem geschreven en
systemen zoals FreeBSD geven je nu de keus om dat mee te
installeren als je het vanuit de ports doet.
Esser weet heel goed waar hij over praat.
security niet in het woordenboek van Java "programmeurs" (ahum)
voorkomt. De kwaliteit van gedeelde software is bedroevend laag. Ik zie dat
zelfs security producten Java als basis gebruiken in appliances (fout #1)
en er dan maar van uitgaan dat de beschikbare software ook wel geschikt
zal zijn (fout #2). Niet dus. Een soortgelijk verhaal gaat op voor Perl.
Dan heb ik meer vertrouwen in C, ook al moet je daar goed oppassen, als
je eenmaal weet hoe dat moet, maak je geen fouten meer en is het netto
resultaat een veel groter vertrouwen in de veiligheid.
fouten in gevonden worden. in ieder geval moet je gewoon
zelf goed programmeren en er voor zorgen dat je server zo
veilig mogelijk is. dat geld voor elke taal die je gebruikt.
even wisselen en dan veilig zijn is een illussie.
Veel php coders kunnen voor geen reet coden, en al helemaal niet security bewust.
Veel php coders kunnen voor geen reet coden, en al helemaal niet security
bewust.
Visual Basic/C++/.NET sleur 'n pleur "programmeurs". Om de
"traditionele" programmeurs (je weet wel, die met een echte
editor) maar even buiten beschouwing te laten..
echte editors.... Wat dacht je van VI of kladblok
is sowieso geen aanrader meer, PHP is naar mijn idee gewoon
veilig genoeg, veiliger dan ASP & Java. Ik kom heel weinig
Nullbyte exploits tegen voor PHP. ASP, Perl & Java zijn erg
gevoelig voor NullByte injectie. Dus mijn voorkeur is nog
steeds PHP.
En ja in PHP hebben voornamelijk de pre-build functies last
van buffer overflows. Simpel. Controleer altijd de input, en
zorg ervoor dat er een maximum aanzit. Want via een shell
script is het mogelijk oneindig karakters door een functie
te pushen.
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.
