5 veranderingen van CMS veiligheid in één decennium

Het landschap van content management systemen is in het afgelopen decennium enorm veranderd. Afgezien van de gevestigde orde – Joomla, WordPress, Magento e.d. – ontstaan er regelmatig nieuwe systemen die het helaas niet redden om het grote publiek te trekken.

De veiligheid in en waarmee met deze systemen omgegaan wordt is in deze periode ook veranderd.

Van “bugs” naar “niet updaten”

Het grootste probleem in de veiligheid is én blijft niet het systeem zelf, maar de mens. Vroeger zat vaak het risico in de geschreven code van de programmeurs, echter na ontelbare jaren fouten oplossen en beveiliging toevoegen, ontstaat een relatief zekere omgeving. Zolang men de applicatie update is er dus niets aan de hand, vroeger was dit update proces een zware taak en daarom vooral voorbehouden aan technisch onderlegde webmasters.

Het probleem tegenwoordig is dus niet meer de code, maar de gebruiker die het vertikt om de applicatie te updaten. Juist het updaten is in de meeste systemen ook nog eens vergemakkelijkt; zie bijvoorbeeld wordpress. Het nadeel daarbij is dat deze systemen aannemen dat je regelmatig inlogt en ook bewust de update-knop drukt. Bij HostingXS merken we dat klanten het veelal vergeten of niet voldoende technisch onderlegd zijn om te begrijpen dat updaten strikt noodzakelijk is.

Van “non-modulair” naar “3rd party dependancy”

De vroege versies van de meeste CMS’en waren niet uitbreidbaar, afgezien van een aanpasbare theme (cq. template). Hierdoor lag de volledige verantwoordelijkheid van de veiligheid bij de ontwikkelaars van het CMS; deze core developers in hun vrije tijd zorgden voor snelle patches.

Ieder CMS is dichter naar de wens van de gebruiker gegaan. Daarmee ook de mogelijkheid om eenvoudig het systeem uit te breiden. Zo gebruikt Joomla componenten, modules en plugins, WordPress gebruikt plugins en Magento extensions. Verantwoording voor iedere plugin ligt in dit geval bij de ontwikkelaar; vaak wordt er in deze plugins ook nog eens gebruikt gemaakt van code die niet gelieerd is aan de plugin of het CMS. De veiligheid van het CMS voor onder andere MySQL injecties en Cross-site scripting (XSS) ligt in dit geval bij de ontwikkelaar van de plugin.

Een goed voorbeeld van zo’n afhankelijkheid bleek uit de problemen met Timthumb; deze code kan op eenvoudige wijze plaatjes real-time schalen. Een erg fijne oplossing en daarom ook ruimschoots ingezet door veel wordpress themes en plugins. Helaas kon een kwaadwillende vanaf een willekeurige website een malafide bestand naar wordpress uploaden en zodoende ieder commando uitvoeren. Het duurt natuurlijk even voordat zo’n probleem gerapporteerd wordt, het duurt echter nog veel langer voordat iedere plugin en theme deze update uitrolt.

Van “afdoende” naar “aanneembare versleuteling”

Wat vroeger als voldoende wachtwoord beveiliging gezien werd is de MD5 versleuteling, uit den boze was sowieso het onversleuteld – ook wel cleartext genoemd – opslaan van een wachtwoord. Destijds waren het aantal kwaadwillenden veel lager dan heden ten dage, vooral omdat de programmeerkennis nu in ruime mate aanwezig is via het internet. MD5 encryptie was voorheen dus ruimschoots voldoende, tegenwoordig gaat dat niet meer op.

Inmiddels zijn we alweer een aantal jaren verder en zijn het aantal op internet beschikbare rainbow tabellen, waarin een grote lijst gangbare wachtwoorden in MD5 formaat opgeslagen is, niet meer op één tablet te tellen. De keuze voor een betere encryptie, zoals SHA-512 ligt bij de core developers. De mogelijkheden om deze te verbeteren worden in ieder geval continu ingebouwd, getuige de functie password_hash voor PHP 5.5+. Of het dan feitelijk ook zo is dat een betere encryptie ingebouwd is, kan men aannemen.

Wie echter het nieuws nauwlettend in de gaten houdt, merkt dat ook bij hele grote websites, de encryptie vaak maar marginaal is. Zie onder andere het volgende nieuws:

Van “onnodige” naar “bewust SSL/https”

Wanneer we het hebben over persoonsgegevens, wachtwoorden en betalingsgegevens ontstaat tegenwoordig steeds meer de bewustwording dat een https (SSL) verbinding noodzakelijk is op de website. Een decennium geleden kwam zoiets geeneens ter sprake. Destijds waren Man-in-the-middle aanvallen ook niet aanwezig. Met de komst van, met name, openbaar WiFi en de explosieve groei aan kennis is de kans sterk vergroot dat kwaadwillenden gevoelige informatie kunnen onderscheppen.

Helaas is het nog niet zo dat men bewust is van de noodzaak van SSL op de eigen website of -shop. Zo zien wij regelmatig websites waarop belangrijke persoonsgegevens onversleuteld verzonden worden. Als voorbeeld ook Windows Phone 7 waarbij het ingebouwde e-mailprogramma eenvoudigweg niet het SSL certificaat voldoende controleerde.

Dus bij deze de waarschuwing: voer geen belangrijke persoonsgegevens in op een website die niet met https/ssl beveiligd is; te herkennen aan een slotje in de adresbalk.

Van “professionals” naar “toegankelijk”

De oudere versies van de content systemen waren feitelijk lastig om te installeren, daarnaast had men kennis nodig van FTP en MySQL om ook maar een werkende installatie op gang te krijgen. De professionals, die deze installaties uitvoerden, waren op de hoogte van de noodzaak om te updaten en kenden zich uit hoe veilig maatwerk aanpassingen uitgevoerd konden worden.

Tegenwoordig is de installatie van onder andere WordPress en Joomla zo ver vereenvoudigd of geautomatiseerd, dat iedereen – dus ook leken – dit kunnen uitvoeren. Échte veiligheid komt echter pas na de installatie; een vanilla-installatie (zoals een kale installatie genoemd wordt) is namelijk op zich veilig. We merken dat klanten, wellicht uit onwetendheid, er van uitgaan dat de hostingprovider verantwoordelijk is voor de bescherming tegen hacks. Natuurlijk nemen wij alle voorzorgen, door moderne firewalls in te zetten en door snel in te springen wanneer hacks geconstateerd worden. De primaire verantwoordelijkheid ligt echter bij de klant, door regelmatig up te daten, wachtwoorden complex te houden en met niemand te delen.

Zie ook: 5 redenen om SSL/https te gebruiken en het filteren van uitgaand verkeer.