PHP-ontwikkelaars willen veiligheidsimago verbeteren

Een internationale groep PHP-programmeurs heeft de handen ineen geslagen om iets te doen aan het slechte imago van deze scripttaal. Met de oprichting van het PHP Security Consortium wil de groep het veilig programmeren promoten. Daarnaast zal het consortium een centraal punt worden waar men terecht kan voor documentatie, standaarden en technieken. PHP kwam slecht in het nieuws door de uitbraak van de Santy worm. Deze worm viel phpBB-forums aan, een programma dat geschreven is in deze scripttaal. Het beveiligingslek waar Santy gebruik van maakte had echter niets te maken met een fout in de PHP-taal.

De release van een aantal patches voor beveiligings-issues voor PHP in dezelfde periode was louter toeval maar leidde tot verwarring. PHP is een laagdrempelige programmeertaal en wordt daarom veel gebruikt. Ook door programmeurs met te weinig kennis van de beveiliging van webapplicaties, aldus Chris Shiflett, een van de oprichters van het consortium.

Reacties (41)

[Norm2782]

Link naar site http://www.phpsec.org/

[Verwijderd]

PHP wordt inderdaad veel te vaak verkeerd gebruikt, hoe vaak zie ik niet scripts die niet beveiligd zijn tegen SQL injection, niet overal controleren of je admin bent etc.

Ik vind echter wel dat PHP zelf inderdaad meer kan doen aan veiligheid. Zo hebben ze bijvoorbeeld magic_quotes in het leven geroepen, maar ik heb nergens een echt goed document kunnen vinden waar de werking uitgelegd wordt (wel ongeveer, dat staat op de php website).

Ik hoop dus van harte dat dit consortium vooral veel goed leesbare documentatie zal produceren

[Verwijderd]

magic quotes is de meest gore instelling in php.ini.. ik heb daar echt geen goed woord voor over

persoonlijk vind ik de security van php op dit moment meer dan toereikend. het is puur een programmeur-aangelegenheid geworden, en zo hoort 't ook.

yomdejong:

magic quotes is een ramp als je niet weet wat het doet, waarom het dat doet, of het dat doet, sinds wanneer het dat doet etc...

voor beginners is het echter een geweldige uitkomst

dat spreekt elkaar tegen.. als je niet weet wat magic quotes zijn of doen, ben je absoluut een beginner.
desalniettemin, ik vind 't bijzonder slecht om alles wat binnenkomt op een page te escapen omdat 't misschien wel eens gebruikt zou kunnen worden op een manier waarbij je variabelen wil escapen. het is een achterlijke manier van coden.

register_globals heb je overigens gelijk in. ik gebruik trouwens register_globals wel, maar ik weet wat ik doe als je 't mij vraagt is het toereikend dat 't standaard uit staat.

overigens, yomdejong, je select niet van een database, maar van een table in een database

[Verwijderd]

magic quotes is een ramp als je niet weet wat het doet, waarom het dat doet, of het dat doet, sinds wanneer het dat doet etc...

voor beginners is het echter een geweldige uitkomst, want nu is deze code opeens veilig:

<?php
$query = "SELECT * FROM database WHERE string = '".$string."';";
$result = mysql_query($query);
while ($row = mysql_fetch_assoc($result)) { // edit: typo (d'oh!)
...
}
?>

maar als je de variabelen voor mailtjes gaat gebruiken... tsja... dan moet je ze eerst door stripslashes halen.

(nu ik dit scriptje schrijf, de register_globals moet eigenlijk uit php gesloopt worden, da's pas gevaarlijk)

[mxcreep]

Bedoel je in dit geval magic_quotes_gpc of magic_quotes_runtime ???

De eerste vind ik persoonlijk wel fijn, maar da's ook een kwestie van weten wat het doet en daarmee werken...de runtime variant gebruik ik nooit...

[mxcreep]

Persoonlijk vind ik register_globals nog veel smeriger...
Het schijnt tot veel programmeurs nog steeds niet door te dringen dat alles uit de GET en POST vars automatisch declareren gewoon vragen om problemen is, zowieso door een hele applicatie door globale variabelen gebruiken is nogal populair...en extreem ranzig.
Functies en Classes maken schijnt voor velen ook een probleem te zijn...daarom include men maar gewoon files met blokken code op willekeurige plaatsen ?!?!
Er is vaak totaal geen zinnige programmeerstijl te herkennen in de werkwijze van veel scripters, vooraf declareren van variabelen, commentaar plaatsen etc etc is blijkbaar niet nodig.
Zelfs paketten waarvan je in eerste instantie het idee hebt dat ze goed in elkaar zitten blijken vaak na onderzoek van de source een puinhoop te zijn.

Overigens zou het ook fijner zijn als safe_mode, wat op zich een goed initiatief is, opgesplitst zou worden in een aantal onderdelen, zodat beter te bepalen is wat een virtual host nou wel en niet mag op het systeem.

Maar feit blijft voor mij, met php kun je echt machtig veel doen en ook nog eens op een goede veilige manier, maar het blijft afhankelijk van de kwaliteiten van de programmeur. De laagdrempeligheid werkt er in dit geval dus aan mee dat er ook veel troep afgeleverd wordt, zelfde geld in feite ook bij andere scriptingtalen.

Wat verder erg positief is is dat er inmiddels al enige tijd een certificering is vanuit Zend voor php. Dit heeft als voordeel dat het kaf van het koren wordt gescheiden en dat beunhazen en hobbyisten zich binnen een redelijke tijd geen php programmeur meer kunnen / mogen noemen zonder te zorgen dat hun kennis voldoende is.

Ik ben overigens van mening dat als je jezelf een fatsoenlijk web programmeur wilt noemen dat je meer kennis dient te hebben als alleen van de script taal waar je in programmeert, kennis van het onderliggende systeem is ook super belangrijk als je wilt weten hoe php met zaken omgaat. Per slot van rekening is meer dan de helft van de functies uit php gecompileerd tegen op het systeem al aanwezige libraries. Uiteindelijk, als je het goed wilt doen, is php dus misschien wel minder laagdrempelig als men denkt.
Zelfde verhaal voor mysql, men kan een database maken en een tabel erin gooien en daar wat mee doen, maar dat maakt nog geen fatsoenlijk database model...

[Verwijderd]

PHP wordt inderdaad veel te vaak verkeerd gebruikt, hoe vaak zie ik niet scripts die niet beveiligd zijn tegen SQL injection

Misschien komt het omdat PHP nogal uitnodigt om rampzalige code te schrijven?

Als je gebruik maakt van andere scripttalen, bijvoorbeeld Perl, krijg je vaak zoiets moois erbij dat je met een soort van sprintf(3) achtige opmaak variablen in je SQL queries gebruikt. Geen gezeik met escapen, klaar is kees.

Magic quotes is trouwens ook een gore hack daarvoor. Dat escape't ' en " voor je, maar een hele boel andere shit niet. Er zijn zat dingen te verzinnen waarmee je een MySQL socket toch aardig dicht kan rossen zonder ' en " te gebruiken.

Wat ik ook zonde vind is dat PHP standaard niet met een template engine komt (Smarty moet je los downloaden). Veel mensen zijn ook te lui om template engines te leren dus is 90% van de PHP code ranzige zooi omdat je midden in je webpagina ineens gaat rommelen met SQL queries en LDAP troep, dus zie je uiteindelijk de bomen niet meer door het bos. Zeker als je andermans code gaat doorloeren.

[mxcreep]

En perl nodigt niet uit tot schrijven van rampzalige rotzooi ???

[mawashigeri]

/offtopic
Bij perl is het hard werken om e.e.a. goed leesbaar en gestructureerd te houden Het is net vrije meningsuiting: er mag wel heel veel, maar het hoeft niet!

Vaak gebruik je perl voor de snell hackscripts, maar toch gebruiken we het ook wel voor meer geavanceerde zaken zoals het uitpluizen van profiling data of code coverage tests.

[Verwijderd]

EdSchouten,

in php5 is een extensie gekomen (mysqli, mysql-improved) waarmee je prepared statements kunt maken. daarmee is de escape-noodzaak opgelost.

template engine? ik vind 't helemaal niks.. je geeft als argument dat je anders sql statements tussen je html code moet gaan schrijven.. sorry kerel, maar als je een beetje ervaring hebt met 't schrijven van software i.c.m. databases moet jij toch ook wel weten dat je presentatie en data van elkaar gescheiden houdt? en daar heb je geen template engine voor nodig, how about classes?

krimszon:

in mijn werk is vrijwel alle code die niet met presentatie te maken heeft verwerkt in classes.. dat betekent dat alle files die geen classes definieren in principe mijn templates zijn.

[Verwijderd]

Ja maar classes zijn toch zeker niet de oplossing om presentatie en code gescheiden te houden? M.i. zijn templates de toekomst voor webapplicaties, kijk maar naar asp.net, smarty en diverse Java-programmeer modellen.

[genosis]

Ik vind het zoiezo jammer dat PHP tegenwoordig vooral aangekeken word als een "kinderlijke" taal die iedereen maar kan leren en gebruiken.

Het is een volwaardige script taal, en hoe het werkt hangt af van de gebruiker.

Hopelijk een stap in de goeie richting!

[Verwijderd]

PHP kan op een zeer kinderlijke manier gebruikt worden. Dat het anders kan ben ik helemaal met je eens, maar hoe vaak hoor ik op school niet 13 jarigen die dan

php kunnen

.
Ik zou niet ook maar een product van hun op een site zetten; dat is vragen om problemen.

(er zijn natuurlijk ook zat 13 jarigen die echt php kunnen, dat zal je mij niet horen ontkennen)

[praseodymium]

Ik ben zelf 15 en kan niet eens zo heel goed PHP, maar wel C#...en ik ben gelukkig niet zo iemand die alleen maar tag soup schrijft - er zijn inderdaad veel jongeren bij die denken dat ze PHP 'kunnen' als ze met echo-en een lekkere tag soup kunnen maken. Van SQL-injections hebben die denk ik ook niet gehoord.
Zelf moet ik zeggen dat ik meer geintereseerd ben in PHP nu ik heb gehoord dat PHP5 aardig OO is.

[ludo]

De veiligheid van php wordt ook niet erg bevorderd door de duizenden 'tutorials' die op internet te vinden zijn, maar ook in vele boeken staan. Hier staan vaak zéér slechte voorbeelden in... Maar het werkt wel... En de beginnende programmeur heeft inderdaad vaak geen flauw benul van de veiligheidsrisico's die zijn/haar scripts met zich meebrengen.

[Erkens]

vaak werken die tutorials etc (gelukkig) ook niet doordat in nieuwere versies van PHP register_global standaard uitstaat
En dat is wat vaak in die tutorials gebruikt wordt, die zijn gewoon te oud, maar ja, zoals met veel wat te vinden is op internet helaas...
Echter krijgen deze beginners hiermee problemen en als ze dan doorzoeken komen ze erachter dat ze register_globals moeten aanzetten
Nee dat schiet allemaal niet op. Goed initiatief iig, alleen ben ik bang dat je deze doelgroep moeilijk kan bereiken

[Verwijderd]

Ik zit me sterk af te vragen wat ze nog meer van plan zijn behalve die PHP Security Guide waar op zich nog wel zaken op aan te merken zijn.

Ten tweede vraag ik me zeer sterk af wat de relatie tussen "het php security consortium" en zend zelf is. Of dat het gewoon in het leven geroepen is met het motto "als we de naam php gebruiken, lijkt het vanzelf officieel."

Goedbedoeld maar ik heb mijn twijfels.

edit + aanvulling:

Ik zie net dat er een wel een aantal knappe koppen bij zitten, wat betreft php security. Dit op zich is wel weer een goed teken.

Ondanks betwijfel ik ten zeerste of phpsec.org een status als w3c en gelijken zal krijgen, puur en alleen al omdat het hele gebeuren is gebasseerd op artikeltjes en publicaties, zonder een duidelijke structuur of ordening, wat het tot een goed naslagpunt zou maken.

Persoonlijk zie ik mezelf nog niet verwijzen naar http://phpsec.org/projects/guide/3.html omdat ik iemand iets wil vertellen over database access beveiliging.

Ze zullen hier hard aan moeten werken wil het een bruikbaar iets worden.
Als ik http://phpsec.org/sessions/ intyp wil ik bijvoorbeeld in plaats van een 404, gewoon een nette summary krijgen waar ik hints en tips vind over het beveiligen van sessions.

De tijd zal het leren.

[Verwijderd]

Ook in de professionele sector is de aandacht voor veilige code laag, al probeert mening developer dat altijd te ontkennen.

- sql injection.
- missende login checks bij pagina's niet direct gerelateerd aan de login pagina.
- missende controles op id's in url's
- weinig controle op aanwezigheid van de aanwezigheid van variabelen
- sql username en password zichtbaar in foutmeldingen
- hardcoded username en password voor developer access
- race conditions die gevoelige data kan tonen
- slechte meldingen bij inloggen zoals "het wachtwoord bij deze username klopt niet", een gebruiker weet direct dat de username dus bestaat.
- weinig koppeling van code aan verantwoordelijke programmeur (wie gaan we hiervoor aanspreken, wie gaan we begeleiden in het voorkomen van de fouten, het is dus niet zozeer een "blame it on" methodiek)

En zo kunnen we nog wel even doorgaan. Het resultaat van steeds complex wordende applicaties, met steeds meer wensen voor minder geld in kortere tijd en daardoor verhoogde werkdruk.

[Olaf van der Spek]

- slechte meldingen bij inloggen zoals "het wachtwoord bij deze username klopt niet", een gebruiker weet direct dat de username dus bestaat.

Ik mag hopen dat je beveiliging daar niet vanaf hangt.

Al die ranzige code komt IMO (voor een groot deel) door een ranzige taal.
De onveilige dingen zijn makkelijker dan de veilige dingen, terwijl dat niet hoeft.

[Verwijderd]

Tuurlijk hangt je beveiliging daar wel vanaf. Je beveiliging hangt af van bijvoorbeeld de combinatie username en password. Het voorbeeld wat ik dus gaf, is de nummer één doodszonde van loginsystemen, namelijk de persoon doorgeven dat 50% van de gegevens WEL goed waren.

Een betere melding zou dan beter iets in de vorm zijn van "Uw inlogpoging is mislukt, controleer uw gebruikersnaam en wachtwoord, en probeer het nogmaals.".

Zo geef je totaal niet vrij, wat er wel en wat er niet goed was.

[BartOtten]

Als je goed coded dan maakt het niet uit dat je '50%' weggeeft en het is voor de n00b-gebruikers wel handig als ze weten wat er fout is. Brute-Forces kan je ondervangen door ip-blocks, account-deactivatie enz enz....

We kunnen ook gaan overdrijven met veiligheid (kijk, een 15.000 leden site heeft wel wat beveiliging nodig maar een simpele bedrijvensite moet je niet met al die checks opzadelen en die moet een simpele login hebben)

[Olaf van der Spek]

Een betere melding zou dan beter iets in de vorm zijn van "Uw inlogpoging is mislukt, controleer uw gebruikersnaam en wachtwoord, en probeer het nogmaals.".

Dat is *zo* irritant op sites die je wat minder vaak gebruikt en als je meerdere usernames en passwords gebruikt.
Geldige usernames vinden is vrijwel nooit een probleem, kijk maar naar deze site bijvoorbeeld.

[Verwijderd]

toch jammer dat niet je niet makkelijk kunt achterhalen wie zich dan voor de veiligheid van deze bijzonder mooie taal gaan inzetten. Vind ik altijd een vaaag teken

[Verwijderd]

Het is een volwaardige script taal, en hoe het werkt hangt af van de gebruiker.

Zolang PHP niet strikt is, met klote codes de boel moet beveiligen (stripslashen, etc) en niet 100% OO ondersteund kan je het niet volwassen noemen. Bij een volwassen taal kom je niet keer op keer op keer idiote zaken tegen waar je gigantisch omheen moet bouwen omdat PHP beperking heeft bij dingen waar andere talen doorheen fluit.

Natuurlijk kan je in java en .NET de boel ook klote maken, maar een code als:

$empty = '';
str_replace('e',''$empty);

zal echt niet lukken.
Zoalng dit goedgekeurd wordt blijf je altijd kut codes en rommeligge zut produceren:

$x = 5;
$x = "test";

echo $x;

Verder is het gewoon klote dat de code niet gescheiden kan worden van de html zonder een template class/engine. Dat moet er gewoon komen want anders zal de code nooit echt schoon worden (zonder gebruik van een 3rd party engine).

PHP is zeker niet slecht, maar kwa beveiliging, volwassenheid en strictheid kan het nog erg veel leren.

Zend mag trouwens zelf wel de boel leren beveiligen. Zolang je "><script>alert(document.cookie)</script> mag uitvoeren in inlog velden mag je jezelf echt geen serieus bedrijf noemen dat iets met PHP doet. Kom op zeg, dit heb ik ruim 1.5 jaar geleden gemeld, maar ze a) doen er niets aan b) zijn te lui c) kunnen niet programmeren. Hoe meer ik met PHP doe hoe meer ik eraan begin te twijfelen.

[mxcreep]

Niks third party template engine, smarty is gewoon onderdeel van PEAR...
Als je dergelijke uitspraken doet moet je je ook es verdiepen in PEAR en PECL...

Overigens noem je net java, alsof jsp zo fijn werken is...om struts nog niet eens te noemen...

Voor wat stricte types betreft heb je deels gelijk, maar dat is een keuze die je maakt als je een platform kiest om op te developen, voor mij persoonlijk is er niet 1 platform het beste om alles op te ontwikkelen...

[Verwijderd]

>Zolang PHP niet strikt is, met klote codes de boel
>moet beveiligen (stripslashen, etc) en niet 100%
>OO ondersteund kan je het niet volwassen
>noemen. Bij een volwassen taal kom je niet keer
>op keer op keer idiote zaken tegen waar je
>gigantisch omheen moet bouwen omdat PHP
>beperking heeft bij dingen waar andere talen
>doorheen fluit.

Volgens mij wil je van php gewoon een taal maken die gepre-compiled moet worden.

>Natuurlijk kan je in java en .NET de boel ook klote >maken, maar een code als:
>$empty = '';
>str_replace('e',''$empty);
>zal echt niet lukken.

String s = "";
s.replace("e", s);

>Zend mag trouwens zelf wel de boel leren
>beveiligen. Zolang je "><script>alert
&gt ;(document.cookie)</script> mag uitvoeren in inlog
>velden mag je jezelf echt geen serieus bedrijf
>noemen dat iets met PHP doet.

Dit is toch iets wat de ontwikkelaar toelaat, en niet iets wat Zend toelaat? Mocht Zend dit blokken, dan wordt het toch erg ingewikkeld om cms-onderdelen te maken waar je html kan invoeren, of online html editors..

> Kom op zeg, dit
>heb ik ruim 1.5 jaar geleden gemeld, maar ze a)
>doen er niets aan b) zijn te lui c) kunnen niet
>programmeren. Hoe meer ik met PHP doe hoe
>meer ik eraan begin te twijfelen.

Held.

[Verwijderd]

Vaag verhaal inderdaad, maar met dat stukje javascript had ik de indruk dat hij de website van Zend bedoelde. Dat dat dan een slechte indruk maakt wil ik wel beamen.

[Verwijderd]

Sorry hoor, maar wat een onzin loop je hier te verkondigen

PHP is niet strong typed, dat wil niet per definitie zeggen je daardoor onveilige code krijgt. Dat jij een variabele eerst vult met een int en daarna met een string, who cares. Het gaat er om dat je het resultaat controleerd.

En dan komt daar nog het OO verhaaltje bij, ook zoiets, alsof OO je veiliger laat coden Weet je wel wat OO is?

En dan als klapper op de vuurpijl

"Zend mag trouwens zelf wel de boel leren beveiligen. Zolang je "><script>alert(document.cookie)</script> mag uitvoeren"

Sinds wanneer voert Zend javascript code uit op de client Als ik dergelijke scripting in de addressbar uitvoer krijg ik ook gewoon resultaat hoor, daar heb ik geen input fields voor nodig. Volgens mij moet je niet aan PHP twijfelen maar aan je eigen kennis.

[aCCuReRaS]

dit is een goede stap, daar veel mensen kunnen programmeren in PHP, maar veel van die mensen hebben geen flauw benul van veiligheid

[Verwijderd]

PHP is een laagdrempelige programmeertaal en wordt daarom veel gebruikt. Ook door programmeurs met te weinig kennis van de beveiliging van webapplicaties, aldus Chris Shiflett, een van de oprichters van het consortium.

Dit stond dus ook al in het bericht zelf

[Engineer]

Waarom zou php een slecht imago gekregen hebben omdat dat frut phpbb een lompe fout heeft gemaakt

Door er zo op in te gaan laten ze aan mij meer onproffesionaliteit zien. Het is totaal aan de programmeur hoe het met de beveiliging gesteld staat.

[Verwijderd]

Echte php beveiliging zou misschien in dat opzicht voornamelijk bestaan uit een imago beveiliging.

Het is denk ik vanuit Zend's opzicht niet onverstandig "php" zodanig als merknaam te beschermen, zodat enkel scripts die aan enkele kwaliteitseisen (waaronder veiligheid) voldoen, die naam zouden mogen dragen.
Dit betekend ook dat er hard opgetreden dient te gaan worden tegen de grote hoeveelheid slechte code die onder de noemer "php[\w]+" de ronde doet.

Alleen zijn ze/we daar weer veels te laat mee, dus die hoop is alweer vervlogen.