Hier staat het whitepaper https://community.qualys.com/docs/DOC-1351.

Er zitten kwetsbaarheden in de desbetreffende versies, maar zo lek als een mandje zou ik het lang niet altijd noemen.

Daarom installeer je phpMyAdmin ook in een directory waarop je jezelf ook eerst moet authenticeren voordat je bij phpMyAdmin komt. Als niemand er bij kan (en waarom zouden ze daar ook rechten toe hebben. Dat is nergens voor nodig), kunnen ze ook geen exploits proberen...
Als een hacker er niet bij kan, kan hij het ook niet stuk maken...

phpMyAdmin is een mooie tool, maar de onderliggende code is echt retegaar. Het knutselniveau waarmee die tool in elkaar gezet is. Na zoveel jaar zouden die gasten toch beter moeten kunnen coden. En over de codekwaliteit van Drupal ga ik nieteens beginnen...

Ook ik heb diverse sites die op een oudere versie van Drupal draaien. Simpelweg omdat de gevonden kwetsbaarheden in het geheel niet relevant voor de site zijn.

Overigens kan men in Drupal een emailadres opgeven, waarna het systeem informatie over eventuele updates naar dat adres stuurt. Daar is de blinde olifant dus niet voor nodig.

@hugo, die opmerkingen kun je kwijt op http://drupal.org/node/add/project-issue/drupal .

Dat is als tegen een junkie zeggen dat drugs slecht is...

Voorbarige conclusie? "lek als een mandje".

Ik heb het rapport gelezen, de conclusie die ik kan trekken is dat er een percentage oudere versies applicatiesoftware operationeel zijn, ouder dan de huidige versie. Of dit een veiligheidsprobleem is (lek) hangt af van meerdere variabelen; waaronder de gegevens die op de website staan, de instellingen van de server, het os, het backup management systeem en de webapplicatiesoftware. Om te bepalen of een applicatie zo lek als een mandje is en daarmee een veiligheidsrisico zal er per applicatie (domein) een analyse gemaakt moeten worden.

Het is vrij normaal dat er oudere applicatie versies operationeel zijn; niet iedere webapplicatie eigenaar heeft de (financiële)mogelijkheid om alle (veiligheids)updates te (laten) installeren. Het belang van veilige webapplicaties en het installeren van veiligheidsupdates ontken en onderken ik niet. Echter enige nuance had security.nl hier wel in kunnen aanbrengen, ook in het rapport van het beveiligingsbedrijf Qualys zie ik de conclusie niet terugkomen (of heb ik die gemist?).

Het installeren van veiligheidsupdates behoort absoluut tot één van de onderhoudsaspecten van een webapplicatie. Veiligheid bij webapplicaties is echter meer dan updaten naar de laatste versie. Het is niet zinvol een veiligheidsupdate te installeren die betrekking heeft op een niet gebruikt onderdeel. Oudere versie kunnen daarom net zo veilig (of onveilig) zijn dan de laatst uitgebrachte versie.

"Standaard-webapplicaties zijn vaak doelwit van aanvallers om ingezet te worden voor de verspreiding van malware,” zegt Qualys. Daar kan ik me wel iets bij voorstellen. Aan ons, leveranciers en bouwers van webapplicatie de mooie taak deze standaard veilig op te leveren en onze klanten, hierin professioneel te adviseren.

Martin N.
CMSeasy

@Hugo: Je hebt zeer zeker gelijk als je zegt dat je "niet over de codekwaliteit van Drupal wilt beginnen". Maar ik daag je uit dat toch te doen.
- Zie jij foutent in de architectuur die beveiligingsproblemen veroorzaken of dat zouden kunnen?
- Waar zie jij specifiek slechte kwaliteit code?
- Hoe zou jij adviseren dat anders te doen?

Zonder dat soort vragen te bantwoorden is je post precies FUD. En niet meer dan FUD.
-- Bèr

@Bèr

Twee jaar geleden heb ik als freelancer een aantal maanden voor een bedrijf gewerkt dat website bouwt op basis van Drupal. Mijn grootste probleem met Drupal is dat het chaotische code is. Drupal maakt gebruik van hooks waardoor een pagina code uit een andere pagina kan gebruiken. Dat klinkt leuk, maar bij wat grotere websites roepen alle pagina's elkaar aan, waardoor je al gauw het overzicht kwijt raakt van welke code allemaal wordt uitgevoerd bij de aanroep van een bepaalde pagina. Ik heb bij dat bedrijf een website gezien waarbij bij de aanroep van een bepaalde pagina bijna de gehele website aan code werkt ingeladen. Traag als taaie stront dus.

Daarnaast maakt Drupal zeer inefficient gebruik van de database. Ik heb metingen gedaan en kwam bij een simple pagina met 15 elementen in een lijstje op meer dan 400 database queries, terwijl niet meer dan 10 nodig zijn om de pagina te kunnen bouwen. Dat maakt Drupal nog trager. De website die lokaal op mijn ontwikkelmachine stond, laadde trager in dan een website op een remote server van mij.

Drupal kent (kende toen iig niet) geen aparte view. De prints staan overal door de code heen. Maakt hetgeen nogal onleesbaar.

Toendertijd was Drupal redelijk hard geprogt rond Apache. En in tegenstelling tot wat veel mensen denken houdt Apache zich ook niet altijd netjes aan de standaarden. Toendertijd was Drupal niet echt webserver onafhankelijk. Je zat dus vast aan Apache.

Los van de hooks bevat Drupal veel functiecalls bij een normale page request. Ik heb een keer geprobeerd om de complete run bij een pagina aanroep te doorlopen. Na de 30ste functie aanroep in meer dan 10 verschillende bestanden was ik de draad compleet kwijt. Niet te doorgronden.

Wat heeft dit alles met security te maken? Alles. Drupal is letterlijk spagetticode. Onnodig complex waardoor onnodige fouten gemaakt worden die tot beveiligingslekken kunnen leiden. En 'to prove my point': http://secunia.com/advisories/search/?search=Drupal

@Hugo Dank je wel voor je uitgebreide onderbouwing. Punt voor punt:

1 spaghetticode
De onderliggende code in Drupal is complex door de hooks. De kracht hiervan is dat Drupal intern geweldig goed kan communiceren. De performance penalty die daarmee gepaard gaat is tijdens ontwikkeling een factor maar Drupal kent zeer goede caching- en optimalisatietechnieken om dit in een productieomgeving teniet te doen. Lees https://www.packtpub.com/drupal-6-performance-tips-to-maximize-and-optimize-your-framework/book. Laag hangend fruit is de installatie van de view_content-cache module.

2 database layer
Drupal's database layer is voor Drupal 7 volledig geabstraheerd. Ervaar het verschil in de eerste Beta.

3 coding practices
Als themer had ik vooral moeite met print statements in phptemplate. Ik miste Smarty. Phptemplate voelde meer als php dan als template language. Nu ik eraan gewend ben zie ik dit meer als voordeel dan als nadeel. Ik ben lui en leer liever eenmalig een universele taal als php dan voor ieder cms een nieuwe template taal te leren.
Ik vind niet dat de code in core slordig is. In contrib is dit ook in drupal 6 soms nog wel het geval, afhankelijk van de schrijver van de module en los van de hooks. Maar de sterke beweging in de richting van api's, de verbeteringen in het schrijven van simpletests, de nieuwe testbot en het fantastische api.drupal.org hebben bijgedragen tot enorme verbeteringen in de code. Waar het aan schort zijn best practices en standaardisatie voor ui-code. Maar in 2009 is een ux-team opgericht dat zich erop richt dit in Drupal 7 te verbeteren.

4 webserver
Drupal 6 draait bijvoorbeeld net zo makkelijk op nginx als op apache, beperkingen in de mogelijkheden van nginx daargelaten.

5 aantal functieaanroepen
Functieaanroepen blijven een aandachtspunt. Niet het aantal calls maar hoe economisch ze zijn is daarbij van belang. Een interessante discussie hierover staat op http://fourkitchens.com/blog/2010/02/03/making-drupal-pressflow-more-mundane en dan met name de commentaren van Larry Garfield en Matt Butcher.

6 security advisories
Je bent niet de eerste die de secunia advisories verkeerd interpreteert. Een groter aantal security advisories betekent alleen maar dat het Drupal security team in een steeds wijdere cirkel beweegt bij de speurtocht naar bugs. Zodra bugs worden gevonden en opgelost wordt dit zo breed mogelijk gecommuniceerd. Beluister de podcast op http://www.lullabot.com/podcasts/drupal-voices-122-greg-knaddison-on-drupal-security.

Wat het rapport rond BlindElephant benadrukt is dat veel Drupal-sitebeheerders hun systeem niet goed updaten. Dat vind ik een stukje eigen verantwoordelijkheid maar het is wel zo dat het updaten van Drupal 6 (core) best een gedoe is. Niet iedereen beschikt over aegir of drush of weet hoe hij/zij makkelijk een gedeelde codebase toepast. Een van de belangrijkste ux-verbeteringen in Drupal 7 is de mogelijkheid om updates via de webinterface uit te voeren. Dat zal het percentage sites met achterstallig onderhoud aanzienlijk naar beneden brengen.

Willem

@willem:

1: beetje raar dat allerlei cache- en optimalisatietruukjes nodig zijn om een ontwerpfout goed te maken. Helemaal raar dat je het brengt alsof dit de normaalste zaak van de wereld is. Een fout ontwerp blijft een fout ontwerp, wat je daarna ook verzint als lapmiddel.

3: smaken verschillen, maar ik houd wel van het MVC principe. Dat maakt het restylen van een website ook stukken makkelijker.

6: leuk excuus, maar een security bug is en blijft een security bug. Maakt niet uit hoe mooi het kroontje is dat je erop plaatst. En zeggen dat ik een melding over een securitybug in drupal 'verkeerd interpreteer' is ronduit laf. Dat het drupal security team meer bugs vindt door in een wijdere cirkel te bewegen, geeft in mijn ogen niet aan hoe goed het team bezig is, maar hoe slecht de drupal code is.


Hoe dan ook, in mijn ogen is al die complexiteit van drupal totaal niet nodig. Helemaal als ik m'n eigen framework ernaast leg, dan ben ik blij dat ik niet met drupal hoef te werken. In mijn eigen framework kan ik alles wat drupal kan, alleen dan wel snel, wel makkelijk te doorgronden en wel veilig.