Drupal patcht ernstige lekken in modules die overname van site mogelijk maken

Contentmanagementsysteem Drupal waarschuwt voor ernstige lekken in drie modules die het overnemen van een site mogelijk maken. Het gaat om modules die gebruikt worden door een klein aantal sites; de organisatie schat het totale aantal tussen de 1000 en 10.000.

De core van het Drupal-systeem is niet getroffen, zo laat het het beveiligingsteam weten in een bericht. Bij de modules gaat het om Restws, Coder en Webform Multiple File upload. Met dit soort modules kan de functionaliteit van het cms uitgebreid worden. De kwetsbaarheden maken het mogelijk om op afstand code uit te voeren en hebben wegingen tot 22 uit 25 punten meegekregen, waardoor deze als zeer ernstig zijn geschat.

Er zijn woensdag patches beschikbaar gekomen voor de lekken. Drupal heeft via Twitter laten weten dat de Coder-module niet ingeschakeld hoeft te zijn om aangevallen te kunnen worden, deze hoeft zich alleen ergens in de webroot te bevinden. Drupal verwacht dat er binnen enkele uren of dagen zeker exploits voor de kwetsbaarheden zullen verschijnen en roept gebruikers dan ook op om zo snel mogelijk een update uit te voeren.

Volgens The Register is Drupal in totaal ongeveer 15 miljoen keer gedownload, in vergelijking tot 30 miljoen downloads van Joomla en 140 miljoen downloads van WordPress.

Reacties (52)

[REDSD]

Ik vind jammer dat drupal de modules nog niet buiten de public directory plaatst.
Het systeem zou een stuk minder kwestbaar zijn geweest als niet alle bestanden voor iedereen toegankelijk waren om aan te spreken.

Met de implementatie van symfony hadden ze daar mooie stappen in kunnen maken voor drupal 8.

[Sysosmaster]

Dit is iets waar de drupal devs naar gekeken hebben (willen ze namelijk ook graag i.v.m. de reden die jij noemt en meer) maar is helaas niet mogelijk omdat dit simpelweg niet mogelijk is op veel VPS providers. Verder heb je nu eenmaal maar 1 of 2 users waar mee je kunt werken op systeem niveau (website user en php user) en vaak zijn deze gelijk aan elkaar.

Echter, Ik draai al enkele Drupal websites waarbij de drupal omgeving enkel lees toegang heeft tot de bestanden (en slechts schrijf toegang heeft tot de cahce en uploads). dit werkt goed maar is wel onderhouds gevoeliger (lees: duurder)

Overigens de soort modules waar het in gevonden is zijn hoogst specifiek in scoop:

• RESTws :=> Services (API ed.),
• Coder :=> zou enkel op Dev systemen moeten staan en buiten drupal zelf, maar in de user home of dergelijk,
• Webform multi file upload :=> Deze is waarschijnlijk meest verspreid onder productie websites. vraag is of de multi echt nodig is, maar is case-by-case afhankelijk.

[CAPSLOCK2000]

Dit is iets waar de drupal devs naar gekeken hebben (willen ze namelijk ook graag i.v.m. de reden die jij noemt en meer) maar is helaas niet mogelijk omdat dit simpelweg niet mogelijk is op veel VPS providers. Verder heb je nu eenmaal maar 1 of 2 users waar mee je kunt werken op systeem niveau (website user en php user) en vaak zijn deze gelijk aan elkaar.

Echter, Ik draai al enkele Drupal websites waarbij de drupal omgeving enkel lees toegang heeft tot de bestanden (en slechts schrijf toegang heeft tot de cahce en uploads). dit werkt goed maar is wel onderhouds gevoeliger (lees: duurder)

Dat is ook mijn ervaring. Drupal kan op zich prima om gaan met een situatie waarin de code niet schrijfbaar is voor webserver of zelfs niet voor de php-gebruiker. De meeste webhosters en websitebouwers kunnen daar echter niet mee overweg.
Ik heb het nu een paar keer geprobeerd (aan beide kanten van het hek) en iedere keer is het resultaat op z'n best matig, maar dat heeft weinig tot niks met Drupal zelf te maken, maar vooral met gebruikers en beheerders die het niet snappen en eigenlijk ook niet willen snappen. Een redelijk argument om dat niet te willen is dat je dan de ingebouwde install- & update-features van Drupal niet meer kan gebruiken om modules te installeren en bij te werken, Drupal heeft immers geen schrijfrechten. Keer op keer blijkt men het belangrijker te vinden om de boel via de ingebouwde webinterface te beheren. Als dat niet kan dan heb je een andere interface nodig (bv via de CLI met Drush) maar daar willen de meesten niks van weten. Ze willen het niet en ze kunnen het niet. Dat betekent dat in de meeste gevallen de keuze is tussen "geen website" en "een onveilige website". Het is begrijpelijk dat er steeds weer voor de laatste optie wordt gekozen want helemaal geen website kan tegenwoordig niet meer.

Dat geldt overigens niet alleen voor Drupal maar voor zo'n beetje iedere complexe webapplicatie. Mensen willen alle features tegen de laagste kosten.

Op een bepaalde manier kun het wel vergelijken met gezond eten. Iedereen weet dat je gezond moet eten en wil dat in principe ook wel, maar als puntje bij paaltje komt doen we het niet. Steeds weer kiezen we toch voor de hamburger die goedkoop en lekker is, maar niet zo gezond.

[rvec]

Als je samenwerkt met professionele partijen zou je hier geen problemen mee moeten hebben. Code aanpassen en modules updaten gebeurt op development omgevingen, via versie management gaat het dan naar acc en productie omgevingen waar het door een CI systeem wordt neergezet zodat geen enkele developer hoeft in te loggen en de apache/nginx gebruiker geen rechten nodig heeft om bestanden aan te passen.

De functie om via de webinterface te updaten is vooral bedoeld voor gebruikers die dit allemaal niet kunnen en met een klik willen updaten. De keuze is dan vooral tussen niet updaten (omdat ze het niet kunnen), of updaten via een web-interface.

[CAPSLOCK2000]

Als je samenwerkt met professionele partijen zou je hier geen problemen mee moeten hebben

Ik ken meer "professionele" (professioneel = het kost geld) partijen die het niet goed doen dan die het wel goed doen.

Code aanpassen en modules updaten gebeurt op development omgevingen, via versie management gaat het dan naar acc en productie omgevingen waar het door een CI systeem wordt neergezet zodat geen enkele developer hoeft in te loggen en de apache/nginx gebruiker geen rechten nodig heeft om bestanden aan te passen.

Yup, dat soort systemen bouwen is mijn werk. Toch krijg ik vaker een e-mail met zipfile vol updates dan het verzoek om tag X uit repository Y te installeren. Natuurlijk probeer ik iedereen op te voeden om het goed te doen, maar deze kennis is nog lang niet universeel aanwezig. Je wil niet weten hoeveel projecten de mist in gaan omdat de ingehuurde developer, webmaster of reclameboer incompetent blijkt te zijn, maar ja, dan is het geld al uitgegeven en om het project niet volledig te verliezen wordt er dan toch maar weer een zipje opgestuurd.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 03:45]

[rvec]

" omdat de ingehuurde developer, webmaster of reclameboer incompetent blijkt te zij"
ja met incompetente mensen samenwerken vraagt om problemen. Dat is ook iet de groep die ik bedoelde met "professionele" partijen.

Mocht je nog een goede partij zoeken met veel kennis van Drupal kan je hier terecht: https://www.drupal.org/drupal-services

[CAPSLOCK2000]

" omdat de ingehuurde developer, webmaster of reclameboer incompetent blijkt te zij"
ja met incompetente mensen samenwerken vraagt om problemen. Dat is ook iet de groep die ik bedoelde met "professionele" partijen.

Het is misschien een beetje flauw om het zo te zeggen maar het verschil tussen professioneel en "professioneel" is hier het probleem. Professioneel zegt niet meer dan dat ze het niet voor niks doen, het zegt niks over de kwaliteit. Kwaliteit vooraf beoordelen is ontzettend moeilijk, zeker als de wensen van de IT-afdeling maar een kleine rol spelen in de totale beslissing. Ik kan wel eisen stellen, bv dat iedereen versiebeheer gebruikt, maar in praktijk betekent het dat gebruikers mij (de it-afdeling) dan gaan omzeilen. Ze hebben een website nodig en ze hebben 500 euro budget. Daarvoor krijg je geen kwaliteit. Mijn gebruikers zien dat alleen niet zo, die zien alleen het eindresultaat, niet de puinhoop die er achter zit. Als het er mooi uit ziet dan zijn ze tevreden. Als ik het niet host dan huren ze wel een webserver voor 1 euro per maand.

Dat is allemaal een beetje kort door de bocht, in werkelijkheid komen we er meestal wel uit, maar de kern blijft. Als ik echt kwaliteit en veiligheid eis dan is 90% van de projecten onbetaalbaar. en zoeken ze wel iemand die goedkoper is.

Mocht je nog een goede partij zoeken met veel kennis van Drupal kan je hier terecht: https://www.drupal.org/drupal-services

Ik ken verschillende partijen uit die lijst en hoewel het met de kennis van Drupal zelf wel goed zit gaat het op andere punten, zoals security, wel eens fout.Op die lijst staan is geen garantie dat ze een veilig product leveren.

(PS, ik probeer niet af te geven op Drupal, het probleem is veel groter dan dat en geldt voor de meeste sofftware en websites).

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 03:45]

[R4gnax]

Drupal kan op zich prima om gaan met een situatie waarin de code niet schrijfbaar is voor webserver of zelfs niet voor de php-gebruiker. De meeste webhosters en websitebouwers kunnen daar echter niet mee overweg.
Ik heb het nu een paar keer geprobeerd (aan beide kanten van het hek) en iedere keer is het resultaat op z'n best matig, maar dat heeft weinig tot niks met Drupal zelf te maken, maar vooral met gebruikers en beheerders die het niet snappen en eigenlijk ook niet willen snappen. Een redelijk argument om dat niet te willen is dat je dan de ingebouwde install- & update-features van Drupal niet meer kan gebruiken om modules te installeren en bij te werken, Drupal heeft immers geen schrijfrechten.

De zwakheid in het hele systeem is heel simpel het ontbreken van gelaagde permissies en accounts.

Het standaard account waar een Drupal site en beheeromgeving onder draait zou gewoon zonder schrijfrechten moeten werken en daarnaast zou voor de update-procedures specifiek een tweede account moeten bestaan dat wel schrijfrechten heeft en waar je via impersonation tijdelijk naar overgaat tijdens het updaten (en alleen tijdens het updaten).

[Sysosmaster]

Wat bedoel je hier met "account", een drupal account (want zoals jij het beschrijft werkt het nu al, al gebruiken veel dit admin account voor alles).
Of een systeem Account. Wat technish mogenlijk is op een *NIX omgeving maar practish vaak niet haalbaar is. Het type lek waar het hier om gaat heeft weinig te maken met de drupal gebruikers. Maar meer met de rechten van de applicatie. Dus als jij het hebt over een drupal gebruikerm dan is het nutteloos. Immers heeft drupal dan gewoon schrijfrechten en is de exploit dus derhalve gewoon mogenlijk.

[R4gnax]

Wat bedoel je hier met "account", een drupal account (want zoals jij het beschrijft werkt het nu al, al gebruiken veel dit admin account voor alles).
Of een systeem Account. Wat technish mogenlijk is op een *NIX omgeving maar practish vaak niet haalbaar is.

Systeem accounts waarop de Drupal-site en -beheeromgeving draaien binnen de webserver.

Dus één systeem-account met enkel leestoegang, waar de site en beheeromgeving normaal op draaien. En één systeem-account met extra schrijftoegang, die enkel en alleen voor update-processen gebruikt wordt.

Waarom zou het splitsen over twee systeem accounts praktisch niet haalbaar zijn, trouwens?

[Reactie gewijzigd door R4gnax op 23 juli 2024 03:45]

[Sysosmaster]

Dus één systeem-account met enkel leestoegang, waar de site en beheeromgeving normaal op draaien. En één systeem-account met extra schrijftoegang, die enkel en alleen voor update-processen gebruikt wordt.

Waarom zou het splitsen over twee systeem accounts praktisch niet haalbaar zijn, trouwens?

Omdat je voor het update proces dan deze 2 systemen op een of andere manier moet gaan vermengen. Je normale account heeft namelijk nog steeds schrijf toegang nodig naar specifieke locaties. En voor een Drupal update heb je ook toegang nodig tot het drupal update systeem voor o.a. database updates. Je ontkomt er dus niet aan dat je 'gewone' user toch schrijf toegang heeft. Ook is je update user gewoon vatbaar voor al de problemen die met deze PSA te maken hebben (dus heeft je probleem niet weggenomen). Ook als het om gedeelde diensten gaat heb je simpel weg maar 1 user dus is opsplitsing niet mogelijk.

[Olaf van der Spek]

Wat technish mogenlijk is op een *NIX omgeving maar practish vaak niet haalbaar is.

Het probleem zit IMO toch op technisch vlak... zonder root toegang kun je geen (sub) users maken.

Een standaard update model is er blijkbaar ook niet voor web apps, elke web app mag het wiel opnieuw en onveilig uitvinden.

[Strunkie]

Op een VPS kan je toch juist zelf alles instellen? Dus zou het geen probleem moeten zijn om je modules buiten de public te plaatsen.

Bovendien is het een slechte reden dat je hierom de modules in de public moet plaatsen, de hostingpartijen moeten zich hier maar aan aanpassen.

[Sysosmaster]

Ik kom anders nog vaak bij klanten tegen met een VPS waar je geen SSH toegang hebt, of enkel een "normal" user zonder systeem-rechten waardoor je ook niets kan. (en ja ik heb inderdaad shared hosting en VPS hosting op een hoop gegooid, misschien te kort door de bocht, maar ikzelf zie te weinig verschil tussen de twee. In mijn ogen is DirectAdmin een slecht werkende draak van een programma dit zijn eigen beveiligings-problemen kent.

[Verwijderd]

Volgens mij is het in VPS land de norm dat je gewoon root toegang krijgt tot een eigen virtuele server hoor... ik weel i.i.g. niet beter en heb er over de jaren best een aantal gehad.

Ik zou ook niet weten wat anders de meerwaarde is van de VPS als je dezelfde restricties hebt als je hebt met een reguliere shared hosting.
Immers, met een VPS krijg je er wel een stukje technisch beheer bij. En dat wil je natuurlijk alleen als je er ook wat mee kan anders zit je jezelf alleen maar extra werk op de hals te halen.
VPS moet immers het gat vullen tussen shared hosting en een eigen server plaatsen ergens in een rack.
De vrijheid van je eigen configuratie zonder de last van dure hardware.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:45]

[Arietje]

Het lijkt er niet echt op alsof je weet waarover je praat. Een VPS kan managed of unmanaged zijn. Neem een VPS bij Digital Ocean of TransIP of andere willekeurige provider en je krijgt gewoon een clean distro en je mag het helemaal zelf uitzoeken.

DirectAdmin is verder een prima controle paneel met software beheer (Custombuild). Prima voor op een VPS voor jezelf. Op shared hosting kan dit ook nog redelijk, al is gebruik met CloudLinux dan wel een stuk beter, daar CL gericht is op shared hosting. Met of zonder CL kun je in ieder geval PHP laten draaien onder de eigen user.

Neem er de CSF plugin en je hebt een leuke firewall (iptables beheer).

Alle panelen zij het plesk/cpanel/directadmin hebben als het goed is allemaal de public root in een vrij diepe map zitten, daar kan prima een map hoger gewerkt worden met bestanden. Kan dit niet, zoek een andere provider.

Dit mag echt geen argument zijn voor Drupal.

[Sysosmaster]

Ja, er zijn ook jongens die het netjes doen (je lijstje is vrij compleet in dat).
SSH toegang vind ik zelf een must omdat het mogenlijk maakt (via certifiacte login) om veilig updates uit te voeren zonder dat de webstack zelf overal schrijftoegang nodig heeft.

Ik zie echter vaak dat klanten een dienst (wat zij een VPS noemen) afnemen waarbij het allemaal gewoonweg niet samen werkt. Je kunt in deze 'VPS' simpel weg niet veilig werken omdat er of gewerkt word met wachtwoorden (die in clear tekst over mail worden verstuurd... wtf.) of omdat je niet zelf dingen kunt inregelen (geen /crippled SSH bijvoorbeeld).

Het klopt dat ikzelf niet heb nagegaan welke vorm van dienst zij hebben (ik word meestal gevraagd om iets te maken, en niet om advies te geven)

Wat betreft controle paneelen. tenzij je een custom versie hebt ben ikzelf er nog geen een tegen gekomen die simpel weg onwerkbaar was om een website fatsoenlijk en veilig mee te configureren.

[Arietje]

Enkele andere grote partijen zijn leaseweb, i3d, cloudvps, pcextreme, en kijk eens rond op ispgids. Het is normaal om bij een unmanaged VPS het volledige beheer te krijgen. Krijg je dit niet, dan is het ofwel managed door de hosting partij of door niemand gemanaged (?). Managed iemand niet naar wens, simpel -> andere partij. Dit hoeft in ieder geval geen probleem te zijn voor een CMS hoe zij zaken ontwikkelen.

Bij DirectAdmin is het zo dat je wel moet weten wat je doet. Laat je alles default staan dan is het geloof ik zo dat alles onder 1 user draait. Echter zijn er genoeg opties om dit per user te laten draaien. Een goede hosting omgeving is dan ook geen one click gebeuren, je mag het rustig een vakgebied noemen.

En ja het komt voor dat er geprutst wordt, maar laat dat dan bij de prutsers en niet bij de algehele werking van systemen.

[ruben06]

Ik denk dat hier eerder gedoeld wordt op shared hosting.

Maar volgens de bevindingen die ik heb, is dit ook perfect mogelijk mits je een goed controle panel hebt zoals Direct Admin waar je buiten de public_html folder om nog andere folders kan aanmaken én de rechten hiervan kan aanpassen

[tszcheetah]

Als je kijkt naar het aantal installaties op de projectpagina's van de modules, staat RESTws (5804 installs) boven Webform multi upload (3076). Coder staat ertussenin (4951) qua installs, maar het zou me niks verbazen als die module op veel productieomgevingen aanwezig is maar uitgeschakeld staat, omdat die simpelweg is meegekopiëerd uit de ontwikkelomgeving.

Dus Coder is het ernstigste lek, maar zal bij fatsoenlijke beheerders niet aanwezig zijn. RestWS is ook behoorlijk kritiek (gezien aantal installs en het feit dat alle gebruikers het lek kunnen misbruiken). Webform multi file upload heeft nog de mitigation factor dat gebruikers bepaalde rechten moeten hebben - dus het risico is daar wat kleiner.

[Verwijderd]

Wist niet dat Drupal tegenwoordig op Symfony verder gegaan is. Iets, wat in mijn ogen, zeer zeker geen verbetering is. (geen fan van die Fabien e.d.)

Nogal de plank misgeslagen, als je de architectuur er niet verder voor aanpast. Had je net zo goed en beter, geen symfony kunnen gebruiken.

Typisch dat Joomla 'hoger' scoort dan Drupal. Drupal is een van de weinige systemen, waar ik zelf nog nooit iets actiefs mee gedaan heb. (wel eens aan geknutseld, maar nooit van mezelf)

[rvec]

Drupal is niet gebaseerd op symfony, maar gebruikt onderdelen uit symfony.
zie ook de composer.json van drupal core:
http://cgit.drupalcode.or...ore/composer.json?h=8.1.x

Volledig symfony based is bijvoorbeeld https://octobercms.com/ .

[Verwijderd]

Ook in mijn ogen geen pluspunt.
Meestal krijg je onnodig veel zooi mee om alleen maar eventjes een command line interpreter te kunnen gebruiken.
De meeste developers lijken ontzettend lui te worden en nemen maar een beetje van alles over. Het wiel hoeft niet opnieuw uitgevonden te worden, maar men kijkt ondertussen niet meer naar het wiel.

Zolang ze maar geen Doctrine gebruiken, waarin je eigenlijk niks echt goed kan, behalve met een extreem simpel database ontwerp (neem al die tijd om native SQL te leren en je kan veel meer)

[Koeniepoenie]

Als je nog nooit iets met Drupal hebt gedaan, laat staan Drupal 8, hoe kun je dan oordelen of Drupal 8 met Symfony geen verbetering is?

De architectuur is namelijk gigantisch aangepast in D8 tov D7. Daarnaast zijn er vele andere verbeteringen in D8 (ik ga ze hier niet allemaal opnoemen). Daarnaast zijn de gevonden lekken zitten in D7 modules, niet D8.

[Verwijderd]

Ik ken Symfony wel.. Werk nu met een paar projecten, waarin het opgenomen is. Alleen de semantiek (hoewel niet belangrijk) vind ik afschuwelijk.
Mijn onvrede ermee komt eigenlijk voornamelijk door Fabien Laurencier o.i.d. (een van de oprichters ofzo), omdat ik zijn seminar verhaaltjes niet kon luchten en gewoon niet op 1 lijn met hem zat. (al ben je Frans, spreek gewoon 'http' uit)

Ik ken niet oordelen of D8 beter dan D7 is, maar ik raak D8 in ieder geval nooit aan, als het verbonden is aan Symfony.
Doorgaans vind ik (het is een subjectieve kwestie) dat systemen ala Symfony wel het doel dienen, maar veel te omslachtig en langzaam.
Als je tig aantal caching / workarounds moet verzinnen om iets normaal te laten draaien en het relatief gesproken tussen de 10-100x langzamer is, dan oudere systemen. Nee, investeer dan gewoon even de tijd en gooi dingen als Symfony weg.
Voor de ervaren programmeurs is het gewoon onnodig en je hebt niet de code van een ander nodig om aan dingen ala exploits/security te denken. Dit is de ervaring van de programmeur en dus niet iederen kan zonder de frameworks.

[jordees]

D7 modules zijn ook nog lang niet allemaal geschikt voor D8. Daarnaast is een upgrade naar D8 vanaf D7 vrij complex en daar zit niet iedereen op te wachten. Zodra D8 mainstream wordt, zullen ook daar de lekken gevonden gaan worden. Er zijn nog niet heel veel websites op D8 te vinden. Zolang is D8 ook nog niet beschikbaar.

[Koeniepoenie]

Snap ik en ben het met je eens, alleen dit was niet helemaal mijn punt

Ik vond het afbranden van D8+Symfony op deze wijze geheel niet terecht.

[jordees]

Daar geef ik je gelijk in. Symfony is een zeer krachtig en robuust framework en D8 maakt daar dankbaar gebruik van.

[Strunkie]

Wat is er volgens jou mis met Symfony dan?

[Olaf van der Spek]

Ik vind jammer dat drupal de modules nog niet buiten de public directory plaatst.

Maakt dat echt uit? Welke kwetsbaarheden zou dit oplossen?

[REDSD]

Een aantal exploits komen doordat er POSTS naar files gedaan kunnen worden, het feit dat drupal CSS en JS in laad vanuit de module folder, zorgt er voor dat je snel kunt zien welke modules er draaien binnen de installatie.

[rvec]

https://web.nvd.nist.gov/...h_type=last3years&cves=on

Er zijn daar verrassend weinig PHP vulnerabilities. Misschien is PHP juist wel veilig .

[thePiett]

Het is de fout van PHP dat er Drupal modules zijn die lek zijn?

[thePiett]

Dit betekent of dat PHP onveilig is (klopt) of dat veel van de ontwikkelaars die PHP gebruiken gewoon geen professionele ontwikkelaars zijn, maar hobbyisten (klopt ook) die eigenlijk maar beperkt benul hebben van programmeren en dus ook niet kunnen overzien dat hun broddelwerk miljoenen mensen aan risico blootstelt.

Waar baseer je je statement "PHP is onveilig" op?

Betreffende de hobbyisten... Dat is jouw ervaring. Denk je nou echt dat een stel hobbyisten veelgebruikte CMS'en als Drupal en Wordpress in elkaar zouden kunnen flansen zonder dat het aan alle kanten uit elkaar dondert? Het gaat in dit geval meer om de 3rd party modules die zo goedkoop en zo snel mogelijk in elkaar gehackt zijn. Dit heeft niets met de professionaliteit van PHP ontwikkelaars of met PHP zelf te maken.

Er zijn zat PHP ontwikkelaars die zéér professioneel te werk gaan en diepgaande kennis hebben van de systemen die ze gebruiken. Ze hebben ervaring in systeem- en netwerkbeheer, gebruiken elke dag Linux en weten dus wat daar speelt, ontwikkelen hun kennis elke dag verder en hebben genoeg geprogrammeerd in C om te begrijpen hoe een computer werkt. Daarnaast hebben ze ook zat in andere talen als Java en C# geprogrammeerd. Ik ben er één van.

Ze worden daarnaast ook zeer moe van mensen die ongefundeerd hun favoriete en zeer goed werkende platform om fantastische webapplicaties te bouwen afbranden. Dát is pas onprofessioneel!

[Verwijderd]

In het verleden zijn er veel vulnerabilities in de PHP interpreter zelf gevonden die remote code execution mogelijk maakte.

Ja, ik denk dat veel van die CMS'en door hobbyisten zijn begonnen omdat PHP zo snel en eenvoudig programmeert. Waarom zijn er relatief weinig CMS'en in Java en .NET geschreven? Omdat het voor beginners veel moeilijker is om iets mee te maken.

Ik beroep mij op empirisch bewijs, namelijk dat bijna elke maand of week wel een fout in één van die in PHP geschreven applicaties wordt gevonden die de hele site opengooien en het mogelijk maakt om een netwerk binnen te dringen. Dat zijn gewoon feiten, niks onprofessioneel aan.

[thePiett]

Je kunt juist met o.a. PHP snel iets bouwen omdat de tools makkelijk te verkrijgen zijn en de benodigde systemen snel op te tuigen zijn. Binnen een paar minuten heb je een VPS draaien met nginx, MariaDB en PHP. Succes met je .NET dingetje achter IIS met het dik beboste woud van licenties of eindeloos gedoe met Mono. Dat heeft niks met PHP zelf te maken.

PHP is niet veel moeilijker / makkelijk dan Java of whatever else, net als .NET zijn dit talen die eenvoudig te leren zijn omdat ze nogal high level zijn.

[timbo007up]

In het verleden.. en vroeger had java ook veel remote code execution mogelijkheden, net zoals ASP, en zelfs C als je even je best deed.. Wat wil je hiermee zeggen?

Tegenwoordig is php steeds meer een proffesionele programmeer taal, met helaas nog wel veel startende programmeurs die een werkend, maar potentieel onveilige module leveren omdat ze er gewoonweg geen oog voor security hebben. Het klopt inderdaad dat het moeilijker voor beginners is om met java of .net iets te maken. Ik durf je ook met 100% zekerheid te zeggen dat ook de systemen die in java of .net geschreven net zoveel fouten bevat. Ze worden alleen minder gevonden omdat er minder aandacht is voor systemen die amper gebruikt worden.

Windows zit ook vol gaten. Is dat ook onproffesioneel? Maar prima jij bent geen php fan, succes met het schrijven van volledig onkraakbare code. Ik vind php een prima taal en zoals elke taal heeft het zo zijn haken en ogen, maar tja php is onveilig by design... net zoals jou manier van denken... er zijn een paar lekken gevonden in iets wat buiten het standaard platform om geschreven is.. daarom is het hele platform lek.. Veel plezier met windows, linux, unix, mac of whatever... want daar zijn ook nooit lekken in applicaties gevonden die volledig los staan van het os.. daarom gelijk maar het hele OS afzweren. Ik wens je succes

[Somoghi]

Een oud nederlands gezegde luidt: hoge bomen vangen veel wind.
Als het dan ook nog eens veelgebruikte bomen zijn is het niet zo gek dat er meer aandacht voor is, van zowel media als hackers.

Jouw reacties doen me denken aan kennissen die mij zeer stellig vertelden dat een Mac geen virus kan krijgen. Windows was slecht want dat stond er om bekend.

[ruben06]

Ik snap niet waar u deze bevindingen haalt.

Drupal is een CMS dat gebaseerd is op PHP, net zoals Wordpress (waar ook beveligingslekken in zitten) maar kom a.u.b niet verkondingen dat in CMS'en die op een andere programmeertaal gebaseerd zijn bugvrij zijn....

Een goede programmeur weet dat geen enkele software geschreven 100% bugvrij is.

Uw reactie komt trouwens ook denegrerend over naar webontwikkelaars in PHP. U kan er zeker van zijn dat een groot deel van de programmeurs in PHP ook snel weg zijn met andere programmeertalen zoals C#, java, python, ....

[ruben06]

Fout, er zijn zat backend developers in PHP die weinig kennis hebben van front-end technologieën.

Een voorname rede waarom je dit soort lekken niet ziet in CMS'en en webshops gebaseerd op Java of C# in uw voorbeeld kan bijvoorbeeld ook komen dat er veel minder (gekende) systemen bestaan in deze talen ten opzichte van PHP.

Ik heb anderhalf jaar als all round webdeveloper gewerkt met PHP, ben nu sinds een half jaar naar asp.net overgestapt maar moet toegeven dat ik daarvoor nog nooit van bijvoorbeeld het umbraco cms gehoord heb...

[eborn]

Daarbij speelt ook mee dat veel andere talen CMS'en als closed-source aanbieden. Dan wordt het sowieso al lastiger om exploits te achterhalen. Als dan de gebruikersgroep ook nog minimaal is, loont het niet om er teveel tijd aan te besteden.

[rvec]

https://www.playframework.com/security/vulnerability
Java based webframework, had in 2014 een vulnerability waarbij het hele filesystem kon worden uitgelezen. En dit is alleen een framework, niet een volledig CMS met duizenden modules.

[thePiett]

Oracle's JRE slaagt erin binnen 6 jaar bijna net zoveel CVE's te produceren als PHP in 16 jaar... (http://www.cvedetails.com...cle-JRE.html?vendor_id=93 vs https://www.cvedetails.co...PHP-PHP.html?vendor_id=74).

Best knap voor het hobbyclubje PHP!

[Verwijderd]

PHP is open source = dus meer projecten = dus meer exploits?

[eborn]

Of PHP draait op ruim 80% van de websites en heeft daardoor iets meer kans om met een fout in het nieuws te komen dan een obscuurdere taal. Geloof me, er lopen genoeg slechte ASP.NET, Java en Python developers rond.

[Strunkie]

En weer een developer die zijn werk niet goed gedaan heeft...

[Wim Leers]

Drupal is geen bedrijf.