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...

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 .

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

@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