Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Open Source CMS'en: hip maar onveilig?

Open source cms'en worden steeds populairder. Pakketten als Alfresco, Joomla, Wordpress en Drupal worden steeds vaker ingezet voor interne en externe websites. Deze pakketten voldoen aan de criteria voor de volgende generatie cms'en, oftewel ze passen prima binnen Enterprise 2.0. Forrester (1) signaleerde in 2008 dat cio's serieus zouden moeten kijken naar met name Drupal en Alfreso. Een uitspraak die mede is gebaseerd op het feit dat de stabilteit en het aantal implementaties voldoende zijn om het als serieuze optie te overwegen, zoals later wordt toegelicht in een interview met CNET (2).

Zijn open source cms'en echter ook op security vlak enterprise waardig? Een artikel uit Informationweek dat vrijwel tegelijkertijd met het zojuist genoemde Forrester rapport uitkwam, zet een aantal kwetsbaarheden in verschillende pakketten op een rij voor onder meer Moveable Type, Wordpress, Drupal en Joomla.

Toegegeven, niet elk lek is even ernstig, maar sommige toch zeker wel. Zo kwam er in Joomla 1.5.x vorig jaar augustus een lek aan het licht dat het mogelijk maakte om volledige controle te krijgen over het cms. Ook kon In versie 4 van Drupal relatief eenvoudig zelfgeschreven programmacode door internetgebruikers worden uitgevoerd dankzij een lek in basis van het systeem. Een analyse van de andere open source cms'en laat zien dat (ernstige) lekken daar net zo goed voorkomen. 

Veiligheid in open source laat dus te wensen over. Vooropgesteld dat veiligheid geen exacte wetenschap is, kunnen er zeker een aantal nuances bij deze bewering worden geplaatst.

Zo is het aantal installaties van Drupal en Joomla aanzienlijk hoger dan van bekende closed source cms'en zoals Tridion, Green Valley of SiteCore. Daardoor wordt het een meer aantrekkelijke prooi voor hackers en raken lekken sneller bekend. Ook is het aantal modules bij open source veel groter. Voor Drupal zijn er duizenden modules en voor closed source cms'en gemiddeld minder dan vijftig. Doordat er meer modules zijn, is de kans dat er één een veiligheidslek bevat groter. Daarnaast is het gebruikelijk om veiligheidslekken snel bekend te maken bij open source, wat bij kleinere closed source cms'en ook minder aan de orde is.

Verder is het zo dat er een aspect is te benoemen dat zeer belangrijk is voor veilige (cms-) software. Dat betreft de integrale inbedding van reviews op code en anticipatie op mogelijke gevaren.  Kortom: veiligheid is iets dat besloten moet zijn in de software ontwikkeling van een cms. Deze bevinding is ook te lezen in een rapport dat is geschreven over de veiligheid van Drupal. Hierin wordt gesteld dat securtiytraining van ontwikkelaars en het beschikbaar stellen van een eenvoudige api sleutelfactoren zijn voor een veilig systeem.

Nu lijkt het trainen van de ontwikkelaars lastig te organiseren voor de community van bijvoorbeeld Drupal. Dit is dus een punt van aandacht, wat dan ook geadresseerd is. Pakketten zoals Drupal en Joomla hebben  een integrale controle op de veiligheid van alle modules door een verplichte review door een security team.

Na al deze punten op een rijtje te hebben gezet, kan denk ik worden gesteld dat een open source cms niet per se veiliger of onveiliger is dan een closed source cms. Immers, hoeveel veiligheidsissues lost Microsoft niet op in bijvoorbeeld Internet Explorer. En hoe veilig is SharePoint als cms nu eigenlijk? Als we hier op afgaan, lijkt het aantal security incidenten eerder een verband te hebben met de schaal waarop de software wordt toegepast , dan met het feit of het open of closed source is.

Met dat in het achterhoofd, is er toch nog een belangrijk verschil te benoemen. De verantwoorlijkheid ligt bij open source anders dan bij closed source. Waar bij closed source de verantwoordelijkheid voor de security meer bij de Vendor ligt, zal deze bij open source meer bij de implementerende partij liggen. Immers, de open source community kan moeilijk aansprakelijk worden gesteld als rechtspersoon. Dit kan met een system integrator echter wel.

Om deze verantwoordelijkheid goed te nemen zal de implementerende partij bij het gebruiken van cms-modules telkens extra moeten toetsen op security. Ook zal de integrator moeten controleren of modules zijn vrijgegeven door een security team, er een goede ondersteuning is en of er patches beschikbaar zijn.


(1) Forrester, 2008. http://forrester.com/Research/Document/Excerpt/0,7211,46162,00.html
(2) CNET, 2008. http://news.cnet.com/8301-13505_3-9973824-16.html

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/2871629). © Jaarbeurs IT Media.
?

 

Reacties

Een pakket als Wordpress heeft tegenwoordig een geweldige auto-update functies, ook voor de plugins. Bij het bedrijfsmatig gebruik van dergelijke pakketten is het belangrijk om afspraken te maken over regelmatige updates. Bedrijven die dit niet doen, snijden zichzelf in de vingers. Ten eerste hebben ze een boze klant en ten tweede kunnen ze geld verdienen door een vast bedrag per maand/jaar te vragen voor het bijhouden van de software.

Deze open source pakketten zijn in de regel zeer veilig. Patches zijn vaak snel gemaakt en worden snel vrijgegeven. De problemen met bijvoorbeeld Joomla zijn vrijwel altijd te wijten aan het niet bijhouden van security updates. Doordat het op zo'n grote schaal gebruikt wordt, is het voor crackers interessant om gericht en geautomatiseerd op zoek te gaan naar Joomla sites.

Een open source pakket zoals Drupal, Joomla, Wordpress of Typo3 heeft ook als voordeel dat er zeer veel ontwikkelaars tegelijk mee bezig zijn, waardoor er veel sneller security-leaks ontdekt kunnen worden en er dus ook veel sneller een oplossing voor wordt aangeboden.
http://www.mia.be

Dit is een tamelijk ongenuanceerd artikel, er zijn namelijk enkele honderden open source CMS-sen. Ik geloof niet dat dhr. Wasse die allemaal kent.

@Jan: ik heb geprobeerd de meest gebruikte Open Source CMS-en te bekijken. Verder kijk ik naar het model waarmee open source software tot stand komt. Dat zou dus niet heel anders moeten zijn bij andere CMS'en.

Dus wellicht zijn sommige Open Source CMS'en veiliger of gaan ze anders met veiligheid om. Dit neemt mijn punt niet weg.

Aardig artikel en inzichtelijk. Echter, refereren naar veiligheidsissues in Drupal 4 is niet echt relevant nu versie 7 alweer in de maak is. Van Drupal is ook een commerci?le variant, Aquaio, waar het voor een implementerende partij mogelijk is om middels ??n beheerinterface de benodigde updates te zien van alle door deze partij gemaakte websites. Zo kan een beheer-afdeling eenvoudig zorg dragen voor het patchen van veiligheidslekken. Versie 6 van Drupal heeft de Update Status module ingebakken, zodat de beheerder gelijk doorkrijgt via de mail of de site aan een update toe is.

Open Source leveranciers als Alfresco, Joomla, Wordpress en Drupal op een hoop gooien, is wat mij betreft hetzelfde als oplossingen als FileNet van IBM, Documentum van EMC en Smartsite over een kam scheren. Dit is blogsoftware, web content management en Document Management/ECM op een hoop gooien. Beetje ongenuanceerd inderdaad. Dat je geen bedrijfskritische online uitingen moet draaien in eenvoudige "freeware" oplossingen lijkt me een kwestie van GBV. Ga dan voor supported versies van Open Source die wel Enterprise Solutions bieden. Het jammerlijke van dit soort uitingen is dat het bijdraagt aan een onfundeerd angstig sentiment ten opzichte van Open Source.

En wat te denken van e-commerce systemen als Magento? Als er ergens waardevolle informatie vandaan gehaald kan worden, dan is het wel bij e-commerce systemen.

@Paul: Ik herken koudwater vrees om een open source CMS bedrijfsmatig toe te passen. Dit sentiment probeerde ik te adresseren ten aanzien van het hiermee verbonden veiligheidsaspect.

Er is volgens mij dus in de basis GEEN reden tot extra voorzichtigheid, het is wel zaak om (technische) support goed te borgen. Het nemen van een commercieel ondersteunde variant van een OS CMS kan inderdaad een prima oplossing zijn.

Jammer dat er in dit artikel alleen naar bronnen van Amerikaanse origine is gekeken. Een pakket als TYPO3 heeft inderdaad in Amerika minder naamsbekendheid en toepassing, maar is in Europa een van de meest toegepaste open source content management systemen. Amerika is echt anders dan Europa.

Roy schreef: "Veiligheid in open source laat dus te wensen over."

Reactie: Bij closed source software is het veel slechter gesteld als het gaat om het fixen van bugs (want daar hebben we het hier over). Microsoft moet bijvoorbeeld om de haverklap nieuwe security patches uitbrengen. Bij open source kan hier een hele community aan werken. Bij closed source (vaak) alleen de editor. Dus het risico is bij closed source veel groter.

Roy schreef: "Waar bij closed source de verantwoordelijkheid voor de security meer bij de Vendor ligt, zal deze bij open source meer bij de implementerende partij liggen."

Reactie: "Security" heeft vooral te maken met de wijze waarop software wordt geimplementeerd en de processen eromheen. Closed source vendors nemen geen verantwoordelijkheid als het gaat om de veiligheid van de software of implementatie. Welke verantwoordelijkheid nemen bijvoorbeeld Microsoft of Oracle als het gaat om veiligheid? Bij closed source sluit je een licentieovereenkomst af om gebruik te mogen maken van de software en een support contract zodat je ze helpen bij problemen. That's it. Bij open source software zie je juist dat bugs sneller en beter worden opgelost dan bij closed source. De active community heeft een zeer waardevolle rol. Voor gebruikers en system integrators is het wenselijk (soms vereist) dat zij terug kunnen vallen op een professionele supportorganisatie. Ook deze dienst wordt bij open source vaak aangeboden.

Ik ben het met de meeste reacties eens. Het is wel heel makkelijk om te zeggen dat open source niet veilig is. Vertel dat maar eens tegen die ict-afdelingen die apache http en linux op alle servers gebruiken.

Wat betreft CMS, tuurlijk zul je hier problemen vinden. Maar die vind je in closed source net zo goed. Veel van deze security problemen zijn gedeeltelijk te omzeilen door het CMS achter https te zetten of zelfs via vpn toegankelijk te maken.

Bij een CMS is er een groot verschil tussen de website die content uit de repository haalt en een CMS die voornamelijk gebruikt wordt om content in diezelfde repository te managen. Als je gewone gebruikers toegang geeft tot je volledige applicatie heb je altijd risico's. De scheiding is bijvoorbeeld met een cms als Hippo (Nederlands en Open source) eenvoudig te realizeren.

Ik zou je stelling willen omdraaien, kun je veiligheid kopen middels een licentie? Of kun je veiligheid behalen door sources niet beschikbaar te stellen? Ik denk dat je beide vragen met een nee kunt beantwoorden.

Prima artikel. Het stelt dat open source pakketten een prima alternatief kunnen zijn, maar dat er een andere rolverdeling aan de orde is. Als je met degene die de implementatie doet geen expliciete afspraken maakt rond beveiligingstests e.d.(en dus ook aangeeft welke risico's je wel en niet acceptabel vindt) en actie onderneemt op de resultaten daarvan, loop je risico's. Deze zijn groter dan bij een 'closed' variant, aangezien de leverancier daar weet dat hij direct aansprakelijk gesteld kan worden als mocht blijken dat het pakket lek is.

"De verantwoorlijkheid ligt bij open source anders dan bij closed source. Waar bij closed source de verantwoordelijkheid voor de security meer bij de Vendor ligt, "

Welk recht kan ik als klant ontlenen aan het feit dat een vendor 'verantwoordelijk is' als er iets fout gaat waardoor ik schade heb?

Volgens mij geen enkele en dit is dus een volstrekte wassen neus, schijnzekerheid voor onzekere IT-managers en inkopers. Behalve in specialistische medische en luchtvaart applicaties is er vrijwel geen software waar de leverancier aansprakelijk is voor de gevolgen van fouten. Hou dus op met dit soort onzin.

Wat een achterhaald artikel zeg.

Op 1 punt kan ik het met de schrijver eens zijn: Modules kunnen onveilig zijn, maar dat heeft niets te maken met OpenSource, maar simpelweg dat er niet goed genoeg naar gekeken is. De verantwoordelijkheid ligt dus bij de gebruiker, maar je mag er vanuitgaan dat dat een professional is die weet wat hij doet.

Helaas ontbreken een aantal goede systemen in dit lijstje;
metname Silverstripe (opensource) is een pakket dat bijvoorbeel een duur pakket als LiveLinkCMS (closedSource) heeft ingehaald op tal van punten.
Ook HippoCMS is best interessant (alhoewel wel 'bloathed')


- Alex
www.lxer.nl

Wie wel eens de moeite heeft genomen een licentieovereenkomst te lezen weet dat bij closed source de 'vendor' zelden of nooit aansprakelijkheid van enige betekenis aanvaardt. Juist op het gebied van leveranciersaansprakelijkheid wijken open en closed source niet noemenswaardig van elkaar af.

Alle open source software heeft een zekere mate van onveiligheid omdat er directe toegang is tot de broncode. Ofwel, het grootste voordeel is tegelijk ook het grootste nadeel.

Want tussen al die geweldige programmeurs die dag in dag uit aan een OS pakket werken, zitten ook kwaadwillende gebruikers.

Zo simpel is het. Hoe mooi het verhaal ook eromheen bedacht wordt, dit is een fundamenteel verschil!!!

Ook denk ik dat het verschil (kan) ontstaan door twee totaal verschillende typen opdrachtgevers. Zo zal een partij die kiest voor open source in de meeste gevallen meer voor budget gaan, dan een partij die kiest voor een closed source variant.

Partijen die veel geld neerleggen voor een closed source pakket, zullen doorgaans ook veel meer investeren in de veiligheid en het onderhoud en veeleisender zijn, wat ook volkomen terecht is.

Ter toevoeging op een reactie betreffende de CS licenties, is iedere leverancier in Nederland wettelijk verplicht een deugdelijk product te leveren. Ieder bedrijf of instelling kan een leverancier ten alle tijden aanklagen op grond van een wanprestatie, ongeacht de leveringsvoorwaarde die de leverancier hiertoe ook stelt. Vooral wanneer de licentiehouder hiervoor een X bedrag per periode in de vorm van licentie betaalt, zal deze zeer sterk staan.

@Michael,

Als een leverancier aansprakelijk zou zijn voor onveiligheden binnen een product, dan zou Microsoft allang failliet moeten zijn.

Bugs zitten in ieder product.

Michael heeft blijkbaar geen enkele kennis van open source producten en/of projecten, dan had hij namelijk wel geweten dat niet iedereen zomaar code kan inchecken wat ook nog eens ongetest in een volgende release terecht komt.

Waarom gebruikers van closed source software meer geld over zouden hebben voor beveiliging dan open source gebruikers, geen idee. Het is wel een feit dat bv. Windows vele malen onveiliger is dan Linux, onder windows heb je altijd superuser rechten, je bent wel verplicht om extra geld uit te geven.

Overigens zit het grootste veiligheidsprobleem achter de computer, de gebruiker. En die wordt zonder licentie geleverd.

Michael, ga je eens verdiepen in software en dan zowel open source als closed source. Verschil in licentie wil niet zeggen dat er zomaar een verschil is in veiligheid. Veiligheid kies je zelf voor en bij de meerderheid van de gebruikers (zakelijk en prive) ontbreekt iedere vorm van een veiligheidsbeleid. Denk jij nu echt dat de licentievorm van de software hier iets aan verandert?

@Paul Jongen:
Inderdaad. Herinner je het 'teardrop' attack verhaal nog waarbij Linux binnen een paar uur gepatched was en dat het bij Windows zo lang duurde, dat providers routers maar de poort preventief dicht gingen gooien?

@Arjan Kamphuis:
Dit verhaal klopt ook helemaal. Rechtzaken kan je niet voeren als je bedrijf door de schade al failliet is verklaard. Die 'verantwoordelijkheid' is inderdaad een wassenneus en de beargumentering is zeer 90's.

Daarnaast moet ik zelf een kant-tekening zetten, waarvoor wil je de CMS als bedrijf gebruiken?

Dit neemt niet weg dat een CMS veilig moet zijn.

Maar hetzelfde verhaal zou zijn; Theoretisch kan een werknemer via zijn desktop met de juiste exploits de meest gevoelige bedrijfsgegevens ontfutselen. Conclusie: Desktops zijn slecht! :)

Computable Expert
Roy  Wasse

Roy Wasse
Directeur, OpenValue. Expert van Computable voor de topics Datamanagement, Development en Beheer.
Hele profiel

Vacatures Datamanagement

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×