Veiligheidsspecialist PHP stopt ermee

PHP-veiligheidsspecialist Stefan Esser heeft per direct zijn vertrek aangekondigd als lid van het PHP Security Response Team. Volgens Esser is het onmogelijk om de veiligheid van PHP 'van binnenuit' te verbeteren.

Volgens de veiligheidsexpert wordt men 'persona-non-grata' verklaard zodra kritiek wordt geleverd op de veiligheid van PHP. Het verhelpen van bekende veiligheidsproblemen duurt volgens Esser veel te lang, waardoor gebruikers onnodig lang kwetsbaar zijn. Overigens wil Esser gewoon doorgaan met het testen van PHP op veiligheidsproblemen, maar hij voegt hier wel aan toe dat hij niet meer zal wachten met publicatie wanneer er niet binnen een redelijke termijn een patch beschikbaar is. Volgens Esser zal dit betekenen dat hij meer vulnerabilities zal onthullen, waarbij de traagheid van het PHP securityteam niet meer zal worden verhuld door het uitstellen van publicatie. Een andere reden dat Esser vertrekt is dat PHP-ontwikkelaars te weinig aandacht besteden aan veiligheid. Volgens hem worden opgeloste veiligheidsproblemen in latere versies weer geïntroduceerd en worden voorstellen om de veiligheid te verbeteren door de ontwikkelaars massaal afgewezen.

Uiteraard is niet iedereen binnen de PHP-ontwikkelaarsgemeenschap het eens met de visie van Esser. Volgens Zeev Suraski, een van de hoofdontwikkelaars van PHP en cto van Zend, is PHP niet bijzonder onveilig. Volgens Suraski is het wel een probleem dat PHP wordt gebruikt door veel onervaren programmeurs waardoor veel PHP-applicaties veiligheidsfouten bevatten. Esser is het er wel mee eens dat er veel onervaren programmeurs PHP gebruiken, maar hij is toch van mening dat er bepaalde onderdelen van PHP onnodig onveilig zijn en voor structurele problemen zorgen. Suraski hoopt echter dat Esser tot bezinning komt en terugkeert in het PHP securityteam.

Reacties (59)

[YopY]

Een programmeertaal is min of meer zo veilig als diegene die er mee werkt. Echte beveilgingsfouten in PHP zijn fouten in de core, niet in fouten in het gebruik daarvan.

Naast het oplossen van bugs in de core (met de veiligheid enzo) zouden ze (PHP team / site) veel meer nadruk moeten leggen op hoe een gebruiker een veilige site kan maken. Ook zouden ze het makkelijker moeten maken om inderdaad veilige applicaties te maken voor de nieuwere gebruikers die nog niet jarenlang op bijvoorbeeld t.net allerlei tips voor het beveiligen van hun PHP applicatie gelezen hebben.

Ze zouden op zich een soort SDK voor PHP moeten vrijgeven, waarmee de beginnende gebruiker gelijk uit de voeten mee kan. Hierbij valt o.a. PHP zelf, een lichtgewicht webserver en databaseprogramma, maar belangrijker een verzameling makkelijk te gebruiken, maar vooral veilige klassen voor de standaard dingen zoals databaseverbinding, etcetera. Ze zijn er op het moment wel, maar ik kan me indenken dat de beginnende gebruikers daar niet aan willen, of het gewoon niet kunnen vinden.

Het al eerder genoemde Ruby on Rails dwingt de gebruiker bijna om een webapplicatie op een bepaalde manier te gebruiken, en daar zit de basis van beveiliging al in. Het zou niet verkeerd zijn om ook zo'n pakket bij de SDK van PHP te leveren.

Probleem is dat er heel veel geruzie zou komen over welk pakket nu het beste is, of wat het beste zou werken, dat soort dingen.

Daarnaast een IDE, zoals NetBeans nu bij Java geleverd word. PHPEclipse zou het op zich wel kunnen doen, maar dan als toevoeging zouden ze er waarschuwingen bij moeten doen als een bepaalde manier om iets op te lossen niet veilig geacht wordt.

Ik bedoel, het moet niet al te moeilijk zijn om voor een editor na te gaan of er gegevens in een mysql string zijn die nog niet door addslashes of een vergelijkbare functie gehaald zijn. Denk ik zo, tenminste.

Maarja.

[Laurens-R]

Dat is dus idd iets wat ik mis in PHP. Een framework/API waar men tegenaan kan werken. Zeker nu PHP soort van OOP ondersteunt zou het fijn zijn als er een framework in PHP zat die standaard veelgebruikte datastructures aanbied zoals LinkedLists, Binary Trees en bijvoorbeeld standaard data objecten die het communiceren naar diverse databases (MySQL, MSSQL, Oracle, etc) standariseerd en gemakkelijker maakt.

En misschien is een framework voor het genereren van een UI die gekoppeld kan worden met al die objecten ook wel fijn (icm AJAX technologie?)... Nu zullen hiervoor vast wel al PHP modules bestaan, maar ik zou ze ook echt in de standaard willen zien. Soort van .Net framework, maar dan voor PHP zeg maar.

Op deze manier kan je ook je security voor databases, formulieren, etc etc voor een groot deel automatiseren imho

[Anoniem: 139822]

Er zijn al behoorlijk wat frameworks, zoals Symfony, Cake, Zend Framework, dan heb je nog Pear die veel interesante libraries bied, Pecl voor modulaire extensies op de PHP-Core en SPL, die met PHP 5.2 ook weer uitgebreidt is.

Hoe de integratie is tussen Zend Studio en Zend Framework weet ik op die moment niet, maar het is te verwachten dat als het nog niet op elkaar aangesloten is, dat dat in de toekomst vast gaat gebeuren.

Of een IDE of Framework daadwerkelijk iets bijdraagt aan de security betwijfel ik, ik stel bepaalde veiligheids eisen liever in via de php-ini of domein/map-configuraties.

Een beetje programmeur weet dat ie bezoekers niet zomaar moet vertrouwen en alle user-input en externe-data dient te controleren of filteren

[sjons]

Zend Studio 5.5 heeft inmiddels ondersteuning voor Zend Framework, oa.

[Robinski]

en waar is PEAR dan voor?
http://pear.php.net

zijn redelijk "standaard" implementaties om die dingen te doen.

[Tyf]

Das nu net het probleem. Dit is een van de zoveeel php "framework-achtige" toestanden. De ontwikkelaars zouden 1 moeten kiezen. En standaard in php steken. Vroeger vond ik asp en php juist hetzelfde. Wie nu nog in php iets maakt. Kweet het niet. Asp.net en jsf zijn echt mega goed. Kun je rap iets mee maken, goed, deftig framework en toch flexibel. Belasting op server daar spreken we nie over

[Sfynx]

PRADO heeft veel overeenkomsten met ASP.NET , alleen dan voor PHP. Ook 1 van de vele frameworks voor PHP dus, wel eentje die me erg bevalt. Voornamelijk gefocused op presentatie, dus alle dingen als repeaters, datagrids, inputvelden e.d. zijn allemaal in een OO-model gegoten, worden onthouden d.m.v. een view- of control state en zijn gekoppeld aan de PHP-objecten. Ook compleet en fatsoenlijk OO en geen gebruik van deprecated rotzooi e.d., lager dan PHP 5.1 werkt er niet mee.

http://www.pradosoft.com

[cytherea]

Bij Zend proberen ze dit wel.

framework.zend.com

Klinkt veelbelovend al zeg ik het zelf. En ik gebruik het ook al in een applicatie.

[BCC]

Ruby on Rails is inderdaad geweldig! Je kan dat alleen volgens mij nooit namaken in PHP omdat Ruby een full-fledged programmeer taal is en handige dingen leent uit scripttalen. PHP blijft een scripttaal die nu handige dingen leent uit Programmeer talen...

[Anoniem: 199596]

Mag ik je voorstellen aan CakePHP
Dit is een framework voor PHP gebaseerd op Ruby on Rails. Ik heb zelf nooit met RoR gewerkt maar CakePHP schijnt erg veel op RoR te lijken.

[crisp]

Onzin, PHP is als taal Turing-compleet wat wil zeggen dat je er alles in kan uitdrukken. Een RoR-implementatie in PHP is dus wel degelijk mogelijk.

Dat een taal runtime geinterpreteerd wordt ipv eerst gecompileerd moet worden is de enige reden waarom het een 'script-taal' genoemd wordt, maar dat wil niet zeggen dat het geen full-fledged programmeertaal is.

[onox]

Volgens mij mis je toch wel features als blocks, hashes, etc. Dat PHP en Ruby beide Turing-compleet zijn betekent alleen dat je met beide talen dezelfde berekeningen kunt uitvoeren. De manier waarop echter... die verschilt.

Bij PHP mis ik ook een standaard Collections API en andere libs. Nu zit daar met SPL en PDO wel wat verandering in, maar ik zit nog steeds opgescheept met 3000 functies met een inconsistente naamgeving.

[crisp]

Dat doet niets af aan het feit dat je in PHP een RoR implementatie zou kunnen schrijven

Wat jij beschrijft is niets anders dan gewoon een voorkeur voor bepaalde constructs die je in PHP anders zal moeten oplossen. Dan begeef je je op een zeer subjectief vlak want dan zeg je eigenlijk gewoon 'PHP zou meer op Ruby moeten lijken'. Als je er zo over denkt dan moet je gewoon niet in PHP programmeren maar enkel in Ruby

Ik ben het overigens wel met je eens wat betreft de overload aan functies en inconsistenties daartussen

[Janoz]

Toch moet ik het met je oneens zijn. Ja, php is wel turing compleet, maar voor een RoR achtige implementatie is meer nodig. Belangrijkste onderdelen die missen in php zijn scopes groter dan request. Die heeft php niet (nee, hun session implementatie wil ik niet eens een scope noemen, dat is gewoon een serializer/deserializer).

Als je enkel requestscope hebt kun je daar neit utispringen. De enige manier om een RoR achtige implementatie te maken is door ook de webserver volledig in php te gaan bouwen zodat je uiteindelijk 1 script hebt dat constant draait. (In dat geval loop je trouwens weer tegen het probleem aan dat php niet (of nauwlijks) threads heef)

[Anoniem: 175233]

Een programmeertaal is min of meer zo veilig als diegene die er mee werkt

Daar ben ik het niet helemaal mee eens. Natuurlijk heeft de programmeur heel veel invloed op de veiligheid. Maar een programmeer taal kan wel degelijk inherent veiliger of onveiliger zijn dan andere talen, door de soort constructs die het toelaat.

De mogelijkheid om strings als code uit te voeren is uiteraard een enorm veiligheids risico. Maar wel iets dat erg veel gebruikt wordt...

Maar ook het overdadig gebruik van pointers is een veiligheids risico. Heel veel van de security issues in applicatie software zijn bijvoorbeeld daarop terug te voeren. (In die zin is Pascal inherent veiliger dan C)

[DataGhost]

Mooi, dit kan de kwaliteit alleen maar ten goede komen, dunkt me. Als er op deze manier druk op gezet wordt zullen de developers wel MOETEN handelen en als ze dat niet doen komt er vast wel iemand anders die een patch instuurt
Wel jammer dat de mentaliteit van de developers zo slecht is, hopelijk verandert dat dus. Dit kon namelijk wel eens doorslaggevend zijn in bepaalde afwegingen van bedrijven.

[GiantRabbit]

Druk....?

Ik denk juist dat er enkele developers een gat in de lucht springen. Zijn ze eindelijk van die zeurkous af

De kwaliteit zal er eerder op achteruit gaan.

[thegve]

Als hij nu de beveiligingsproblemen publiceert, en ze reageren er niet snel genoeg op, dan is vanzelf een hacker die ze misbruikt, krijgt PHP een nog slechtere naam op beveiligingsgebied en blijken er nog genoeg andere talen beschikbaar om de nu sterke positie van PHP over te nemen (Python, Ruby).

[Olaf van der Spek]

Volgens Zeev Suraski, een van de hoofdontwikkelaars van PHP en cto van Zend, is PHP niet bijzonder onveilig.

Dat klinkt lekker.
Ik ben niet bijzonder ontevreden.

Discussieren met bepaalde PHP developers is trouwens ook lastig, voor je het weet ben je gebanned van de bug tracker.

[Kalief]

reden dat Esser vertrekt is dat PHP-ontwikkelaars te weinig aandacht besteden aan veiligheid

Olifantdeskundigen vinden dat er te weinig aandacht wordt besteed aan olifanten. Territoriumdrift.

worden voorstellen om de veiligheid te verbeteren door de ontwikkelaars massaal afgewezen

Dus zijn al die ontwikkelaars gek? Als voorstellen massaal worden afgewezen moet er misschien nog eens kritisch naar die voorstellen worden gekeken.

[onox]

De meerderheid is niet altijd het slimst.

[Anoniem: 93798]

Ik noem mezelf geen senior programmer maar het newbie stadium ben ik al lang voorbij, wat ik vaak merk bij mensen die net met PHP begonnen zijn is dat ze vooral om te beginnen al een basis algemene pc kennis missen. Zo kreeg ik van de week de vraag nog waarom iemand zijn php files "niet werkten" ... de hosting (de 50 MB die je krijgt van je ISP) ondersteunde gewoonweg geen PHP
Verder zie ik vaak fouten in de trend van "index.php?pagina=gastenboek" ... met dan een code in de trend van
<?php
$include = $_GET['pagina'];
include('includes/$include');
?>
en zo kunnen we nog even doorgaan

Dat PHP te traag is in het oplossen van security issues heb ik zo geen idee van, ik merk alleen dat men al te vaak PHP wilt gebruiken omdat het snel & simpel is maar daarbij dan de veiligheid over het hoofd ziet ... Je kan het min of meer vergelijken met Windows eigenlijk, omdat het populair is worden er ook veel meer security issues gevonden denk ik ...

[kodak]

Je hebt het nu over de gebruikerskant. De reden dat Esser uit het security team is gestapt is juist omdat naar zijn mening de overige leden niets willen weten van mogelijke problemen in PHP zelf.

[Anoniem: 196388]

Ik heb één maal eerder over een dergelijke blunder gelezen en ik vond hem knap stom. ZO zou ik ook nooit iets programmeren.
Echter, een lijst met dergelijke voorbeelden ben ik nog nergens tegen gekomen! Zou wel zo makkelijk zijn om je eigen code even tegen het licht te houden. Van hé, een dergelijke constructie heb ik ooit eens daar en daar gebruikt. Dat en dat moet ik even nog aanpassen voor de volgende release.

[2playgames]

ik zou zoiets nu ook nooit gebruiken, maar je moet eens kijken wat amateurs (waaronder ooit ikzelf) allemaal uithalen

[exeldro]

De voorbeeld code die KimG geeft is helemaal niet onveilig, want er worden enkele quotes gebruikt in de include instructie. Strings aangegeven met enkele quotes worden in php niet geparsed op variabelen.

[lvh]

Ik denk dat het gaat over het feit dat er helemaal niet op users ofzo wordt gecontrolleerd, maar dat willekeurige gebruikers willekeurige pagina's kunnen opvragen (ook deze waar ze geen toegang tot zouden mogen hebben) als ze de naam maar kennen.

[EdwinG]

Nee hoor, de volgende code:
<?php
$include = $_GET['pagina'];
include('includes/$include');
?>
Zal altijd een bestand met de naam '$include' (letterlijk, niet de waarde van die variabele) includen, aangezien $include tussen enkele quotes staat, en dus niet als variabele gezien wordt.

Als
include('includes/$include');

vervangen wordt door
inlcude("includes/$include");
of door
include('includes/' . $include);

Zou het wel gevaarlijk worden.
Dat zal ook wel de bedoeling van het voorbeeld zijn geweest.

[torp]

Ik ben een php-amateur, ik weet het...
Waarom is het ene gevaarlijker dan het andere??

[Anoniem: 101162]

Of nog gevaarlijker, en ook al veel gezien:


$include = $_REQUEST["pagina"];

include($include);

om bvb een POST op te vangen.
Zet in de url een voleldige url met http:// en je kan eender welke website van het gehele internet includen, inclusief 'gevaarlijke' php scriptjes.

Ook met databases wordt er vaak slecht omgesprongen via SQL injection.

[i-chat]

alleen even, - wat is daar zo gevaarlijk aan behalve dan dat je wellicht de verkeerde map gebruikt,

/includes in plaats van /pages
tis een vrij simpele code er is weinig aan te vern..ken. - zozang je geen config files in dezelfde map hebt staan
als je webcontent, maar dat zou zowiso HEEL dom zijn, aangezien, het nog wel zou kunne zijn dat je 'later' een online page-editor zou toevoegen, en dan heb je schrijf-rechten nodig op een foto waar je configuratie bestanden staan????
)

[i-chat]

omdat je in principe geen controle hebt welke bestand uit die map of een sub-map ervan word ge-include.

[Janoz]

Tja, met .. kun je natuurlijk prachtig uit de map springen. Gebruik je helemaal geen directory en staat 'files includen via http' aan dan kan ik middels het includen van www.janoz.com/dingmetnastyphp.txt elke willekeurige code op je server uitvoeren.

[Anoniem: 24417]

ik denk dat je als programmeur vooral verantwoordelijk bent voor de veiligheid. als je code zuiver en 'foutloos' is lijkt het me over het algemeen niet dat de veiligheid in het geding komt door oneffenheden van php.

[GiantRabbit]

als je code zuiver en 'foutloos' is lijkt het me over het algemeen niet dat de veiligheid in het geding komt door oneffenheden van php.

Dat is niet wat er bedoelt wordt met de veiligheid van php. Het gaat juist om de veiligheid van :
a - de implementatie van de taal (de zend engine)
b - de gebruikte extensies (mysql driver, sockets driver, etc.)

Zo hebben we de oldtimer register_globals tot en met een denial of service attack op je mede hosters.

En dat is met name in hosted omgevingen erg gevoelig. Want vaak draaien er meerdere virtual hosts (meerdere domeinen) in hetzelfde process, onder hetzelfde user account. Tel maar na hoeveel gevaar er alleen al in deze methode zit, plus de mogelijke fouten zoals ik hierboven beschreef... blAst....

[Anoniem: 29908]

en volwassen hoster werkt natuurlijk niet met alle php processen onder dezelfde account. Met suPHP of andere gelijkwaardige technieken.
Veel van dit soort "veiligheidsgaten" worden ook door de hosters zelf niet goed gedicht.

[markg85]

de bron mag wel van Heise afkomstig zijn.. de echte bron is hier: http://blog.php-security....from-securityphp.net.html

[humbug]

Nu ben ik bepaald geen PHP fan en is het lastig de uitlatingen van deze "veiligheidsexpert" op waarde te schatten, maar toch schrik ik hiervan. Zeker de opmerkingen dat de PHP ontwikkelaars laks zijn met betrekking tot veiligheids problemen en bekende en opgeloste bugs weer herintroduceren in nieuwe versies zijn opmerkelijk. PHP is een product wat voornamelijk in kwetsbare (internet) omgevingen gebruikt wordt. Dan zou je juist een focus verwachten op veiligheid ipv de schijnbare "laat maar waaien" houding.

[Anoniem: 139256]

...toch van mening dat er bepaalde onderdelen van PHP onnodig onveilig zijn en voor structurele problemen zorgen

Ik ben benieuwd welke! (klinkt als: ik geloof er geen zak van, maar ik bedoel; ik ben benieuwd welke!)

Iemand een idee?

[deathz0rz]

Volgens Zeev Suraski, een van de hoofdontwikkelaars van PHP en cto van Zend, is PHP niet bijzonder onveilig.

Wij van WC-eend..