Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 41 reacties
Bron: eWeek

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.

PHP 5 logoDe 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.

Moderatie-faq Wijzig weergave

Reacties (41)

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
magic quotes is de meest gore instelling in php.ini.. ik heb daar echt geen goed woord voor over :P

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 :P 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 ;)
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)
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...
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...
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.
En perl nodigt niet uit tot schrijven van rampzalige rotzooi ???
/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.
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.
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.
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!
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)
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.
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.
vaak werken die tutorials etc (gelukkig) ook niet doordat in nieuwere versies van PHP register_global standaard uitstaat _o_
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 :/
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.
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.
- slechte meldingen bij inloggen zoals "het wachtwoord bij deze username klopt niet", een gebruiker weet direct dat de username dus bestaat.
:Z

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.
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.
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)
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.
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.
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.
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
Het lijkt me nogal logisch hoe PHP aan het slechte imago is gekomen. Dat hebben de PHP gebruikers namelijk zelf gedaan. Ga maar eens op zoek naar PHP code/tutorials/standaard scripts. Daar gaat get voor 99% van alle gevallen om functionaliteit.
Veiligheid wordt vergeten of uitgesteld.
Waarschuwingen over mogelijke SQL injection en inloggen met een challenge/response zijn nou niet echt zaken die ik vaak tegenkom op PHP-taal gerelateerde sites.
Het lijkt me een goede zaak dat veilig programmeren een beetje in de aandacht wordt gebracht. Ik script nu bijna 6 jaar PHP voor de kost, en je wilt niet weten wat voor foute code ik in die tijd voorbij heb zien komen van collega's.

Ook bij mijn nieuwe baas waar ik nu sinds enige weken werk zie ik de meest afschuwelijke fouten in betaalde projecten voorkomen. Zoals het gebruiken van de superglobals, de mogelijkheid voor SQL injects, het niet valideren van user-input, etc etc etc.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True